Consider a vulnerability that allows an attacker to take control of a WordPress website or commercial web application. To exploit this vulnerability, the threat actor only needed to post a comment containing malicious JavaScript code. The vulnerability was discovered by a researcher, which is why we can only imagine its impact. However, other similar vulnerabilities in web applications have been found and exploited in the past:
- An exploit in MySpace allowed a user to gain 1 million friends in a day before the site was taken offline to fix it
- There was a data breach at British Airways that resulted in a £20 million fine and a confidential settlement with those affected, but it was caused by a script modification on the baggage claim information page. This script allowed attackers to access credit card CVV codes that were not stored on British Airways’ servers, which led to the breach.
There are more and more vulnerabilities in web applications as they become more complex, and certain types of vulnerabilities are found in most web applications. Analyzing the most common vulnerabilities identified by eScan’s team, we recommend mitigation measures.
Web application vulnerabilities: The top five most prevalent ones
- breaching access control by evading authorization using a user-controlled key
Vulnerability
The authorization functionality in the system does not prevent a user from altering the key value identifying data or records belonging to another user.
- In order to retrieve a user record, a key value that the user controls must be specified
- A key identifies a user-related record stored in a system, and is used to search for that record for presentation to the user.
- Other authorisation checks in the system are bypassed during the authorisation process, since the authenticated user doesn’t have enough priveleges to get to the requested data.
Authenticated users are likely to conduct internal attacks; opportunistic or disgruntled employees typically deploy internal attacks.
How it might seem
The attacker can determine whether the key for the item the user is searching for can be remotely controlled by analysing locations where user-specific data is retrieved (e.g., search screens). It is possible to tamper with the key value by hiding it in an HTML form field, passing it as a URL parameter, or using an unencrypted cookie variable, among other methods.
The vulnerability is commonly found in systems that use sequential or otherwise easily guessable session IDs, which allow users to easily access and modify the data of another user.
Reduced
Ensure that
- Every data access request is granted sufficient privilege for the requestor to access the requested records
- It is not possible for a user to manipulate the key used in the lookup of a specific record by themselves
- It implemented robust encryption to prevent legitimate key values from being guesses
- The key value is protected by a digital signature, so that the server can verify that it has not been modified
- Defective Identity and Authentication (Broken Authentication)
Vulnerability
Users are unable to verify their claimed identities, or they are not granted access by the system to authorized users, which may allow unauthorised individuals to access sensitive data, perform unauthorised actions, or impersonate legitimate users.
Reduced
- Set up multi-factor authentication (MFA) where additional authentication factors are required over and above usernames and passwords
- Ensure that user data is protected at rest and in transit with strong encryption. Keep your passwords secure by never storing them in plain text
- Ensure that all data controlled by users is validated thoroughly and contains no malicious code
- Maintain secure session management practices such as short session timeouts, secure cookie flags, and periodic session regeneration
- 3. Tampering of Assumed-Immutable Parameters
(Payment/Parameter Tampering)
Vulnerability
A web application failing to verify hidden form fields, for example,that are actually externally controllable but assumed to be immutable.
- It is possible to modify sensitive data if a web application does not sufficiently protect assumed-immutable properties in hidden form fields, parameters, cookies, or URLs
- It is common for web applications to mistakenly assume that data passed to the client in hidden fields or cookies cannot be altered
- User-controlled data that is not validated correctly can result in incorrect and malicious input being processed
How it might seem
It is common for custom cookies to store session data or persistent data across sessions, both of which are used by the server for authentication, access control, and other security-related decisions. Consequently, cookies may contain sensitive data including usernames, passwords, and privileges, which can lead to server-side applications improperly relying on client-provided cookie values.
Reduced
- Consider all input malicious. A validation strategy based on ‘accept known good’ inputs, i.e. using a list of acceptable inputs that strictly follow specifications, rejecting any input that does not meet specifications; or transform input to meet specifications
- Validate inputs by considering all potential relevant properties such as length, type, full range of acceptable values, missing or additional inputs, syntax, consistency across related fields, and business rules compliance
- Beware of relying solely on looking for malicious or malformed inputs. It is likely that at least one undesirable input will be missed, especially if the environment of the code changes, thus giving attackers the opportunity to bypass validation. Input denylists are useful for deciphering potential attacks or identifying inputs that should be rejected outright due to their malformations
- Validating inputs requires decoding and canonicalizing them to the application’s internal representation
- SQL Injection
Vulnerability
As a result of SQL injection (SQLi), attackers are able to inject malicious SQL code into seemingly harmless inputs by taking advantage of the application’s misplaced trust in user-provided information. The code is incorporated into database queries under the guise of valid user input and tricks the database server into executing unintended operations.
- Because SQL databases often store sensitive information, confidentiality is affected
- Poor SQL commands can lead to user names and passwords being compromised.
- Accessing a system without knowing the password of the previous user
- An SQL database can provide authorization information that can be changed with SQLi
- Modifications or deletions of data are possible
Reduced
- Ensure that all user inputs are sanitized and validated before they are incorporated into database queries
- Using parameterised queries will prevent malicious code injection thanks to the separation of data from the SQL statement
- Predefined parameters should be used in stored procedures in order to minimize risk
- Scripting on Cross-Site
Vulnerability
A Cross-Site Scripting (XSS) attack involves injecting malicious scripts into otherwise trusted and benign websites. A cross-site scripting attack is a method of sending malicious code to a different end user using a web application. The vulnerabilities that allow these attacks to succeed are quite widespread, and they affect any web application that includes user input without validating or encoding it.
It is possible for attackers to use XSS to send a malicious script to unsuspecting users. In this instance, the browser does not realize that the script is malicious and executes it, allowing the malicious script to access any cookies, session tokens, or sensitive information stored by the browser.
- Taking advantage of session cookies or other sensitive information can allow attackers to hijack user sessions, impersonate legitimate users, and gain unauthorised access to accounts or perform actions on their behalf
- It is possible for web forms to capture sensitive user information, such as login credentials, credit card information, or Personally Identifiable Information (PII).
- An altered website may display misleading information or redirect users to phishing sites by altering its appearance or functionality
- The user’s device can be infected with malware when it is downloaded and installed
Reduced
- Ensure that all user-controlled data is validated before being incorporated into web pages or database queries. Data should be formatted according to the expected format and potentially malicious characters should be filtered out
- Before including user input in the application’s output, sanitize it to remove potentially harmful code or scripts. Techniques such as HTML entity encoding can be used to convert special characters into harmless representations
- Ensure user-controlled data is appropriately encoded when displayed within a website to prevent it from being interpreted as executable code by the browser
Our eScan team has identified these five vulnerabilities across a variety of web application information security assessments. Besides common vulnerabilities in web applications, there are many other vulnerabilities that might exist in your enterprise’s web applications and expose your enterprise to highly destructive cyber-attacks. Learn how we can help you identify and close gaps in your web and mobile applications’ cyber defences by contacting Us.
