We have been watching it lately XSS to become more and more well-known in its field better safetyof applications. Although the SQL Injection does not say to lose its first, as the most widespread vulnerability in IT systems as defined by OWASP Top 10, type vulnerabilities XSS are gaining more and more ground as the knowledge of exploiting the vulnerability and its effects increases attacks.
XSS vulnerabilities are divided into 3 types:
- Reflected
- Stored
- DOM Based
The details of each type of vulnerability are beyond the scope of this article, the important thing is to take into account that the same effects can happen to each type.
In most cases, when a type vulnerability occurs XSS either by malicious users or by system security consultants, we see one of the most painful effects, which is the presentation of a popup window in the browser that is accomplished by entering the Java code . Με απλά λόγια διατάζει τον browser να εμφανίσει το παράθυρο με το message "XSS ".
For the presentation we will use the Damn Vulnerable Web Application (DVWA) which is designed to practice and learn various kinds of vulnerabilities.
Although this does not cause concern to the user, for malicious users this is an introduction to further escalate the attack with enough disastrous results.
Another important thing to keep in mind is that the vulnerability of this vulnerability is most apparent when the application is accessible to users after their credentials have been registered, eg 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 is stored in a special file that is sent from the server and stored in the user's browser. This file includes information from whether o user already logged in, even information about his shopping cart, etc.
These files are the ones we know Cookies, which are usually deleted immediately after closing the browser, if this procedure 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.
Each time the user requests a page the browser sends the Cookie into the header of the request. In case the user does not have a cookie or it has expired then the server responds with a new cookie in its own header which is stored in the browser.
When a malicious user retrieves the file, it will be able to access the application without the need to register credentials and will be able to use the application as its legitimate user.
The way this attack works is listed below.
It is worth mentioning here that Chrome has a built-in XSS Auditor, which is a mechanism for recognizing and preventing the exploitation of XSS vulnerabilities. Although this mechanism recognizes the attempts and protects the user by preventing the execution of the code, nevertheless, fraudulent attacks have become known.
As in the case of the message "XSS", the user-friendly Cookie that is stored in his browser can also be displayed in the same simple way by entering the code .
One of the difficulties of success of these attacks is the fact that vulnerability occurs in the user 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. Malicious users have thought that since these vulnerabilities are related to the introduction of code then the next step would be to enter code that will send the Cookies to them through other channels such as email or a website that belongs to the malicious user and can serve as Cookie catcher.
We return to DVWA in order to get the user's Cookies and send them to the Cookie catcher that is controlled by us and enter the code where X is the IP of our Cookie catcher.
In our case our Cookie catcher is a simple PHP web site that stores the information that comes as:
- Cookie
- IP
- Referrer
- Date:
The results of the attack are shown below demonstrating the success of the attack after we were able to extract the Cookies as well as other useful information. The malicious user can now enter the application using cookies and without the need to enter a password. Also, it is important that this attack is very difficult to be recognized by the user, since all he sees is that the page does not load.
The purpose of this article was to show that the pressures of the press XSS are not limited to simply popup loopholes, but can have catastrophic consequences such as theft of personal data, theft of money,
