A web application vulnerable to cross-site scripting (XSS) allows a user to inadvertently send malicious data to him or herself through that application. Attackers often perform XSS exploitation by crafting malicious URLs and tricking users into clicking on them. Learn about the server application risks that cross-site scripting can pose and some possible solutions available to you.
Contributed by Lisa Welch Rating: / 12 July 19, 2004
Cross-site scripting (XSS) attacks are a type of attack in which a variety of techniques are used to attempt to execute malicious script code by injecting it into form input, query strings, or cookies. If an attacker can successfully inject script into one of these areas, and your code processes it without validating or filtering the data, the script code can be executed, exposing your application data and more.
Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS) and cross site scripting. Some security people refer to Cross Site Scripting as XSS as well as CSS. If you hear someone say "I found a XSS hole", they are talking about Cross Site Scripting for certain.
XSS vulnerabilities are very often misunderstood and not given the due concern and attention they deserve. Simply put, a web application vulnerable to XSS allows a user to inadvertently send malicious data to him or herself through that application. Attackers often perform XSS exploitation by crafting malicious URLs and tricking users into clicking on them. These links cause client side scripting languages (VBScript, JavaScript, etc.) of the attacker’s choice to execute on the victim’s browser. XSS vulnerabilities are caused by a failure in the web application to properly validate user input. 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.
The most common web components that fall victim to XSS vulnerabilities include CGI scripts, search engines, asp pages, forms, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; XSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags.
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.
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:
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.
The first and most effective solution is to disable all scripting language support in your browser and email reader. But the method is not practical as almost all the websites need this to be enabled.
Reasonable caution should be taken when clicking links in anonymous e-mails and dubious web pages.
As a web user, you can’t do much to safeguard you against XSS but must pay extra attention while visiting new sites or following links posted on message boards and like. And as a rule never download files or follow links sent to you from some unknown source.
As a Web Developer:
As a first step, never compromise on validating input. If you are using post method for data submission then client side checks might be sufficient but it is all the more necessary to do server side validation if you are using Get method to retrieve data.
For efficiency reasons use both server side and client side scripting.
Even after all kinds of validation, do use some kind of HTML escaping must be done to avoid XSS.
As a .Net Web Developer
To protect against XSS attacks, the ASP.NET team has added a new feature to ASP.NET 1.1 called Request Validation. Request Validation checks the query string, form input, and other input data for indications of HTML elements, script blocks, or other potentially dangerous data. If such data is found, an exception of type HttpRequestValidationException is thrown.
Request Validation is enabled by default, and can be disabled either at the application level using the validateRequest attribute of the <pages> configuration element:
<page validateRequest="false"/>
Or at the page level using the validateRequest attribute of the @ Page directive:
<% @ Page ValidateRequest="false" %>
Note:
It is highly recommended that you do not disable Request Validation unless you have first ensured that all input to the page or application is being appropriately validated and/or filtered for potentially dangerous data. Failure to heed this recommendation can result in data loss or other serious security problems.
If ValidateRequest is true, entering dangerous data would give a server error whenever user tries to enter malicious data. But you may not want your users to get an impression that it is your server which is at fault rather than his/her input.
If you don’t want input to be validated, then use following strategies to cope up with XSS:
HTML encode Not a sure shot method but still it is helpful in minimizing the harms of attack.
Replace Use some kind of Replace function to remove special characters that you think can harm your website. I use following Replace function in my (C#) code. You can use Replace function provided to you VB.Net as well.
Call the function above for each of following special characters < > " ' % ; ) ( & + and corresponding string(strReplace) that will replace it according to your code.
I like to use some special replacement for the above characters that look like the above special characters but have different meaning for the browser. You can use anything you like:
strFind strReplace ‘ `(Character along with ~) “ `(Character along with ~) < «(ALT+174) > »(ALT+175)
Caution:
While using HTMLEncode() or Replace(), keep in mind that these function may result in increasing the length of string if strReplace is longer then strFind. And then may cause the SQL Server error. So, if you need to validate the length of string do it after HTMLEncode() or Replace() function calls.
CASE II: validateRequest="true"
If you are using default input to be validated, then use following strategies to cope up with XSS:
Still use the Replace function like the one above to tackle with problem of SQLInjection. Especially, for single quote character (‘) as it is used as a delimiter in SQL. Single Quote character is not validated for input by .Net.
To trap the default error message you can follow either of following two ways:
1. Page_Error Method: For individual page only. Use this method if you want to write different error messages depending on different web pages.
2. Application_Error Method: For application level. To be added to Global.asax file. Note: If you are building web project then code behind of global.asax has this method defined. Just add your function body to tackle with the problem. Otherwise create a Global.asax file using text editor and embed following code into it.
Use this method if you want to write common message for all the web pages.
Always Remember: Never display what user has entered without validating the input, even to let him know that he has tried XSS attack. If possible apply the Replace function even to the output.
Though I have taken every care in covering all the ways of XSS attack, never take this as if you will never be attacked by cross site scripting. XSS Lovers keep on finding new ways to implement cross site scripting attack.
Remedies as input validation and HTML escaping are a start, but they must be applied at all application points that accept data. An application with a single overlooked form field is just as insecure as one that does no checking whatsoever. This article doesn't cover the complete solution to XSS-style attacks -- I've only discussed the individual approach that users and Web developers can take. To insure that we always check our data ValidateRequest is developed.
Always do input validation.
If possible do output validation as well.
Never rely on client side scripting.
Avoid Get method for sending data.
Always use validateRequest=True;
Always replace ‘(single quote-if you are storing data in a database especially) to prevent SQL Injection.
Avoid using Cookies.
Always verify and check the lengths of string to safeguard against stack-overwriting attacks and SQL errors.
Keep yourself updated on the topic to know “Whether attackers have found a new way to implement cross site scripting attacks.”
Windows Security 
/ 12 
ASP.NET Export to Excel and Word using VB.NET and C#
