Paranoia: Cross Site Scripting

[ArticleBot]

This is a dedicated thread for discussing the SitePoint article 'Paranoia: Cross Site Scripting'

[mmj]

An informative article. I see it as a rather long-winded way of saying "always validate your input".

Cross site scripting is a relatively harmless side-effect of not validating your input. Other side effects can be much worse. I'm referring to situations where you are using an input variable as part of a database query, or you are evaluating a string.

In my scripts (I use PHP), I use a function I created called load_var() to fetch variables from input variables, and validate them at the same time. For example, load_var('name', 'REQUEST', 'title') loads the variable 'name' from the request fields, and validates it against a pattern I have called 'title'. The 'title' pattern includes all letters, digits, spaces, and a few punctuation marks. If the variable contains any other digits, my function returns false. I have patterns for int, yesno, float, and so on. One pattern is called string, and it can include any data at all.

I think it's good practice to create a function like this. If you change your pattern matching requirements, for example, if you want to start allowing underscores in names, you only have to modify the validation code in one place.

[archigamer]

if you are using asp.net properly (like not using Response.Write) you do not have to worry about this as much.

asp.net helps safeguard against this. one example can be seen in this thread

http://www.sitepointforums.com/showt...hreadid=125914

[cejua]

Originally Posted by archigamer

if you are using asp.net properly (like not using Response.Write) you do not have to worry about this as much.

asp.net helps safeguard against this. one example can be seen in this thread

http://www.sitepointforums.com/showt...hreadid=125914

Yes - I think by default asp.net will not allow suspect stuff like opening and closing script tags (< ... >) in the address bar or submitted input fields which is a very good thing to have.

Also if you stick to using stored procedures and passing data via parameters, and execute permissions are only given to the sprocs, then potential for cross scripting is reduced.

This article on MSDN is pretty good. Framework 1.0 doesn't have ValidateRequest=true (it was introduced in 1.1) but you can implement it yourself if need be:
http://msdn.microsoft.com/asp.net/de...protection.asp