OWASP Top Ten Series: Cross Site Scripting
Cross Site Scripting (XSS) attacks are a type of injection attack. XSS is probably the most common type of malicious attack after code injection. They are certainly the most common vulnerability type targeting client browsers and web views.
What is the vulnerability?
Cross site scripting attacks have traditionally been organised into three types. There is some overlap between the types due to the way that the scripts are delivered. The traditional types are:
- Stored XSS – Also know as Persistent or Type I XSS. In this type of XSS attack the injected script is permanently stored on a server. The storage can be in a database, in a web page component like a message forum, visitor log, comment field, or other element that goes to make up a page to deliver to a user. The victim of the attack retrieves the malicious script from the server when they request the stored content as part of a browsing session. The malicious script is delivered along with the normal web content and the client executes it. In this scenario it is the server that has been compromised and is used by the attacker to deliver scripts to the client browser sessions.
- Reflected XSS – Also know as Non-Persistent or Type II XSS. Reflected attacks are those where the malicious script is reflected by a web server and then executed by the the web browser. In this type of attack a user is tricked into clicking a link, or filling in a form, that has the script hidden in it. When this is submitted to the server it will be rejected and reflected back to the browser. Many servers will send the input back in text format so the browser can display the input that was rejected. If this text is a valid script then the browser will execute it as it is coming from a trusted source.
- DOM Based XSS – Also know as Type 0 XSS. DOM Based XSS is an attack wherein the attack payload is executed as a result of modifying the DOM (Document Object Model) environment in a browser used by the original client side script, so that the client side code runs in an unexpected manner. The page itself does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. As the DOM XSS is a purely client side browser attack there is an ongoing discussion as to whether it should be reclassified and renamed as Client Side XSS.
Starting in 2012 there has been an effort to reclassify the types of XSS attacks under two main headings. These are:
- Server XSS – Server XSS occurs when untrusted data is included in a web page generated by the server and delivered to the client browser. The source of this untrusted data could be from the original request, or from a stored location. This means that both Reflected Server XSS and Stored Server XSS attacks are possible. The entire vulnerability is in server-side code that is delivered to the client. The browser is simply rendering the response and executing any valid script embedded in it.
The definition of DOM Based XSS doesn’t change under these two new definitions. DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the Server.
Given that both Server XSS and Client XSS can be Stored or Reflected, this new classification results in a simple matrix with Client & Server XSS on one axis, and Stored and Reflected XSS on the other as shown in table below:
How to protect against Cross Site Scripting
Server XSS is caused by allowing untrusted data to be inserted into dynamic web pages sent from servers to client browsers. The easiest and strongest defence against Server XSS in most cases is to enable context-sensitive server side output encoding. Details on how to implement this, and many other ways to counter XSS attacks are presented in detail in the OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet.
As stated in other articles in this series it’s also vital that systems are kept up to date with the latest software versions. Security vulnerabilities and bugs are constantly being discovered and fixed. General network security infrastructure should be kept up to date as well. Firewalls, content checkers, anti-malware systems and Load Balancers should be running the latest software patches. Additional security tools should also be deployed and kept up to date. The KEMP Web Application Firewall Pack (AFP) for LoadMaster includes tools that continuously monitor traffic to application and web servers. It detects and counters known vulnerabilities, including those outlined in the OWASP top 10. Specifically it detects and prevents the malicious injection of untrusted data into values that are passed between servers and clients. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered.