Cross-Site Scripting

Description

The browser then executes the script in the context of a site the user trusts. That means the script can see part of the page content, change what is displayed, send requests, steal tokens that are not well protected, or slip the user a fake login form. To the user everything still looks like the same familiar site.

XSS is often the result of a poor attitude to user input. A comment, a search, a profile name, a parameter in a link or a part of the DOM become the places through which an attacker injects malicious code. If the web application does not handle that input properly before display, the line between content and program code slowly disappears.

Examples

• The attacker injects a script into a comment on a forum. Every user who opens the thread unknowingly executes that code in their own browser, on their own machine.
• The victim is sent a link with a specially prepared search parameter. The page returns the result together with a script that executes immediately.
• DOM XSS changes the page display and inserts a fake login form that looks like part of the legitimate application.

Notes

• XSS is not merely a cosmetic matter. Carried out in the right place, it can cause session theft, account takeover or a covert way into a business application.
• Protection does not come down to deleting a few dangerous characters. It takes proper output encoding, a Content Security Policy, HttpOnly cookies and discipline in handling user input.