Cross Site Scripting (XSS): An Overview - The Threats of Cross-site Scripting
(Page 2 of 5 )
Cross-site scripting poses server application risks that include, but are not limited to, the following:
- Users can unknowingly execute malicious scripts when viewing dynamically generated pages based on content provided by an attacker.
- An attacker can take over the user session before the user's session cookie expires.
- An attacker can connect users to a malicious server of the attacker's choice.
- An attacker who can convince a user to access a URL supplied by the attacker could cause script or HTML of the attacker's choice to be executed in the user's browser. Using this technique, an attacker can take actions with the privileges of the user who accessed the URL, such as issuing queries on the underlying SQL databases and viewing the results and can exploit the known faulty implementations on the target system.
- An attacker can easily change the appearance of site when the inputted data is displayed (e.g. simply by introducing a </table> tag)
- He can display the wrong information through your site to cause even more damage.
- SQL Injection (Related but different threat.)
And there are many more ways you can think of.
If you still think “BUT WHY SHOULD I CARE??”, then read the following to know what can be the consequences. If you don’t care:
Malicious attacks on Web sites are an industry-wide problem, bringing down Web servers, disrupting online commerce, and threatening users' personal data. The attacker gains the ability to capture the session information, peer into private user details such as ID, passwords, credit card information, home address and telephone number, social security/tax IDs, and so on. If the targeted Web site doesn't check for this type of malicious code, misuse of the user is probable. An attacker can capture the user's session and steal the user's credentials, redirect to a page on another Web site, and then insert code that can poison cookies, expose SSL connections, access restricted or private sites, or even trigger a number of such attacks.
Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks.
An Example:
Suppose we have an ASP page called hello.asp that displays everything posted to it on As Input as Output basis.
<%Response.Write (“hello ”+Request.QueryString) %>
Contents of file hello.asp
If we use following as input:
/hello.asp?Jack
This would print ”hello Jack” on the page.
Now comes some crook minded that input the following:
/hello.asp?<B>Fool</B><script>window.close()</script>
This would print “hello Fool” and then tries to close the window.
Still no problem if this page is used only for that crook. But if we use this kind of code on a message board, this would certainly cause a problem for each user visiting the board.
This would be fatal if he tries to enter something like this:
/hello.asp?<script>window.location=”Some fatal Location;”</script>
This would redirect the browser to location specified in string. That can be even the link to some executable like www.foo.com/virus.exe and a user who is surfing your site and does trust it, he may even download the file and then BANG.
Now you can think of what can be done using XSS.
I had written one of the most basic and non fatal example because I don’t want you to use this article for learning how to cause XSS attacks.
This can also be done if user submitted information even using post is displayed back on your page without any validation.
Next: Possible Solutions >>
More Windows Security Articles
More By Lisa Welch
