An Introduction to Cross-Site Scripting (XSS) Vulnerabilities: Probably one of the most known web application security issues. These happen when an app adds untrusted data to a brand-new web page without validating or escaping it properly, creating an opportunity for the updates of another third-party user with malicious scripts. The purpose of this blog post is to provide a practical guide on how we can find and fix XSS vulnerabilities that might have slipped through the testing phase.
Understanding XSS Vulnerabilities
Three categories of XSS vulnerabilities exist: Stored XSS, Reflected XSS, and DOM-based XSS.
Stored XSS, also known as Persistent XSS, happens when the hacked script is permanently stored in a target server. As long as the required search information is requested to be held, this malicious script will then hide it within the server where one of its probable victims can retrieve it.
Reflected XSS, in which the malicious script is embedded in a URL The victim is tricked into clicking a malicious link, and the script bounces off of the web server back to execute within their own browser.
DOM-based XSS attack happens on the client, but it is completely in the browser of a user where a script changes a Document Object Model (DOM).
Testing for XSS Vulnerabilities
In order to check for cross-site scripting (XSS) vulnerabilities, several script payloads are injected into user-input fields, and their execution is monitored if they get executed. In order to find vulnerabilities that automated scanners might overlook, manual testing is just as important as using automated tools like OWASP ZAP and Burp Suite.
Below are some sample test cases:
TC1: Verify that all input is validated using positive validation.
| Title: Verify that all input is validated using positive validation. | |
| Severity | Low |
| Status | Fail |
| Reported by module | Hybrid Testing |
| Description | |
| Input validation is crucial in an information system to ensure that only correctly formatted data enters the workflow. This process prevents any malformed data from being stored in the database, which could potentially cause malfunctions in downstream components. It is highly recommended to perform input validation as early as possible in the data flow, ideally right after receiving the data from an external party. | |
| Impact | |
| A program crash or excessive consumption of resources, such as memory and CPU, can be triggered by an attacker by providing unexpected values. If an attacker gains control over resource references, they could potentially read confidential data. Additionally, an attacker can manipulate data or disrupt control flow by injecting malicious input, which may even lead to arbitrary command execution. | |
| Recommendation | |
| To ensure the accuracy and safety of data before processing, it is crucial to implement input validation. This can be achieved through various methods, including Client-Side vs Server-Side Validation, Validating Rich User Content, Preventing XSS and Content Security Policy, File Upload Validation, and Email Address Validation. | |
| References | |
| https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html https://cwe.mitre.org/data/definitions/20.html | |
| Affected items | |
| Register form: /Register.asp | |
| Details | |
| Steps to reproduce: 1. Access the URL: http://testasp.vulnweb.com/Register.asp 2. Input valid data to all fields 3. Input invalid data to Email field (Ex: hoa#gmail) 4. Click [Register me] button 5. Can register with invalid email => FAIL | |
| Request | |
| POST /Register.asp HTTP/1.1 Host: testasp.vulnweb.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 64 Origin: http://testasp.vulnweb.com Connection: close Referer: http://testasp.vulnweb.com/Register.asp Cookie: ASPSESSIONIDCQTBQDRC=MGALNKGDMPIMGLKMKJPDAHJE; ASPSESSIONIDCSTARDRC=GNFKJGDAKHPGOGKAFNIBOCJN Upgrade-Insecure-Requests: 1 tfUName=hoanguyen&tfRName=Hoa&tfEmail=hoa%23gmail&tfUPass=123456 | |
| Response | |
| HTTP/1.1 302 Object moved Cache-Control: private Content-Type: text/html Location: Login.asp?RetURL= Server: Microsoft-IIS/8.5 X-Powered-By: ASP.NET Date: Sun, 02 Oct 2022 08:08:19 GMT Connection: close Content-Length: 138 <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF=”Login.asp?RetURL=”>here</a>.</body> | |
| Proof of Concept / Reproduce | |
| PoC: functional input | |
| PoC: result of output | |
TC2: Verify that output escaping, whether automated or manual, is context-aware to effectively prevent reflected, stored, and DOM based XSS attacks.
| Title: Verify that output escaping, whether automated or manual, is context-aware to effectively prevent reflected, stored, and DOM based XSS attacks. | |
| Severity | Medium |
| Status | Fail |
| Reported by module | Hybrid Testing |
| Description | |
| Cross-Site Scripting (XSS) attacks occur when: Data is introduced into a Web application from an untrusted source, typically a web request. This data becomes part of dynamic content that is then sent to a web user without undergoing validation for potentially harmful content. The harmful content sent to the web browser often appears as a piece of JavaScript, although it could also consist of HTML, Flash, or any other type of code that the browser can execute. The range of XSS attacks is extensive, but they frequently involve actions such as transmitting sensitive data (e.g. cookies or session information) to the attacker, redirecting the victim to web content controlled by the attacker, or carrying out other malicious activities on the user’s device while appearing to originate from the vulnerable site. | |
| Impact | |
| XSS can lead to a range of issues for the end user, varying in severity from being a nuisance to completely compromising their account. The most severe XSS attacks involve the exposure of the user’s session cookie, enabling an attacker to hijack the user’s session and gain control of the account. Other harmful attacks include the disclosure of the user’s files, installation of malicious programs, redirecting the user to different pages or websites, or altering the presentation of content. If an XSS vulnerability allows an attacker to modify a press release or news item, it could impact a company’s stock price or undermine consumer confidence. Similarly, an XSS vulnerability on a pharmaceutical site could enable an attacker to manipulate dosage information, potentially resulting in an overdose. | |
| Recommendation | |
| When user-controllable data is inserted into application responses, preventing cross-site scripting attacks can be achieved by implementing two layers of defenses. Firstly, input validation should be performed rigorously upon arrival, taking into consideration the expected content type. For instance, personal names should only include alphabetical characters and a limited set of typographical characters, and should be relatively short. Similarly, a year of birth should consist of exactly four numerals, while email addresses should adhere to a specific regular expression. Any input that does not pass the validation process should be rejected rather than sanitized. Secondly, user input must be HTML-encoded whenever it is included in application responses. This involves replacing all HTML metacharacters such as <, >, “, ‘, and = with their corresponding HTML entities (<, >, etc). In situations where users are allowed to create content using a restricted set of HTML tags and attributes (e.g. blog comments with limited formatting options), it is essential to parse the provided HTML to ensure that it does not contain any harmful syntax. This task can be quite complex but is necessary to maintain security. | |
| References | |
| https://owasp.org/www-community/attacks/xss/ https://portswigger.net/web-security/cross-site-scripting | |
| Affected items | |
| Auth function: /auth/xss.php | |
| Details | |
| Steps to reproduce: 1. Access to website: http://php.testsparker.com/auth/login.php 2. Login with default account (username=admin/password=admin123456) 3. Access to website: http://php.testsparker.com/auth/internal.php 4. Input invalid data into “Search for” field (Ex: <script>alert(1);</script>) 5. Click on [SUBMIT] button The imported script will be executed=> FAIL | |
| Request | |
| POST /auth/xss.php HTTP/1.1 Host: php.testsparker.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded Content-Length: 52 Origin: http://php.testsparker.com Connection: close Referer: http://php.testsparker.com/auth/internal.php Cookie: PHPSESSID=8ed3b0c22363d4b355bc5d9612409fa4 Upgrade-Insecure-Requests: 1 search=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%29 | |
| Response | |
| HTTP/1.1 200 OK Date: Sat, 01 Oct 2022 16:52:02 GMT Server: Apache/2.2.8 (Win32) PHP/5.2.6 X-Powered-By: PHP/5.2.6 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Length: 2674 Connection: close Content-Type: text/html [REDACTED] !– end #header –> <div id=”page”> <div id=”page-bgtop”> <div id=”page-bgbtm”> <div id=”content”> <div class=”post”> <h1 class=”title”><a href=”#”>Admin Area</a></h1> <p>You searched for: <script>alert(1);</script>)</p> <div style=”clear: both;”> </div> <div class=”entry”> </div> </div> <div style=”clear: both;”> </div> </div> <!– end #content –> [REDACTED] | |
| Proof of Concept / Reproduce | |
| PoC: functional input | |
| PoC: result of output | |
Additionally, some scripts to execute:
Mitigation Strategies
The main steps in mitigating cross-site scripting (XSS) vulnerabilities include validating, sanitizing, and escaping user inputs. The following are some strategies:
Input validation: Verify that user inputs follow the formats that should be there. By doing this, attackers may be prevented from introducing harmful payloads.
Output Encoding: User input should be encoded before being re-displayed on the website (output encoding). This guarantees that any potentially injected scripts are handled as plain text rather than being run.
Content Security Policy (CSP): By limiting the locations from which scripts can be loaded, CSP can effectively prevent XSS by stopping inline script execution.
HTTPOnly Cookies: Use HTTPOnly cookies to stop scripts from getting access to private cookie information.
Use of Frameworks: To help prevent XSS, a lot of contemporary web development frameworks, such as Angular and ReactJS, automatically escape user inputs.
Conclusion
Even though XSS vulnerabilities are a serious threat to web applications, application security may be greatly improved by comprehending how they operate and implementing a thorough testing and mitigation strategy. Recall that maintaining security is a continuous activity rather than a one-time event.
Reference
- OWASP Foundation. (n.d.). Cross Site Scripting (XSS). Retrieved June 1, 2024, from https://owasp.org/www-community/attacks/xss/
- PortSwigger Web Security Academy. (n.d.). Cross-site scripting (XSS). Retrieved June 3, 2024, from https://portswigger.net/web-security/cross-site-scripting
- OWASP Cheat Sheet Series. (n.d.). Cross-Site Scripting (XSS) Prevention Cheat Sheet. Retrieved June 7, 2024, from https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
- OWASP Cheat Sheet Series. (n.d.). Input Validation Cheat Sheet. Retrieved June 20, 2024, from https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
- MITRE Corporation. (n.d.). CWE-20: Improper Input Validation. Retrieved June 20, 2024, from https://cwe.mitre.org/data/definitions/20.html
- PortSwigger Web Security Academy. (n.d.). Cross-site scripting. Retrieved June 20, 2024, from https://portswigger.net/burp/documentation/desktop/testing-workflow/input-validation/xss
- Precise Lab. (n.d.). XSS attack using script, style and image. Retrieved July 1, 2024, from https://preciselab.io/xss-attack-using-script-style-and-image/