Understanding XSS attack
Cross-Site Scripting (XSS) attack is one of the most important security risks in web applications described in the OWASP top ten. These faults occur when untrusted data without proper validation is inserted into an application. They use user’s input fields as entry points. The browser interprets this data as part of the application. Therefore, it’s constituted as a client-side attack. XSS allows attackers to execute scripts in the victim’s browser. This way it can hijack user sessions, destroy websites, direct the user to a malicious site, deny service, obtain confidential information, privilege escalation, etc.
To know more about secutiry risks in web applications, read OWASP: Top 10 Project for Applications Security
Non-persistent XSS
Non-persistent XSS attacks or reflected XSS do not store the malicious code on the server. It passes and presents it directly to the victim. It is the most popular method of XSS attack. The attack is launched from an external source, via email or a third party site.
Persistent XSS
The malicious code has already passed the barrier of the validation process and is stored in a data store. It can be any type of section of the website that requests input to the user a comment. Like a log file, a notification message, a script file, etc. When this particular information is presented on the website, the malicious code is executed.
DOM-based XSS
DOM-based XSS is an advanced type of XSS attack. It takes place when the web application writes user-provided data to the Document Object Model (DOM) from the client-side scripts.
In reflective and stored Cross-site scripting attacks, you can see the vulnerability payload on the response page. In DOM-based cross-site scripting, the HTML source code and response of the attack will be the same. I.e. the payload cannot be found in the response. It can only be observed at runtime or by investigating the DOM of the page.
The most dangerous part of DOM-based XSS is that is a client-side attack. But also, the attacker’s payload is never sent to the server. This complicates the detection of the attack for Web Application Firewalls (WAFs) and security engineers. They analyze the server’s logs and won’t even see the attack.
Finding Cross-Site Scripting Vulnerabilities
By understanding what XSS is, we can start to find this vulnerability in our application. In this opportunity, we explain “black box testing.” It is about injecting a string containing characters that have special meaning in HTML, into some parameter of an HTTP request. We are going to follow several steps to find XSS vulnerabilities in our application.
The first step is to select the tools to execute the tests. One important thing to have in mind is that the modern web browsers have some type of validation to avoid XSS attacks. Also, the application could have some client-side javascript input validation.
For this reason, we need to intercept the HTTP requests that the Web browser makes before they are sent. And modify them to inject our XSS test. Using a proxy that intercepts and scans traffic will help us identify problems. Example tools include Burp Proxy and ratproxy.
The second step is to identify all fields that allow user input for each page. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values.
In the third step, we need to select input data, to insert into the fields that were identified in the previous step. Generally, we use specially crafted input data.
Some examples of this input data could be:
>"'><script>alert(‘XSS')</script>
>%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
%22%2Balert(%27XSS%27)%2B%22
<table background="javascript:alert(([code])"></table>
<object type=text/html data="javascript:alert(([code]);"></object>
<body onload="javascript:alert(([code])"></body>
Fourth step: we are going to interact with our application. We have to insert strings that contain HTML and JavaScript metacharacters into all application inputs. We need to use the selected data in step 3.
For example: if we insert the string “"'><script>alert(‘XSS')</script>” and our application doesn’t correctly escape this string, we will see an alert and know that something went wrong.
XSS is taking the information inserted in step 4. Our page interprets it as a valid code. Then, it shows that information without any type of filtering. Using JavaScript allows an attacker to manipulate any aspect of the page displayed. Adding new elements (such as a false login screen that sends our credentials to a hostile site). Manipulating any aspect of the DOM internal tree. And deleting or changing the way in which a page is displayed. This is extremely dangerous in content management systems, blogs, or forums, where a large number of users will access information entered by other users.
The best protection for XSS is a combination of whitelist validation of all incoming information and proper coding of outgoing information. The validation allows the detection of attacks. The coding prevents any injection of a script from running successfully in the browser.
Further reading on security for web applications by clicking on Successful and Reliable Applications
