A7 Cross-Site Scripting (XSS) 2017

A7 XSS 

Description:

It is the seventh most critical web application security risk according to OWASP Top ten list (2017).

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.

Types of Cross-Site Scripting :

1. Stored Cross-site Scripting (XSS)
2. Reflected Cross-site Scripting (XSS)
3. DOM Based Cross-Site Scripting

Let’s discuss in details:

Stored XSS 

Stored XSS generally occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser. With the advent of HTML5, and other browser technologies, we can envision the attack payload being permanently stored in the victim’s browser, such as an HTML5 database, and never being sent to the server at all.

Reflected XSS  

Reflected XSS occurs when user input is immediately returned by a web application in an error message, search result, or any other response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data. In some cases, the user provided data may never even leave the browser (see DOM Based XSS next)

DOM Based XSS 

DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write)."

Examples:

1.Reflected/Non-Persistent XSS

Most of the XSS vulnerabilities are exploited by a reflected XSS attack. Its very simple, you enter a malicious script in a input form which is vulnerable to XSS and the script gets executed. If you want to attack a user, you can simply send him a link with your malicious script.

For example, I exploited a website’s search form and the webpage which executed my malicious script has the following URL:
www.example.com/search.php?term="><script>alert(dadada)</script>

Now if I send this link to someone and he opens it then my malicious script will be executed in his browser. This kind of XSS i.e. Reflected XSS is temporary as it can be executed only when you visit a malicious URL.

2.Persistent/Stored XSS

This type of XSS occurs when a hacker injects a malicious script and it gets stored in the database of the website and gets executed every time when a user visit the infected page. Yes. I said it gets stored.

For example,




This input form is vulnerable to XSS in which I have entered my malicious script.
Now my comment i.e. malicious script will get stored in the database of the website and everyone visiting the page that I have commented on will get a pop up like this:

A hacker can easily insert a cookie stealing script, a redirection script, a phishing page and what not?

3.DOM-Based XSS

What is DOM? Well Document Object Model (DOM) is a thing which allows the client side script (i.e. JavaScript) to modify the content and layout of a webpage.

Take a look at this code

<html> 
<head>
</head>
<body>
     <script>
var pos=document.URL.indexOf("input=")+6;  //finds the position of value 
var userInput=document.URL.substring(pos,document.URL.length); //copy the value into userInput variable
document.write(unescape(userInput)); //writes content to the webpage
  </script>
</body>
</html>

This code is vulnerable to DOM based XSS as it renders the webpage according the input submitted by the user. So a hacker might send a link like example.com/index/doc.php?m=Click <a href=”phishing_site.com”>here</a>.

Which will render the page like this:

So I can send this to anyone and their browser will render the this page and not the server.

Preventing XSS Vulnerabilities:

To prevent cross-site scripting vulnerabilities it is very important to apply a context dependent output encoding. In some cases it might be enough to encode the HTML special characters, such as opening and closing tags. In other cases a correctly applied URL encoding is necessary. Links should generally be disallowed if they don't begin with a whitelisted protocol such as http:// or https://, thus preventing the use of URI schemes such as javascript://.
Even though most modern web browsers have an inbuilt XSS filter they should not be seen as an alternative to sanitization. They cannot catch all kinds of cross-site scripting attacks and are not strict so not to lead to false positives, which would prevent some pages from loading correctly. A web browser's XSS filter should only be a "second line of defense" and the idea is to minimise the impact of existing vulnerabilities.
Developers should not use blacklists as there is a variety of bypasses for them. Another thing they should avoid using is the stripping of dangerous functions and characters as the browsers' XSS filters can't recognize the dangerous payloads when the output is tampered with allowing for possible bypasses. That being said, the only recommended prevention of XSS is encoding as mentioned above.



NOTE:Information showing on this blog is only use for educational purpose.