Skip to content

By default, RazorEngine will not encode values to be HTML safe #65

Closed

Description

@304NotModified

From https://github.com/adoconnection/RazorEngineCore/wiki/@Raw

By default, RazorEngine will not encode values to be HTML safe, you need to escape values by yourself

I think this is a security issue. It's really unexpected and I'm sure many won't see this warning at all.

Please change the default in the next major version

Activity

  1. 304NotModified commented on Jul 22, 2021

    @304NotModified
    ContributorAuthor

    I think at least RunHtmlSafe should be included in this library. (also Aysnc stuff). Is a PR accepted for that?

  2. adoconnection commented on Jul 23, 2021

    @adoconnection
    Owner

    HtmlSafeAnonymousTypeWrapper is not a correct way of secure html encoding as there is a difference between encoding html and its attributes. Right way is implemented in https://github.com/wdcossey/RazorEngineCore.Extensions

    I did not include @Html.Raw for several reasons:

    1. Microsoft RazorEngine itself does nothing for web safety, therefore its wrapper should keep this behavior.
    2. RazorEngine is not MVC thats why there are no MVC helpers like @html and it does not inherit MVC behavior.
    3. The idea is to keep this library light and super extensible

    Could you please share what are you going to use RazorEngine for?
    also, what Asyncs do you miss? separate issue would be nice

  3. 304NotModified commented on Jul 28, 2021

    @304NotModified
    ContributorAuthor

    Could you please share what are you going to use RazorEngine for?

    We're creating HTML and render it to a pdf. Also in the PDF you could add javascript. Javascript is now disabled in the PDF, but we really prefer multiple lines of defense (LoD)

    also, what Asyncs do you miss? separate issue would be nice

    Of the RazorEngineExtensions for https://github.com/adoconnection/RazorEngineCore/wiki/@Raw - but maybe that isn't really a good solution.

    Right way is implemented in https://github.com/wdcossey/RazorEngineCore.Extensions

    I don't really see how I could RazorEngineCore.Extensions for that, as I want this to be safe:

    Hello @Model.name
    

    where Model.name could have the content <script>alert('oops')</script>. I really not preferring wrap them all in @Html.Encode...

    1. Microsoft RazorEngine itself does nothing for web safety, therefore its wrapper should keep this behavior.

    Good one, unfortunately almost every example of razor is in combination with MVC and so Html Encoding. E.g. https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor?view=aspnetcore-5.0#expression-encoding
    (the URL says MVC, the breadcrumb not)

  4. adoconnection commented on Jul 29, 2021

    @adoconnection
    Owner

    And the PDF content is based upon user input, right?

    I don't really see how I could RazorEngineCore.Extensions for that, as I want this to be safe:

    this is exactly what RazorEngineCore.Extensions does:

    image

  5. 304NotModified commented on Jul 29, 2021

    @304NotModified
    ContributorAuthor

    Ah thx. I checked also the code today and I doubt if this works for strong typed compiled models. But will test that. Hopefully before the weekend :)

  6. adoconnection commented on Aug 12, 2021

    @adoconnection
    Owner

    Don't panic :)

    First of all, I have updated @Raw wiki it now contains code on how to make RazorEngine 100% HTML safe with few lines of code.
    Your complaints and my replies combined have more text than the code that solves this problem ;)

    The long answer

    If you ever had a chance to work with classic ASP, you know there was a pain: devs had to encode literally every their output

    <%= Server.HTMLEncode(myVariable) %>

    it was very unhandy since in web you have to encode any user content.

    Skipping webforms, fast forward to ASP.NET Razor

    decades later you still have to encode every user content in web environment, so they decided to make razor html safe by default. Because encoding your output is primary usecase. And occasionaly you need to write unsafe html content where @Html.Raw comes in.

    Detached RazorEngine has no primary usecase

    It can be used in

    • CMS scenarios
    • Emailing with user content
    • Emailing without user content
    • Processing CSS/JS/other text

    So as you see HTML safety does not applies everywhere.
    In fact I have 3 projects using RazorEngine and HTML safety is not required in any of them. Moreover It would become a pain as I always have to render raw html or text.

    Think this way: What if RazorEngine were to render LaTeX templates and values there have to be encoded in completely different way. I dont think it has to be included as default feature. So the HTML safety.

  7. benmccallum commented on Aug 13, 2021

    @benmccallum

    Amazing, thanks @adoconnection!

    I think your approach here is reasonable and I understand your reasoning for keeping the core job of this framework focused. I would suggest though that you highlight the default behaviour really clearly on the README as it's so easy for people to not understand or forget about html encoding and if the default behaviour leads them down the "wrong" track when generating HTML, it'll just be too easy for folks who aren't paying attention to end up in a bad place. Maybe it's literally a section titled "HTML generation and security" that's got some warning bells on it or something :P And just links to the @Raw docs.

    Gonna migrate our RazorEngine project over today to RazorEngineCore and see how I go!

    Thanks again :)

  8. 304NotModified commented on Aug 13, 2021

    @304NotModified
    ContributorAuthor

    Great answer!

    Think this way: What if RazorEngine were to render LaTeX templates and values there have to be encoded in completely different way.

    I think also html encoding should be enabled by default if you could disable it. It's one of the secure design principles: https://en.m.wikipedia.org/wiki/Secure_by_default

    Security by default, in software, means that the default configuration settings are the most secure settings possible, which are not necessarily the most user-friendly settings

  9. adoconnection commented on Aug 14, 2021

    @adoconnection
    Owner

    I have updated readme to avoid confusion.

    I would argue. Default installation of MongoDB will let anyone on the internet to connect to it. ELK does not have HTTPS by default. Rediculous! But im trying to say that there are things not intended to use by newcomers.

    ASP.NET on the other hand is intended for use by rookies.
    Come on, if you dont test XSS and other various attacks and rely on third parties you better quit programming until its not to late :)

    One can not make secure angle grinder. New users will still chop their fingers, and others will be annoyed.

  10. benmccallum commented on Oct 29, 2021

    @benmccallum

    @adoconnection , I seem to have a problem after following the layout + html safe templating docs whereby the @RenderBody() portion is html encoded... any suggestions?

    It's like it's encoding the @RenderBody() part when it's already safe/encoded.

    Edit:
    I think I have a solution, shout out if I'm missing any issues though.

    1. Modify MyTemplateBase<T> Include and RenderBody methods to return object and be virtual.
    2. Modify MyHtmlTemplateBase<T> (which inherits MyTemplateBase<T>) by overriding those two methods and have them return Raw(base.Include/RenderBody);.
    3. Need to move RawContent into its own internal class as it was previously private inside MyTemplateBase.

    Like this, when WriteAsync is called with the RenderBody() or Include() result, it's already a RawContent and the avoidance of html encoding happens.

    Hope that helps someone else. Almost wonder if it's worth adding this into the docs.

  11. 304NotModified commented on Oct 30, 2021

    @304NotModified
    ContributorAuthor

    @benmccallum we have the same issue here. We fixed it by not using template rendering in the layout page except @renderbody (and guaranteed it with units tests to be safe)

    I think your solution could work, it would be great to have it & document it 👍

  12. benmccallum commented on Nov 3, 2021

    @benmccallum
  13. adoconnection commented on Nov 30, 2021

    @adoconnection
    Owner

    this issue seems to be resolved

  14. 304NotModified commented on Dec 1, 2021

    @304NotModified
    ContributorAuthor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions