We have been watching it lately XSS to become more and more known in the field of application security. Although it is 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 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 είτε από κακόβουλους χρήστες είτε από συμβούλους ασφάλειας συστημάτων βλέπουμε μια από τις πιο ανώδυνες επιπτώσεις η οποία είναι η presentation ενός παραθύρου popup μέσα στον browser το οποίο επιτυγχάνεται με την εισαγωγή του κώδικα Java . 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.
Αν και αυτό καθαυτό δεν δημιουργεί ανησυχία στον χρήστη, για τους κακόβουλους χρήστες αυτή είναι μια εισαγωγή για περαιτέρω κλιμάκωση της επίθεσης με αρκετά καταστροφικά 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 our known Cookies, which are usually erased immediately after the browser is closed, if this is not done, then the risk of theft is increased and used at a later stage. This file is moved back to the server every time a user opens a page in the application.
Every time the user requests a page the browser sends it Cookie inside header of the application. In the event that 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 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 unless the malicious user has access on 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,
