Imagine a vulnerability that allows an attacker to take control of a website running on WordPress or a commercial web application. The only thing the threat actor needed to do was post a comment that included malicious JavaScript code. While this vulnerability was discovered by a researcher, which is why we only need to imagine its impact, other such vulnerabilities in web applications have been discovered and exploited:

As web applications increase in complexity, such vulnerabilities are increasing in frequency and certain types of vulnerabilities are found in many web applications. We analyse the most common vulnerabilities identified by K7’s VAPT team, and provide our recommended mitigation measures.

The 5 Most Common Vulnerabilities In Web Applications

1. Authorisation Bypass Through User-Controlled Key (Broken Access Control)

The Vulnerability

The system’s authorisation functionality does not prevent a user from gaining access to another user’s data or records by modifying the key value identifying the data.

  • Retrieval of a user record occurs based on a key value that is under user control
  • The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user
  • The authorisation process does not verify if the authenticated user has sufficient access privileges to perform the requested data access, bypassing any other authorisation checks present in the system

The attacker is likely to be an authenticated user in the system; internal attacks are known to be deployed by opportunistic or disgruntled employees.

How it May Manifest

Attackers can analyse locations where user specific data is retrieved (e.g., search screens) and determine whether the key for the item the user is searching for can be externally controlled. The key may be a hidden field in a HTML form field, or might be passed as a URL parameter or as an unencrypted cookie variable, allowing an attacker to tamper with the key value.

This vulnerability may appear in a system that uses sequential or otherwise easily-guessable session IDs that allow a user to easily switch to another user’s session and read or modify their data.

Mitigation

Ensure that

  • For every data access request, the user has sufficient privilege to access the record that is being requested
  • The key that is used in the lookup of a specific user’s record cannot be controlled externally by the user
  • Robust encryption is implemented to prevent guessing of legitimate key values
  • A digital signature is associated with the key to allow the server to verify that the key value has not been modified

2. Identification and Authentication Failure (Broken Authentication)

The Vulnerability

The system cannot accurately verify a user’s claimed identity or fails to grant access to authorised users, potentially allowing unauthorised individuals to access sensitive data, perform unauthorised actions, or impersonate legitimate users.

Mitigation

  • Implement multi-factor authentication (MFA) that requires additional verification factors beyond just a username and password
  • Protect user data with strong encryption at rest and in transit. Never store passwords in plain text
  • Thoroughly validate all user-controlled data to ensure it conforms to expected formats and contains no malicious code
  • Use secure session management practices such as short session timeouts, secure cookie flags, and regular session regeneration

3. Assumed-Immutable Parameter Tampering (Payment/Parameter Tampering)

The Vulnerability

The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.

  • Modification of critical data is possible if a web product does not sufficiently protect assumed-immutable values in hidden form fields, parameters, cookies, or URLs
  • Web applications often mistakenly assume that data passed to the client in hidden fields or cookies are not susceptible to tampering
  • Improper validation of user-controllable data can lead to processing of incorrect, and often malicious, input

How it May Manifest

Custom cookies commonly store session data or persistent data across sessions, which are involved in user authentication, access control, and other security-related decisions by the server. The cookies may, therefore, contain sensitive data such as user credentials and privileges which is risky and results in the server-side application improperly relying on values in the client-provided cookie.

Mitigation

  • Assume all input is malicious. Use an ‘accept known good’ input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications; reject any input that does not conform, or transform into something that does
  • When validating inputs, consider all potentially relevant properties including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input especially if the code’s environment changes, giving attackers room to bypass validation. Denylists can be useful in detecting potential attacks or determining which inputs are so malformed that they should be rejected outright
  • Inputs should be decoded and canonicalised to the application’s current internal representation before being validated

4. SQL Injection

The Vulnerability

SQL injection (SQLi) leverages the application’s misplaced trust in user-provided data, allowing attackers to inject malicious SQL code into seemingly harmless inputs. This code, disguised as valid user input, gets incorporated into database queries and tricks the database server into executing unintended actions.

  • Confidentiality is affected, as SQL databases often hold sensitive data
  • Using poor SQL commands to check user names and passwords may allow connecting to a system as another user with no previous knowledge of the password
  • Authorisation information held in a SQL database may be changed through SQLi
  • Data may be changed or even deleted

Mitigation

  • Sanitise and validate all user inputs before incorporating them into database queries
  • Use parameterised queries that separate data from the SQL statement, preventing malicious code injection
  • Utilise stored procedures with predefined parameters to limit risk

5. Cross-Site Scripting

The Vulnerability

Cross-Site Scripting (XSS) attacks are a type of injection in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way of knowing that the script should not be trusted and will execute the script, allowing the malicious script to access any cookies, session tokens, or other sensitive information retained by the browser and used with that site.

  • By stealing session cookies or other sensitive data, attackers can hijack user sessions, impersonate legitimate users, and gain unauthorised access to accounts or perform actions on their behalf
  • Sensitive information entered by users in web forms, such as login credentials, credit card details, or Personally Identifiable Information (PII), can be stolen
  • The website’s appearance or functionality may be altered, potentially displaying misleading information or redirecting users to phishing sites
  • Malware can be downloaded and installed on user’s device

Mitigation

  • Validate all user-controlled data before incorporating into web pages or database queries. Ensure data conforms to expected formats and filter out potentially malicious characters or code
  • Sanitise user input to remove potentially harmful code or scripts before including the user’s input in the application’s output. This can involve techniques like HTML entity encoding, which converts special characters into harmless representations
  • Appropriately encode user-controlled data when displaying within a webpage to prevent the browser from interpreting it as executable code

These are the top 5 vulnerabilities that K7’s VAPT team have identified across numerous information security assessments of web applications. There are many other vulnerabilities that are not as common but may exist in your organisation’s web applications and could expose your enterprise to highly destructive cyber attacks. Contact Us to learn more about how we can help you identify and close gaps in your web and mobile applications’ cyber defences.

Like what you're reading? Subscribe to our top stories.

2023 K7 Computing. All Rights Reserved.