EXPERT RESPONSE
Fundamentally, guarding against cross-site scripting (XSS) attacks in ASP.NET is done just as it is on any other platform: you must confirm that inputs are valid and encode any user-supplied data that is echoed back to the browser. Fortunately, ASP.NET provides a number of facilities that help. These include blocking of some suspicious inputs at the platform level, the Validator framework, and the built-in Web user interface (UI) controls.
Firstly, the ASP.NET runtime provides some trapping of certain suspicious HTTP input signatures such as "<SCRIPT>." These are detected by the platform before your Web form code even begins to execute and an exception is thrown. This can help protect against many link-based XSS attacks, but alone does not make the platform completely safe.
This built-in protection only works on inputs passed to a given Web form and does not protect against attacks that may be delivered by data from another source such as a database table. Also, this only detects known "bad" inputs so new methods of encoding XSS attack inputs will still get by. It is much more secure to validate all inputs as being "good." For example, if an input is expected to be alphanumeric, then it should be explicitly checked to meet this criteria and XSS-enabling characters such as < should not be present.
This is where the Validator framework comes in. The ASP.NET Validator framework makes it easy for developers to ensure that user inputs fall within approved guidelines. Validator controls are attached to Web controls and perform validation on both the client- and server-sides. There are a number of different ready-built Validators available and you can create your own as well. Of particular interest is the RegexValidator because it allows for the flexibility and power of regular expressions to be used in validating user inputs.
The built-in Validator framework helps to keep bad data from being passed to your application, but the ultimate defense against XSS attacks is to ensure that suspicious data is properly HTML-encoded before it is echoed back to the browser. To this end, ASP.NET provides built-in UI controls such as the TextBox and DropDownList that will automatically HTML-encode their .Text or other fields when they are rendered to HTML. Be careful of Literal controls, however. These are rendered "literally" to the HTML stream. If you must send suspicious data back to the browser without the benefit of the built-in controls, the HttpServerUtility.HtmlEncode method can be used to properly encode text so that it will render correctly in browsers.
Again -- ASP.NET does provide some handy tools and features for protecting against XSS attacks, but the responsibility ultimately rests on the developer to ensure that inputs are properly validated and that data displayed to the browser is correctly escaped.
More information:
|
