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?

Web servers deliver both static and dynamic content to client browsers. The dynamic content includes scripts that are executed on the client. These scripts can come from various sources when a dynamic web page is being delivered and displayed by a web browser on a client device. If an attacker manages to inject their own scripts into the dynamic pages delivered from servers, then the client will execute the scripts. This can lead to various unauthorised activities such as data being redirected, user accounts being compromised, cookies being downloaded for analysis, or the deployment of malware or other unauthorised software. The type of activity that could be performed when malicious scripts are executed is almost limitless. If a script written in JavaScript or one of the other client side scripting languages can be inserted into a web page being viewed by an authenticated user, then that malicious code could have ready access to other applications and data on the client and connected servers. Any data or process that is available to the web browser could be compromised. The client web viewer that is compromised in an XSS attack does not have to be a standard web browser. It could also be an embedded web view in an application.

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.

• Client XSS – Client XSS occurs when untrusted data is used to update the DOM with an unsafe JavaScript call. By definition a JavaScript call is considered unsafe if it can be used to introduce valid JavaScript into the DOM. The source of this data could be from the DOM itself, or it could have been sent from the server. The ultimate source of the data could have been from a request to a server, or from a stored location on the client or the server. This means that both Reflected Client XSS and Stored Client XSS attacks are possible.

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.

Client XSS is often caused when untrusted data is used to update the DOM with an unsafe JavaScript call. The easiest and strongest defence against this is to only allow the use of safe and trusted JavaScript APIs. Addition information on preventing Client XSS attacks is given in the cheat sheet link in the previous paragraph. A dedicated OWASP DOM based XSS Prevention Cheat Sheet is also available.

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.