Cross Side Scripting - XSS

Cross Side Scripting is technically a security vulnerability that includes injection of code into a web pages through the a vulnerable web application.

This is the process of transferring information form an entity in the vulnerable web app of a user's to another entity in the attackers host.

The information transferred includes the session data, sensitive page content, compromising user data, and other entity objects.

XSS has proved its existence, from the day JavaScript was introduced by Netscape. Initially it  had lots of vulnerabilities since this supports the client-side execution of code sent from the server with no security policies.

So this lead to the major vulnerability as when a malicious site and trusted site is open on a browser by executing malicious code the attacker can gain user's session data of the trusted site directly and exploit them.

This further lead to the development of Same Origin Policy.

Same Origin policy:

According to this policy the interaction between the objects on the client side is restricted to the web pages based on the factors like domain name, application layer protocol used, TCP port of web page running scripts. By this the data is made inaccessible to the attackers even if malicious site is open in the user's browser.  But these are gradually bypassed by the attackers.

 The XSS can be considered as two categories based on the type of storage of scripts.

1) Reflected XSS:

This is based on the vulnerability, that when a data is submitted to a web app.In this type, the script is not stored by the web page. This is the most commonly used type of XSS called as Reflected XSS. Here this is based on the single request and response. where the attacker issues a request with a payload and delivers it to the specific users. This is performed easily by a little of social engineering to induce users with the legitimate format of delivery.

Like using the official mail format or message format used by the company.

 Effects:

• Virtual Defacement: XSS malicious code has the ability to alter the code on the client side,  creating  a virtual mask over the actual content. Considering this attacker takes rule over the data but only when user indulges in action like clicking the malicious link generated by the attacker the user is affected. Instead of changing the site content by mirroring the original web page and make desired changes and redirect the user to the target site, but on both situations user must be made to click the link generated by the attacker. The reasons for this attacks includes the Mass Hysteria or Panic. Like publishing fake news in popular news channels on things that can get viral easily or by faking stock prices in stock markets.
• Session Hijacking: This is the most common among the first order XSS itself. Here attacker supplies malicious code to the user that requests for the user's session data and issues the response to a malicious site of the attacker. This is a direct attack on the user by getting the session objects of a trusted site like bank sites. where attackers can get financial gain as the can use any part of the transactions possible on that particular web application. This is explained as.,

These data obtained can be directly used by the attackers while using their regular browsers and adding the session data to the vulnerable web app. For example the Firefox users can use LivehttpHeaders extension and change the cookie and other values directly.(Cookie:)
These attacks are not that efficient when compared to Request Forgery (XSRF) when stealth or anonymity is taken as major concern. Request Forgery exploits the client-server trust relationship and uses the vulnerable application as a proxy like connection between the attacker and user.

2) Stored XSS:

This is based on the persistent exploitation of the webpage over all its viewers, this occurs when the malicious code or file is stored to the database or as file system. And it is not a single request targeting a user it can affect multiple users, Since stored, loaded every time user loads the web page. The main advantage of the Second order over the first is that the number of users affected is more. And also it can spread with a malicious code. 

For example lets take two instances for understanding it.

• Firstly, Samy worm it is XSS developed towards a social neworking site (MySpace) written by Samy Kamkar. The logic behind it is that, it is uploaded into a profile and then the views of that particular profile are in turn affected by the code. here the Samy was the user and he uploaded the malicious code to his profile,  the code affects the viewers and makes Samy their hero and makes them friend of  Samy. This has become one of the fastest spreading viruses all-time. Due to the Exponential rise in the Samy's friend requests, MySpace had a DoS attack.
  
  

  
• Secondly, Lets consider that we are on to a Electronic devices selling web app, attacker uploads a image just built by designing tool and inserts the malicious code and uploads the image for sale. When user clicks on the image to view it. The malicious code is executed.  Which can take up the session data of the viewers accounts. By which the attacker can use the user's account completely.

 Prevention:

When comes to prevention the main thing to be noted is the input validation at each parts of the web app. Restrict the length of the input user can enter and the list of permitted characters user can enter. Most of the vulnerabilities are identified using the errors that the application returns to the users, so encode it to sanitize the application from showcasing its vulnerability to attackers. For the Second order additionally validate the file uploaded and the HTTP headers. 

Purging hazardous characters must be filtered and sanitized on all log files.

Prevention Mechanisms includes the Signatures filters, that filter based on the signatures of scripting in the user inputs,  Purging data filters that helps in filtering the scripting done by purging of or encoding of the scripts in the user inputs.

Though these inputs are validated, these prevention mechanisms are more likely to be bypassed by the attackers, so the main thing is that we must be aware of the vulnerability before the attacker does.

 Happy Secure Coding :)