5

From what I understand about what ASP.NET does and my own personal testing of various XSS tests, I found that my ASP.NET 4 website does not require any XSS prevention.

Do you think that an ASP.NET 4.0 website needs any added XSS security than its default options? I cannot enter any javascript or any tags into my text fields that are then immediately printed onto the page.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Dexter
  • 6,170
  • 18
  • 74
  • 101

2 Answers2

10

Disclaimer - this is based on a very paranoid definition of what "trusted output" is, but when it comes to web security, I don't think you CAN be too paranoid.

Taken from the OWASP page linked to below: Untrusted data is most often data that comes from the HTTP request, in the form of URL parameters, form fields, headers, or cookies. But data that comes from databases, web services, and other sources is frequently untrusted from a security perspective. That is, it might not have been perfectly validated.

In most cases, you do need more protection if you are taking input from ANY source and outputting it to HTML. This includes data retrieved from files, databases, etc - much more than just your textboxes. You could have a website that is perfectly locked down and have someone go directly to the database via another tool and be able to insert malicious script.

Even if you're taking data from a database where only a trusted user is able to enter the data, you never know if that trusted user will inadvertently copy and paste in some malicious script from a website.

Unless you absolutely positively trust any data that will be output on your website and there is no possible way for a script to inadvertently (or maliciously in case of an attacker or disgruntled employee) put dangerous data into the system, you should sanitize all output.

If you haven't already, familiarize yourself with the info here: https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

and go through the other known threats on the site as well.

In case you miss it, the Microsoft.AntiXss library is a very good tool to have at your disposal. In addition to a better version of the HtmlEncode function, it also has nice features like GetSafeHtmlFragment() for when you WANT to include untrusted HTML in your output and have it sanitized. This article shows proper usage: http://msdn.microsoft.com/en-us/library/aa973813.aspx The article is old, but still relevant.

David
  • 72,686
  • 18
  • 132
  • 173
  • Yes, so what's the best way to sanitize, I feel like ASP.NET already sanitizes ALL input from text boxes already, so I don't know why I need to do anything extra. What should I do then, Html.Encode() all textbox data being printed on the page? I thought ASP.NEt already did this. – Dexter Aug 01 '11 at 20:39
  • I added another paragraph at about the time you were typing the comment - that paragraph answers the question. – David Aug 01 '11 at 20:41
  • 1
    ASP.NET does NOT sanitize data from textboxes - it FILTERS what can come IN. Santiization is done as output is being displayed back OUT from the server to the user. – David Aug 01 '11 at 20:43
  • Someone said that microsoft AntiXSS is a bit of overkill and unnecessary on another page in this site because standard ways of filtering with HtmlEncode etc are good enough. – Dexter Aug 01 '11 at 20:44
  • I'd disagree - with good reason - see my answer to a question on that subject here: http://stackoverflow.com/questions/1608854/what-is-the-difference-between-antixss-htmlencode-and-httputility-htmlencode/1608932#1608932 – David Aug 01 '11 at 20:45
  • Yes, that's what I said, it filters the input. If I'm filtering data being input by the user, then I have done my job of preventing XSS. And ASP.NET already does this right? Unless there are very well known huge loopholes in ASP.NET's standard filtration, then why would extra security be necessary (other than to be extra cautious)? – Dexter Aug 01 '11 at 20:47
  • Oh, and I'm not saying Anti-XSS library is bad, I'm sure it's more secure than the ASP.NET framework, but I'm not looking for maximum security, I just want to make sure much of the common XSS methods will not work. – Dexter Aug 01 '11 at 20:49
  • I think you may have missed the point that your asp.net application may not be the only method that can be used to input data. If you have an MSSQL database and your web app is putting data into it, there's nothing your app has done to prevent me opening the SQL Server Management Studio and entering malicious data through that. Then when your web app shows the page with that data, the XSS attack will be successful. – David Aug 01 '11 at 20:51
  • As the website developer it is your job to prevent your web app from outputting potentially unsafe data regardless of where the data came from. However, this is up to you to determine if there ARE other potential inputs to your system. – David Aug 01 '11 at 20:51
  • Right, I don't think database access is an issue. I'd prefer it if there was an output function specifically designed for XSS filtering, but it seems the only way to fully prevent all XSS would be to get the AntiXSS library since you are saying HtmlEncode is not enough. – Dexter Aug 01 '11 at 20:56
  • HtmlEncode is enough for most cases, but the AntiXss library is better and has more features. Certainly using Server.HtmlEncode() is acceptable if you can't for some reason use the AntiXss library from Microsoft. – David Aug 02 '11 at 15:38
4

Sorry Dexter, ASP.NET 4 sites do require XSS protection. You're probably thinking that the inbuilt request validation is sufficient and whilst it does an excellent job, it's not foolproof. It's still essential that you validate all input against a whitelist of acceptable values.

The other thing is that request validation is only any good for reflective XSS, that is XSS which is embedded in the request. It won't help you at all with persistent XSS so if you have other data sources where the input validation has not been as rigorous, you're at risk. As such, you always need to encode your output and encode it for the correct markup context (HTML, JavaScript, CSS). AntiXSS is great for this.

There's lots more info specifically as it relates to ASP.NET in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS).

Troy Hunt
  • 20,345
  • 13
  • 96
  • 151
  • And what if AntiXSS is not an option, what then? – Dexter Aug 02 '11 at 14:13
  • If AntiXSS is not an option use Server.HtmlEncode(). It's less flexible and powerful than the Microsoft.Applicaiton.Security.AntiXss.HtmlEncode() but it is a step in the right direction. – David Aug 02 '11 at 15:37
  • As David says, but also keep in mind there are no native .NET methods to encode for JavaScript or CSS so depending on your context, you may have a problem. But why would AntiXSS not be an option? – Troy Hunt Aug 02 '11 at 20:13
  • `inbuilt request validation .. whilst it does an excellent job, it's not foolproof -` could you please base your claim by giving some example? I tested various combinations and .net denied them all? (And I'm not talking about the second part of your answer about data coming from other data sources or somebody hacking directly to the db) – BornToCode Jul 05 '12 at 13:38
  • 2
    Sure, here's on example: http://www.portcullis-security.com/184.php Remember, there are many, many XSS vectors and a lot of them are not "valid" HTML and they behave differently in different browsers. Here are some good examples: http://ha.ckers.org/xss.html – Troy Hunt Jul 06 '12 at 21:35
  • OK, thank you for those examples, forgive me if I'm nagging, but the first example won't work in asp.net 4 (it's vulnerable only in .net 2 as stated there). The second link did prove me that if I allow SOME tags then I could be in trouble, but if I allow no tags (and by default it seems that .net 4 denies any tag), it makes the impression that it's pretty safe - the xss's from the second link didn't worked either, am I still missing something here? (thank you for your patience) – BornToCode Jul 08 '12 at 14:09
  • @Troy Hunt - What XSS Vulnerabilities does asp.NET 4.0 handle out of the box? – Ryan S Nov 16 '12 at 14:28
  • Natively, it has fairly rudimentary support for intercepting HTTP requests with script tags and a few other typical XSS patterns. Try loading a web forms page ad appending ? – Troy Hunt Nov 17 '12 at 21:25