Cross-site scripting (XSS) is the most prevalent website attacks today but many webmasters overlooks it. The attack causes distributed denial-of-service and SQL injections attacks. According to a latest study report, about 75% of United States’ government websites are found to be susceptible to XSS attack.
XSS attacks hunt their victims by using the connection user and website he/she is accessing. Principally, when a user visits a website, the data transferred between the web server and user’s browser client should remain visible only to website owner or those who are authorized to see it. But the intrusion of XSS into the relationship can disclose the information to a malicious third-party.
Same-origin policy
Limiting the code to interacting with data from same-origin server is a dependable method to develop trust in web applications. Let’s assume that a website owned by rockcorps.com contain two external files of JavaScript, one hosted at abchost.com and other at xyzhost.com.
The roots of the problems lie here, because the document elements on the page generated from abccorp.com can be accessed by the code downloaded from the xyzhost.com. These entities may include username, password and account balance. The other scripts downloaded from abchost.com, such as functions and methods, can also be called by with this code.
But the code downloaded from xyzhost.com, on the other hand, is not allowed to access these elements. This “same-origin policy” provides the protection to the user because we aren’t clear that the code from xyzhost.com can be relied or not. This same-origin policy may differ for different web browsers.
The mission of a attacker is to trip the code into browser under the pretext of kowtowing to the same-origin policy and to achieve this, they rely upon XSS attacks.
Typically, these XSS attacks fall into two further strategies – reflected attacks and persistent attacks.
Reflected XSS Attacks:
In a reflected XSS attack, a code is unintentionally is sent to a web server which than reflects that script back into the browser of the user. From here it is executed by a malicious third-party, who performs it for their sinister deeds.
For example, consider a website that allows the user to insert input in form of search request. Let’s suppose that the web app responds with the search query with such outcome, “Results of your search for abc…”
Now assume that code that processes the input entered by user, either on server side or client side, does not sanitize it sufficiently. The user input which actually features the code, such as JavaScript, from the client-side could be crafted by the attacker. This code could be used to steal this information from user and dish it out to the server that is under attacker’s control.
In a classical reflected XSS attack, the end-user receives a hyperlink from the attacker that contains the malicious code. This link is usually delivered through a phishing email the prompts the user to click over it and set-off attack progression. .
Persistent XSS
The potential of a reflected XSS attack is limited because it depends on how much users can be trapped for triggering malicious code. The attacker who want to utilize it for large scale, prefer to bank on a persistent XSS attack.
Basically, the persistent XSS attack works in the similar way as of reflected XSS attack, i.e, as the malicious code is embedded into a webpage sent by server, to satisfy the end-user about same-origin policy. However, in this type of XSS attack the attacker places the script in a webpage where it became visible to every user.
Let’s take the example of a web-based discussion board, such as forum. The messages posted on the forum are witnessed by the every visitor of that page. These messages are submitted by the users. If the malicious code is baked into a message by the attacker that the users post themselves, most of the users will unintentionally execute the code.
Here the insufficient sanitization of the user input message board posts is the key vector exploited by the user. These web-board discussion boards and the other websites that display the user submissions allow the unknown parities to post the content. So if this content isn’t methodically cleansed of potential malicious script, the attacker can easily plant the persistent XSS attack on the website.
Aftermaths of an XSS attack
The XSS code can be crafted to steal variant receptive information including the data submitted on the same webpage where the malicious code was placed. However, the theft of user authentication credentials is the most dangerous scenario.
In many websites, the authentication credentials are saved in the browser cookies. The malicious code can take these cookies and deliver to the attacker controlled server. The access to cookies may allow the attacker to access the same website, or at least the personal information.
Apart from stealing the sensitive user data, the malicious code can also be designed to alter or vandalize the content on a website. .
How to defend against XSS
The best measure to protect your website from these XSS attacks and ensure the safety of the user is the strong sanitization of user input. The website owners should harden the security of every path from where their sites are accepting the incoming data to proscribe these executable scripts.
Another preventive measure to ensure the user safety is to link the browser cookies credentials to his IP address. Though it isn’t a complete defense but it makes the process of accessing user cookies a bit difficult for the user.