Cross Site Scripting is a well known web application vulnerability . It is essential that we do a Web Application Penetration testing of our web application for testing against such vulnerabilities as Cross Site Scripting . Cross Site Scripting is referred as XSS instead of CSS for obvious reasons ( CSS is well known abbreviation for Cascading Style Sheets ).
What is Cross Site Scripting ?
XSS is ranked as one of the OWASP top ten web application vulnerabilities and recommended during penetration testing of the web application . In XSS an Attacker injects a malicious script to perform unauthorised actions on trusted websites . Malicious Script executes on the browser (or server) and infects the webpage visitor . XSS can be found in websites where the user input is taken but is not encoded or sanitized or escaped.
Why Does XSS Occurs ?
- Trust of the developers for the users .
- Application is not filtering the user input before processing .
- XSS has lots of variants . Sometimes Applications gets confused while filtering the user input and allows the malicious scripts . Most XSS filters tend to fail .
We can never be sure that the Application is 100% safe from XSS Attacks . Always research and make XSS filters smarter .
Types Of XSS
Non Persistent / Reflected XSS :
Data is infected and reflected back in response . Generally this contains a link with an XSS Attack Vector .
Persistent XSS / Stored XSS
XSS attack vectors stored in database and executed when the web page is visited by the user . Each time the user visits the web page the script is executed .
DOM Based XSS
Caused by the trust of developers on the users. HTTP Response is not changed but the malicious script executes . Happens due to DOM (Document Object Model) modification of the webpage . This is the hardest type of XSS to detect during the Penetration testing of the web application and the most dangerous type of XSS .
Penetration testing Against XSS
Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response.
- Detect input vectors. For each web page, the tester must determine all the web application’s user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.
- Analyse each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability.
Prevention Of XSS
XSS can be prevented while coding an application .
- Validate All Input and Output .
- Escape all special characters that may be used in a script .
- Internet explorer has an Attribute HTTP-Only that can be set for cookies to avoid access to cookies by any third party scripts and hence preventing cookie stealing .
- White listing input validation is also a good technique .
- Use OWASP Auto sanitization Library .
- Refer to OWASP Content Security Policy .
- Output validation must be done otherwise browser might treat malicious scripts as an active browser content .
- Build a good XSS Filter .