Testing Cross-Site Scripting

Advertisements

Previous Page
Next Page  

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.

3. cross site scripting

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.

3. xss

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>
3. xss

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.

3. xss

Step 4 − Now as per the scenario, we need to login as jerry (HR) and check if jerry is affected by the injected script.

3. xss

Step 5 − After logging in as Jerry, select 'Tom' and click 'view profile' as shown below.

3. xss

While viewing tom's profile from Jerry's account, he is able to get the same message box.

3. xss

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.

Advertisements