In a recent study I found on esecurityplanet.com, over 75% of all the websites on internet are vulnerable to XSS attack. WOW terrifying right?? XSS attack commonly known as Cross Site Scripting is a type of computer security vulnerability typically found in Web applications, such as web browsers through breaches of browser security, which enables attackers to inject client-side script into Web pages viewed by other users. XSS attacks exploit the relationship between the user and the web site he or she is accessing. When you visit a web site, there is a presumption that the data transferred between your browser client and the web server is visible only to the owner of the web site and its authorized partners. But when an XSS attack muscles its way into this relationship, it can expose data to a malicious third-party – without the knowledge of either the end-user or web site owner.
XSS attack effect may range from a petty low to a severe security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security measures taken by the website owner.
XSS- Cross Site Scripting is of two types
1) Non Persistent XSS Attack
2) Persistent XSS Attack
Non-Persistent XSS Attack:
In Non-persistent XSS attack (Reflected XSS), It is mandatory foe a user to visit the specially created link by the attacker. When the user visits the link, the code will start its work and will get executed by the user’s browser. Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding, may lead to markup injection. A classic example of a potential vector is a site search engine: if one searches for a string, the search string will typically be redisplayed verbatim on the result page to indicate what was searched for. If this response does not properly escape or reject HTML control characters, a cross-site scripting flaw will be there. A reflected or non-persistent attack is typically delivered via email or a neutral web site. The bait is an innocent-looking URL, pointing to a trusted site but containing the XSS vector. If the trusted site is vulnerable to the vector, clicking the link can cause the victim’s browser to execute the injected script.
Let us take a closer look on this attack.
A simple XSS attack will look like this:
Even though this URL doesn’t do any damage or harm to the website other than the annoying ‘XSS’ pop-up, but an attacker can use this method to do several damaging things. Like he can redirect you to some phishing website or force you to download something which might harm your computer or even grab your cookies.
Persistent XSS attack:
The basic working of both persistent and non-persistent is same. i.e. to wrap the malicious code into a website page so that it satisfies the browser. The attacker plans the code in the website same as it did earlier in non-persistent attack. The only difference this time is that the attack this time will be permanently stored in the server.
Malicious code can also be designed to alter the content on the page presented to the site visitor. One nasty trick would be to change the destination of a link on the page (or present a new link that the visitor is urgently told to click), baiting them into visiting a malicious site fully engineered by the attacker to launch a more serious attack. According to OWASP “The difference is in how the payload arrives at the server. Do not be fooled into thinking that a “read only” or “brochureware” site is not vulnerable to serious reflected XSS attacks. XSS can cause a variety of problems for the end user that range in severity from an annoyance to complete account compromise. The most severe XSS attacks involve disclosure of the user’s session cookie, allowing an attacker to hijack the user’s session and take over the account. Other damaging attacks include the disclosure of end user files, installation of Trojan horse programs, redirect the user to some other page or site, or modify presentation of content. An XSS vulnerability allowing an attacker to modify a press release or news item could affect a company’s stock price or lessen consumer confidence. XSS vulnerability on a pharmaceutical site could allow an attacker to modify dosage information resulting in an overdose.”
How to Protect from XSS attack?
Both XSS and SQL are very similar in nature because of the fact that both happen due to sanitized data input. So basically to stop an attack like XSS the best way to defend against it is through testing what all user input is coming.
At the end encoding proves to be quite secure against XSS attack.
You should check every input path by which the web site accepts incoming data. Each page must be encoded against malicious data that can represent executable code in the web page. You can do it by implementing multiple filters along the communication pathway – for example, a web application firewall such as ModSecurity plus input sanitization within server-side input processing code.
Author: Naveen Thakur