Cross site scripting
|
|
Cross site scripting (XSS) is a type of computer security exploit where information from one context, where it is not trusted, can be inserted into another context, where it is. From the trusted context, an attack can be launched. Note that although cross site scripting is also sometimes abbreviated "CSS", it has nothing to do with the Cascading Style Sheets technology that is more commonly called CSS.
A classic example of cross site scripting is to supply parameters to a CGI script on a web site which cause the web site to emit bogus data. For example, the use of HTML client-side scripting language fragments in a web page parameter may insert this information into the rendered page, resulting in targeted web browsers executing the code.
This may be done by entering data into a web form on the site, for example as part of a bulletin board feature, or by publicly posting a URL which users are likely to click on, for example in e-mails or Usenet. Such a vulnerability in a web application can make phishing schemes more effective.
Note that despite the name, as example 2 demonstrates, this type of attack does not require the use of scripts.
Example 1:
- UserA trusts example.com to run JavaScript on his machine.
- UserB has found a way to inject/insert his/her own JavaScript code into example.com (for example into a bulletin board message) and inserts a malicious script that asks for people's credit card numbers and stores them somewhere where UserB can access them.
- UserA visits example.com and UserB's script asks for his/her credit card number. Thinking that this is a legitimate request from example.com, UserA blissfully provides his/her credit card number.
- UserB has effectively "stolen" UserA's credit card number using cross-site scripting and some social engineering.
Example 2:
- UserA has an account at example.com and is logged in.
- UserB has found a way to inject/insert his/her own HTML into example.com (for example into a bulletin board message) and inserts a form that asks for people's credit card numbers and stores them somewhere where UserB can access them.
- UserA visits example.com and UserB's form asks for his/her credit card number. Thinking that this is a legitimate request from example.com, UserA blissfully provides his/her credit card number.
- UserB has effectively "stolen" UserA's credit card number using cross-site scripting and some social engineering.
Example 3:
- UserA has an account at example.com and is logged in.
- UserB injected a piece of JavaScript to retrieve the session ID of the current user and send it to him/her.
- UserA visits the manipulated page and his/her session ID is transmitted to UserB.
- UserB can now use UserA's account until he/she logs out (possibly longer if he/she changes UserA's password).
If UserB had put the code on his own website, it would not be allowed to access the session-cookie.
The name "cross site" derives from the way the attack is directed "across" the web-site, from the attacking data source to the attacked browser.
External links
- http://httpd.apache.org/info/css-security/
- http://www.cert.org/advisories/CA-2000-02.html
- XSS FAQ (http://www.cgisecurity.com/articles/xss-faq.shtml)
- http://www.shocking.com/~rsnake/xss.html
- XSS Cheatsheet (http://ha.ckers.org/xss.html)
- The CSS Blacklist (http://www.pointblanksecurity.com/xss/)
Current Blacklist (http://pointblanksecurity.com/xss/xss2.php)
de:Cross-Site Scripting ja:クロスサイトスクリプティング pl:Cross Site Scripting