Html.Raw and Xss

Prevent XSS attacks and still use Html.Raw

It isn't easy and you probably don't want to do this. May I suggest you use a simpler language than HTML for end user formatted input? What about Markdown which (I believe) is used by Stackoverflow. Or one of the existing Wiki or other lightweight markup languages?

If you do allow Html, I would suggest the following:

only support a fixed subset of Html
after the user submits content, parse the Html and filter it against a whitelist of allowed tags and attributes.
be ruthless in filtering and eliminating anything that you aren't sure about.

There are existing tools and libraries that do this. I haven't used it, but I did stumble on http://htmlpurifier.org/. I assume there are many others. Rick Strahl has posted one example for .NET, but I'm not sure if it is complete.

About ten years ago I attempted to write my own whitelist filter. It parsed and normalized the entered Html. Then it removed any elements or attributes that were not on the allowed whitelist. It worked pretty well, but you never know what vulnerabilities you've missed. That project is long dead, but if I had to do it over I would have used an existing simpler markup language rather than Html.

There are so many ways for users to inject nasty stuff into your pages, you have to be fierce to prevent this. Even CSS can be used to inject executable expressions into your page, like:

<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

Here is a page with a list of known attacks that will keep you up at night. If you can't filter and prevent all of these, you aren't ready for untrusted users to post formatted content viewable by the public.

Right around the time I was working on my own filter, MySpace (wow I'm old) was hit by an XSS Worm known as Samy. Samy used Style attributes with embedded background Url that had a javascript payload. It is all explained by the author.

Note that your example page says:

This page is meant to accept and display raw HTML by trusted editors.

The key issue here is trust. If all of your users are trusted (say employees of a web site), then the risk here is lower. However, if you are building a forum or social network or dating site or anything that allows untrusted users to enter formatted content that will be viewable by others, you have a difficult job to sanitize Html.

Why you should never use Html.Raw in your Razor views

原文有更多内容

So, what's wrong with `Html.Raw`?

In some cases, disabling HTML encoding is just unavoidable, for instance if the content is already encoded: not doing that would result in double-encoding.

So, why shouldn't you use Html.Raw in your views? It's actually all about intent: Html.Raw encourages developers to "disable" HTML encoding at the wrong layer (i.e in the view rather than in the controller itself) by declaring already-encoded HTML properties as simple string properties in their view model rather than as HtmlString properties.

Using this type instead of Html.Raw has two big advantages, that would have helped avoid this vulnerability in the first place:

By marking your view model properties as HtmlString, you force the developer in charge of maintaining the controller code to manually create a HtmlString instance from an existing string: new HtmlString(existingEncodedString). Technically, the result is exactly the same, but it's now clear by looking at either your view model or your controller code that a property is not a simple string, but something hightly susceptible of containing HTML payloads you should treat with extreme care.
HtmlString is not bindable: a form model containing a HtmlString will never be populated with user input. In this specific case, exploiting the bug wouldn't have been possible with HtmlString.

Please, do yourself a favor: stop using Html.Raw.

@Html.Raw(json) cross-site scripting trap

Is there a risk in using @Html.Raw?