Cross Site Scripting
“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:
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.
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:
- Non Persistent scripts.
- Persistent Script.
- 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.
- 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.
- 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.
- 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.
Now you want some changes:
Response.Write(\\"Hello \\" + Request.QueryString(\\"fName\\"));
When you run this code you get the following output:
Here's some more that would produce the "Hello Lumpy" output:
But here is something dangerous!
now, the browser will popup a nice little box telling you "beotch"!
Check out this..
Now, Check out this next line...
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”:
!--Code to change the innerhtml of the sign out span with the alert(‘you cannot sign out of the system’);
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:
- Enocoding and Decoding of Tags if present in any input
- Disabling scripts
- 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:
<iframe src=http://ha.ckers.org/scriptlet.html <
many other ways even i dont know