Web Application Weakness Trends
These days, it is quickly becoming a necessity that all companies have public facing web applications for various purposes. Additionally, these web applications can be incredibly complex with a large feature set. Because of that, web application weaknesses can arise pretty easy, resulting in serious consequences. In this blog post, we’ll examine a couple web application weakness trends that I personally have noticed in the past year while conducting web application penetration tests, along with some examples.
Authorization Weaknesses
A common pitfall in web application security are weaknesses in authorization. NIST defines authorization as “the process of verifying that a requested action or service is approved for a specific entity”. Authorization weaknesses can be seen in various ways, such as allowing users to access content or features within an application that should otherwise be restricted.
From File Download to Admin
During an assessment, an authorization vulnerability was discovered in a web application where I was able to view/download any file that a user had uploaded. Uploaded files should have their access restricted such that only users that own the files can download them or only users with a specific role granted to them can gain access. That could be any role with a justified business need, like employees who review supporting documentation for medical claims or employees who need to share files with one another for collaborative purposes.
This vulnerability was identified based on how the application assigned identifiers for files. By uploading two files back-to-back, I observed how sequential, numeric IDs were given in the application which looked something like:
• https://example.com/Documents/Download/attachmentId=110
• https://example.com/Documents/Download/attachmentId=111
Note how the “attachmentId” values increment in a standard, predictable pattern. After noticing this, the next step was to figure out if I could access another user’s files. By modifying the attachmentId to a different value, a file was downloaded which was outside of my control that I could not view through the user interface. This then allowed me to use Burpsuite’s built-in Intruder tool. Intruder is a powerful tool which can help automate requests for vulnerabilities using a configured pattern or list, ultimately speeding up the exploitation process.
In the image above, I flag the attachmentId parameter, and then iterate through a list of numbers 0 through 200 and manually review each response received looking for sensitive information.
From here, a file was discovered which contained a valid set of credentials for the target application. After logging in with these credentials, I was able to grant administrator access to the testing account which we were given to facilitate testing.
Remediation
To mitigate against authorization vulnerabilities, proper authorization checks should always be in place to prevent parameter modification such as the example above. Additionally, introducing GUIDs (32-character identification strings) or longer alphanumeric strings is a good idea to prevent the automated enumeration of files, as I demonstrated above.
Sensitive Data Exposures
Another common weakness seen is sensitive data exposures. Unfortunately and commonly, we see data in responses which should normally never be exposed. This can be anything from cleartext passwords, password hashes, SQL statements, personally identifiable information (PII), customer/client names, etc. Data leaks in HTTP responses and/or within the application can lead to customer data being breached, an attacker elevating their privileges, and more.
Unauthenticated Search to Admin Account Takeover
Let’s take a look at another example from a web application penetration test which has since been remediated. The application had a search bar which would retrieve data through an API. Included in this API response was a password field with an MD5 hashed password.
First, password hashes should never be returned in a response, especially in this case where any unauthenticated user could issue a search request and observe this password hash. Additionally, MD5 is considered a weak hashing algorithm as it has significant issues, including the presence of collisions and the fact that is has a very low work factor. The majority of the hashed passwords were easily cracked, allowing access to most accounts on the application. Once logged in, this then led to another overly verbose API response that was observed, but this time with plaintext username and password credentials for an administrative portal were returned.
Remediation
Information returned in API calls should always be restricted to only that which is necessary to be displayed based on a user’s access.
Summary
While vulnerabilities such as cross-site scripting (XSS) and SQL injection (SQLi) are often highlighted when talking web application security, it’s important to remember there are many more serious vulnerabilities that may not be discussed enough. Additionally, vulnerabilities like authorization bypass, insecure direct object references, or sensitive data disclosure via application/API responses may fly under the radar until a compromise occurs, whereas XSS and SQLi are getting more frequently caught by static code analysis, internal testing/review, or web application firewalls (WAF).
