Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Symantec as of 2007.[1] Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by the site's owner.( copy from :http://en.wikipedia.org/wiki/Cross-site_scripting)
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.
Example of a Cross Site Scripting attack
As a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for.
Example:
Search Results for "XSS Vulnerability"
To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like:
http://test.searchengine.com/search.php?q=XSS%20
Vulnerability
Next we try to send the following query to the search engine:
By submitting the query to search.php, it is encoded and the resulting URL would be something like:
http://test.searchengine.com/search.php?q=%3Cscript%3
Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%2
9%3C%2Fscript%3E
Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability.
^_^(copy from:http://www.acunetix.com/websitesecurity/cross-site-scripting.htm)
Exploit scenarios
Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the cast of characters commonly used in computer security.
Non-persistent:
1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.
2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website, but will contain Mallory's malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bob's website.
5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc) without Alice's knowledge.
Persistent attack:
1. Mallory posts a message with malicious payload to a social network.
2. When Bob reads the message, Mallory's XSS steals Bob's cookie.
3. Mallory can now hijack Bob's session and impersonate Bob.[16]
^_^(copy from:http://en.wExploit scenariosAttackers intending to exploit cross-site scripting)
NEW Case of Cross -Site Scripting
On the 9th of April 2010, Apache.org infrastructure suffered a direct and targeted attack on the server hosting the Apache issue-tracking software, Atlassian JIRA. This is the second major compromise the Apache Software Foundation suffered in less than a year, when last August, the main Apache Foundation website was also hacked.
The attackers crafted an attack by exploiting a cross-site scripting vulnerability in JIRA software via a TinyURL redirect. Thanks to this attack, the attackers managed to gain root access to brutus.apache.org, the server hosting Atlassian JIRA, Bugzilla and Confluence software. By gaining root access to brutus.apache.org, the attackers managed to get a hashed copy of the user passwords of JIRA, Bugzilla and Confluence.
^_^ copy from (http://www.acunetix.com/blog/web-security-zone/articles/xss-to-root-apache-org/) Read more this at www.acunetix.com
