- Security Testing Tutorial
- Security Testing - Home
- Security Testing - Overview
- Security Testing - Process
- Security Testing - Malicious Software
- HTTP Protocol Basics
- HTTPS Protocol Basics
- Encoding and Decoding
- Security Testing - Cryptography
- Security Testing - Same Origin Policy
- Security Testing - Cookies
- Hacking Web Applications
- Security Testing - Injection
- Testing Broken Authentication
- Testing Cross Site Scripting
- Insecure Direct Object Reference
- Testing Security Misconfiguration
- Testing Sensitive Data Exposure
- Missing Function Level Access Control
- Cross Site Request Forgery
- Components with Vulnerabilities
- Unvalidated Redirects and Forwards
- Security Testing - Ajax Security
- Testing Security - Web Service
- Security Testing - Buffer Overflows
- Security Testing - Denial of Service
- Testing Malicious File Execution
- Security Testing - Automation Tools
- Security Testing Useful Resources
- Security Testing - Quick Guide
- Security Testing - Useful Resources
- Security Testing - Discussion
Testing Cross-Site Scripting
Cross-site Scripting (XSS) happens whenever an application takes untrusted data and sends it to the client (browser) without validation. This allows attackers to execute malicious scripts in the victim's browser which can result in user sessions hijack, defacing web sites or redirect the user to malicious sites.
Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.
Types of XSS
Stored XSS − Stored XSS also known as persistent XSS occurs when user input is stored on the target server such as database/message forum/comment field etc. Then the victim is able to retrieve the stored data from the web application.
Reflected XSS − Reflected XSS also known as non-persistent XSS occurs when user input is immediately returned by a web application in an error message/search result or the input provided by the user as part of the request and without permanently storing the user provided data.
DOM Based XSS − DOM Based XSS is a form of XSS when the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.
Example
The application uses untrusted data in the construction without validation. The special characters ought to be escaped.
http://www.webpage.org/task/Rule1?query=try
The attacker modifies the query parameter in their browser to −
http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>
Hands ON
Step 1 − Login to Webgoat and navigate to cross-site scripting (XSS) Section. Let us execute a Stored Cross-site Scripting (XSS) attack. Below is the snapshot of the scenario.
Step 2 − As per the scenario, let us login as Tom with password 'tom' as mentioned in the scenario itself. Click 'view profile' and get into edit mode. Since tom is the attacker, let us inject Java script into those edit boxes.
<script>
alert("HACKED")
</script>
Step 3 − As soon as the update is over, tom receives an alert box with the message "hacked" which means that the app is vulnerable.
Step 4 − Now as per the scenario, we need to login as jerry (HR) and check if jerry is affected by the injected script.
Step 5 − After logging in as Jerry, select 'Tom' and click 'view profile' as shown below.
While viewing tom's profile from Jerry's account, he is able to get the same message box.
Step 6 − This message box is just an example, but the actual attacker can perform much more than just displaying a message box.
Preventive Mechanisms
Developers have to ensure that they escape all untrusted data based on the HTML context such as body, attribute, JavaScript, CSS, or URL that the data is placed into.
For those applications that need special characters as input, there should be robust validation mechanisms in place before accepting them as valid inputs.