VS2013, MVC, VB
I'm asking this question now because much time has passed since most of the posts that I read about XSS protection.
In the spirit of SO, my technical question is if someone can confirm that Microsoft's HtmlAgilityPack does not really do what AntiXSS does. I've read posts where people suggested that AntiXSS has problems, so they used htmlAgilityPack, but then the posts, including on SO, that state clearly they are not the same tool. That AntiXSS is what one would use for XSS protection.
If someone could clarify that I'd appreciate it.
A second, and not intended to be asking an opinion question per se, is to ask if the problems previously claimed against AntiXSS are by and large solved and is that the right tool to use for XSS protection when using MVC.
My intent is to use a whitelist approach for XSS protection.
Followed the guidance from this post as a basis for coding a whitelist filter using the html agility pack. The link shows a function used in a web pages approach, but the basic algorithm works fine coded in the controller of an MVC project to sanitize input from an RTF/WSIWYG editor (CKEditor)
Related
I've got a news-feed style field which admins can edit that will appear on users' pages. All users and all admins are approved so this is a pretty low-security affair.
Is there a simple, built-in way to validate their input for malicious script injection?
Microsoft Web Protection Library: http://wpl.codeplex.com/
It's not built-in, but it's highly regarded and built for ASP.NET
Unfortunately, I don't think there is anything out there that is both simple and mature - at the moment. You can give OWASP Enterprise Security API a try, but you'll unlikely be any happier than with WPL.
I'd recommend adhering to the OWASP XSS guidelines, but I suspect you're already familiar.
I know that Stack Exchange sites do not use the ASP.NET MVC built-in #Html.AntiForgeryToken() for the prevention of XSRF/CSRF attacks. Instead of creating a hidden input named __RequestVerificationToken with a really long value based on the machineKey section of the web.config, the Stack Exchange method creates an input named fkey with a MUCH more succinct value. This is apparently a Guid, and based on evidence from the Stack Exchange Data Explorer project on Google Code, this value is tied to each individual user, remaining fairly constant until you log in or out.
Also, the Stack Exchange value is constant on a page, and is made available to client script, so that Ajax posts for voting and things like that also use the token. By contrast
So why does Stack Exchange march to its own drummer?
Is there a reason not to trust AntiForgeryToken?
Does the AntiForgeryToken have some limitations that the Stack Exchange team was unwilling to accept? If so what were they?
Or maybe AntiForgeryToken just wasn't around (it started life in the MVC Futures project) when Stack Overflow was started, and if they had it to do over from scratch today they would use AntiForgeryToken?
I've been unable to find any blog posts from Jeff or others on the Stack Exchange team to explain the guiding principles behind how the XSRF-prevention policy on the SE network. It would be really nice if one of them could do a write-up, assuming of course that it could be done in general terms without creating a vulnerability. It would be really valuable information for those of us that want to make our websites secure, but aren't entirely comfortable just blindly trusting Microsoft to do it for us.
The one limitation we ran into with the default implementation was the lack of out-of-the-box support for AJAX calls. The hidden field approach works for sites that primarily deal with traditional form POSTs; but, not quite for AJAX heavy sites like SO.
We implemented the approach outlined in this CodeThinked blog post and we couldn't be happier. It looks like Phil Haack also supports this approach, based on his oct 2011 blog post
Couple of (unsolicited, I know!) pointers:
if you are running a web-farm, you should, of course use a static machinekey in your Web.config
Make sure all your servers have this KB installed. Otherwise, you may run into machinekey validation issues
It should be free. Easily integrable with asp.net mvc. Extremely light-weight. It must sanitize the input.
for example, say if the user enters
hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
It must not break the formatting of the page!
if the user enters some nasty html or maybe any html at all or any javascript code, it should reject that.
It would be awesome if it did some sort of cuss-word checking too, but that is not a requirement.
It can be jquery based.
Before you feel tempted to mark this question as duplicate, do check whether other questions are very old or something like that.
There are lots of RTEs that can be easily integrated into an asp.net page.There are many that are jquery based. See here I use server side code to sanitize. There are a number of classes that can be used to sanitize html. Run the user entered text thru the sanitizer to strip the markup.I am using http://roberto.open-lab.com/2010/03/04/a-html-sanitizer-for-c/
Jeff Atwoods code is here
Also see this SO post
What are security issues in asp.net mvc?! and does MVC solved XSS and the others?!
As jfar says: watch out for SQL injection. :-)
It helps by allowing you to use some specific pieces, but you still have to use them in appropriate places.
Use the new default <%: that Html Encodes the output
Use the anti forgery request token
Use Any of the provided data access solutions. At the lowest possible level, use .Parameters to pass parameters
Pay attention to every bit of guidance
don't dismiss security advisory published, as the recent one affecting asp.net in general: is-asp-net-mvc-vulnerable-to-the-oracle-padding-attack
You still have to understand & question the security aspects.
The same as any other website. Just like any other language or framework Sql Injection and Request Forgery are only solved if you implement measures to prevent it. XSS is solved only if you don't need to accept HTML input and disable XSS validation.
Don't get soft thinking MS provided all the answers. It still takes a keen eye for flaws and a rigid application of counter measures to keep things secure.
I'm looking for any experience someone can share regarding the usage of a rich text editor such as YUI's rich text editor. In particular I'm interested in how to deal with or prevent issues with
Cross site scripting
Image or attachment handling
Any similar questions you can provide links to or web articles would be appreciated.
The recommended way is to use whitelisting. We use Antisamy for it and some custom XPath Expressions. with antisamy you can define which tags and which attributes are allowed. For the attributes you can define lists of valid values or regular expressions which describe a valid value. The issue of cross site scripting can be mitigated quite good with whitelisting.
http://www.owasp.org/ has a lot of good resources and guidelines about web application security. (So you can read about more issues like Cross Site Request Forgery, SQL injection, ...)
What questions do you have about image or attachment handling?