protection against cyber-attacks.
How XSS Attack WorksLike other injection attacks, cross-site scripting leverages the fact that browsers can't see valid markup from perpetrator-controlled markup. They execute any markup text they receive. The attack bypasses the SOP (Same Origin Policy), which purpose is to prevent scripts originating in one website from interacting with scripts from another website. The SOP requires that all content on a webpage come from the same source. When the SOP isn't working correctly, a culprit can inject a script and modify the webpage to meet their purposes. For instance, to extract data that will permit the perpetrator to become a validate user, or to insert malicious code for the browser to execute. Cross-site scripting can be used in many ways to cause severe problems. The typical use of XSS attacks enables a culprit to steal session cookies, allowing an attacker to impersonate the victim. However, it's not just taking cookies. Perpetrators can use XSS to spread malware, deface websites, create chaos on social networks, phish for credentials and in connection with social engineering techniques, perform more severe attacks.
XSS Attack TypesThere are 3 main types of XSS attacks:
- Reflected, and
- DOM XSS.
Stored XSSStore or persistent XSS is the most dangerous type of cross-site scripting attack. The culprit inserts a script (payload) that is stored permanently on the target application, such as a database. For instance, a perpetrator injects a malicious script on a blog, forum post or in a comment field.
The XSS script will be then be served as part of a webpage when the victim goes to the affected webpage in a browser. Then, when the victim views the page in a browser, a user will end up accidentally executing the malicious payload. Example: A stored XSS attack can happen if the username of an online shopping web page member isn’t correctly sanitized when it is printed on the page. In that situation, a culprit can inject malicious code once registering a new user on the form. Once the username is reflected on the shopping web page, it’ll appear like this:
Reflected XSSIt's the most common type of XSS attacks. In this type of attack, the culprit must deliver the script to the victim. Hence, the perpetrator’s payload must be part of the request sent to the web server and returned to the HTTP response and involves the script from the HTTP request.
The culprit uses phishing emails and other social engineering methods to entice the victim to request the server unintentionally which includes the XSS script. The victim then executes the payload that gets reflected and completed within the browser. Because reflected XSS isn't a permanent attack, the culprit must deliver the script to each victim. For example, search functionality on a magazine’s website, which works by adding the user's input, used from the GET request to the Q parameter, like in the example below:
In the search results, the web app reflects the query's content that the user searched for following: User searched for "data example": If the search feature is vulnerable to a reflected XSS attack, the culprit can send the victim a link like the following:
Once the victim points on the above link, the website will show the following: User searched for:
The HTML source code that is reflecting the perpetrator’s malicious code redirects the user to a website. It is controlled by the culprit, which can then record the victim's current cookie for user.com as GET parameter.
DOM XSSIt is an advanced type of XSS attack happens when the web application's client-side script writes user-provided data to the DOM (Document Object Model). The web app then reads the data from the DOM and send it to the browser. If the data is not controlled correctly, the culprit can inject a script that will be stored as DOM’s part. The script is then executed once the data is read back from the Document Object Model. Example: The following page http://www.user.com/test.html contains the below code:
After the malicious code is performed by page, an attacker can easily exploit this DOM XSS vulnerability to hijack the victim’s cookies or modify the page's behavior.
Cross Site Scripting PreventionRemember that the cross-site scripting attack is a type of code injection. User input is accidentally interpreted as malicious program code. To prevent XSS attacks, secure input handling is required. Here are 2 major methods of secure input handling: encoding and validation.
- Encoding is a method of escaping user input so that the browser recognizes it only as data, not like code.
- Validation, which controls the user input so that the browser sees it as code without malicious commands.
- Context: Secure input handling should be performed differently relying on where in a page the user input is inserted.
- Inbound/outbound: Secure input handling should be used either when a website receives the input (inbound) or just before the website inserts the input into a page (outbound).
- Client/server: Secure input handling should be applied either on the client-side or the server-side, depending on circumstances