We have been watching it lately XSS to become more and more known in the field of application security. Although it is SQL Injection it does not say to lose its primacy, as the most widespread vulnerability in IT systems such as those specified by the OWASP Top 10, type vulnerabilities XSS are gaining more and more ground as knowledge of exploitation of vulnerability grows and the impact of such an attack is growing.
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 . Simply puts 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 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 when navigating page by page, but stored in a special file that is sent by the server and stored in the user's browser. This file contains information from whether the user has already logged in, up to 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.
Every time the user requests a page the browser sends it Cookie μέσα στο header της αίτησης. Στην περίπτωση που ο χρήστης δεν έχει Cookie ή αυτό έχει λήξει τότε ο διακομιστής απαντά με ένα νέο Cookie στο δικό του header το οποίο αποθηκεύεται στον 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 built-in XSS Auditor, which is a mechanism for identifying and preventing exploitation of XSS vulnerabilities. Although this mechanism recognizes the attempts and protects the user by preventing the execution of the code, nevertheless attacks fromscamhis
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 for these attacks to succeed 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 except and whether the malicious user has access to the victim's screen. Malicious users thought since these vulnerabilities are related to injecting code then the next step would be to inject code that would send 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,
