XSS Attack: Tutorial and Protection

XSS Attack

XSS Attack-Tutorial and Protection
XSS Attack-Tutorial and Protection

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:

http://xyz.com/index.php?name=guest<script>alert(‘XSS’)</script>

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.

The basic defense technique to stop a XSS attack is contextual output encoding/escaping. There are several different escaping schemes that must be used depending on where the untrusted string needs to be placed within an HTML document including HTML entity encoding, JavaScript escaping, CSS escaping, and URL (or percent) encoding. As for the fact most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner.

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.

There are many tools specially developed for developers to test their websites for XSS vulnerabilities. For Firefox there is an addon called XSS Me. XSS-Me is the Exploit-Me tool used to test for reflected XSS vulnerabilities. It detects XSS vulnerabilities early in the development process will help protect a web application from unnecessary flaws. And for Google chrome users there is a plugin called DOM Snitch. DOM Snitch is an experimental Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. Developers and testers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or by pausing the execution of their application.

Author: Naveen Thakur

If you wish to write articles for Whitec0de Magazine, then Click Here.

  • Pingback: Top 5 Antivirus for Apple iPhone 5()

  • Pingback: Yahoo Mail XSS Vulnerability Leads To Hacking Of Accounts()

  • Pingback: After Facebook & Apple, Microsoft Computers Hacked()

  • abdul nazer

    It was helpful, but for me not getting pop up when I make try few Urls appended with string given above. Is there any restrictions like this string is work only for php site.

    Expecting repy
    Thanks in Advance

    Naz

    • karmicdice

      Nope, not just for PHP, it may even happen in JSP sites.. XSS is not language / scripting specific vulnerability. More than vuln, its a bug which programmer is expected to perhaps. Firefox and Chrome latest versions do not let running of JS from address bar… So high possibility that your attempt may be working but, is silent.

      • abdul nazer

        karmicdice : Thank you very much for the reply..

        I am new to this domain.

        “Firefox and Chrome latest versions do not let running of JS from address bar”
        Is that means we can’t exploit XSS vulnerability in latest versions of browser..?