views:

33

answers:

3

Hi, I have a webforms applications. There is a page with textboxes and users enters search terms into these which are used to query the database.

I understand I need to prevent javascript injection attacks?

How do I do this?

In MVC I would use Html.Encode. It doesn't seem to be recognising it here.

Thanks!

A: 

You can use Server.HtmlEncode (which translates to HttpServerUtility.HtmlEncode) , but there is a better tool.

There is a Web Application Security library that you can download from Microsoft that includes a utility that uses a white-list approach to HtmlEncoding (much safer and better, and recommended by OWASP although they point to an older version). It also has tools that allow you to get safe HTML fragments, etc.

http://blogs.msdn.com/b/securitytools/archive/2010/09/30/antixss_2D00_4_2D00_0_2D00_release_2D00_notes.aspx

You can get it here: http://wpl.codeplex.com/

If you look at nothing else, however, take a look at the OWASP top 10. It sounds like you're just scratching the surface of web app security, and this is the best resource out there. Cross-Site Scripting attacks are just one of a whole slew of things you need to defend against.

It's also the one you will need to conform to if you have to deal with any sort of compliance (PCI, Red flag, etc)

http://www.owasp.org/index.php/Top_10_2010

David Stratton
I'm sorry, but anti-XSS input filtering is seriously not at all a substitute for HTML-encoding plain text at the output-to-HTML stage. All anti-XSS tools are fragile, mangle valid input and incomplete: at best a sticking plaster for poorly-written apps with HTML-escaping issues and not a cure that actually addresses the problem.
bobince
Please comment if you're downvoting so I can learn from my mistakes...
David Stratton
(Sorry for the -ve, but it's a serious problem with naïve webapp authors that they're sticking together various forms of output from text strings with no HTML-escaping, JSON-encoding, URL-encoding or whatever other type of context-sensitive-encoding is required for the particular task. Then they expect an input-filtering anti-XSS layer to somehow fix it all up. This is doing no more than brushing the problems under the rug.)
bobince
Agreed that he should not be filtering at the input stage but should be filtering at the output stage. 100% accurate. The OWASP guide that I linked to covers this. I merely suggest that the AntiXss library, with the whitelist validation, does a better job at this than the Server.HtmlEncode. I also agree that naive web app authors don't do security properly. This is also why I pointed him to the OWASP top 10 and my answer included "You're barely scratching the surface". But, fair point, and thanks for the feedback!
David Stratton
Yeah, the OWASP guide, especially the “You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into” section, is spot on. And ah, yeah, if you're talking about the escaping functions in AntiXSS, I suppose they're fine; I'll take back the -ve (though for me it's not clear what they really offer over .NET's existing escaping functions). It's the other automated nonsense in the library I take exception to.
bobince
A: 

You can use HttpUtility.HtmlEncode: http://msdn.microsoft.com/en-us/library/system.web.httputility.htmlencode.aspx

Badaro
A: 

On webforms you can call

HttpUtility.HtmlEncode(foo);

Be careful to not double encode.

Equiso