What is XSS
XSS attack or cross-site scripting is a common code injection attack that allows a perpetrator to execute malicious JavaScript code into a vulnerable web app. Malicious scripts are frequently delivered in the bit forms of JavaScript code executed by the victim's browser, but exploits can involve malicious executable code in many different languages, such as Java, Ajax, Flash, VBScript, Active X, and HTML. The culprit doesn’t directly target a victim. Instead, attacker leverage a vulnerability in a website that a user visits, to get over the website and to deliver the malicious JavaScript for an attacker. For the user's browser, the malicious JavaScript appears to be a legit part of the site, because the site is acted as an inadvertent accomplice with the perpetrator. A successful XSS attack can cause devastating consequences for an online business’s image and relation with its clients. To avoid XSS attacks on your web app or online business read this article which includes: how XSS attacks impact on network or apps, their types, cross-site scripting example and where to useprotection against cyber-attacks.
How XSS Attack Works
Like 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 Types
There are 3 main types of XSS attacks:- Stored,
- Reflected, and
- DOM XSS.
Stored XSS
Store 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:
The code from the example is activated whenever a victim visits this web page section and sends the users' cookies of the web page to the perpetrator, who is then able to use cookies to hijack their sessions. Stored XSS can be very malicious since it can have the effect of a worm, particularly when exploited on popular pages. For instance, web page or social network app with a public facing page that is vulnerable to a stored XSS attack, like the profile page of the user. If the culprit can insert a malicious script that adds itself to the profile page, every time someone opens it the script will spread itself with the permanent growth.
Reflected XSS
It'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 XSS
It 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 Prevention
Remember 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
