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?

@Html.Raw will allow executing any script that is on the value to display. If you want to prevent that you need to use @Html.AttributeEncode

 

 

which one fix  @Html.Raw(Model.Content)

A.<span>@Html.Raw(Model.Content)</span>
B. @Html.DisplayTextFor(p => p.Content)
C. @Html.Raw(Microsoft.Security.Application.Encoder.CssEncode(Model.Content))
D. @(new HtmlString(Model.Content))
explain the reason

The correct option to fix @Html.Raw(Model.Content) is:

D. @(new HtmlString(Model.Content))

Here's the reasoning behind it:

1. Option A: <span>@Html.Raw(Model.Content)</span>
   This option wraps @Html.Raw(Model.Content) with an HTML <span> element. While this will render the content correctly as raw HTML, it introduces an additional <span> element that may not be necessary depending on the context.

2. Option B: @Html.DisplayTextFor(p => p.Content)
   This option uses @Html.DisplayTextFor which is used for rendering plain text and doesn't interpret any HTML. It won't fix the issue of rendering HTML content as intended.

3. Option C: @Html.Raw(Microsoft.Security.Application.Encoder.CssEncode(Model.Content))
   This option uses Microsoft.Security.Application.Encoder.CssEncode which is used to encode CSS content, not HTML content. It's not suitable for rendering HTML.

4. Option D: @(new HtmlString(Model.Content))
   This option creates a new instance of HtmlString, which is a type that allows you to render raw HTML content. This is the correct way to render HTML content from a string in Razor syntax.

   Using @(new HtmlString(Model.Content)) ensures that the Model.Content is treated as raw HTML and will be rendered as intended.

It's worth noting that Html.Raw also serves a similar purpose, but HtmlString is considered more explicit and safer in some contexts because it explicitly marks the content as raw HTML.

So, in summary, option D is the correct one for fixing @Html.Raw(Model.Content).

 

 

 

 

作者:Chuck Lu    GitHub