You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
By default, RazorEngine will not encode values to be HTML safe #65
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
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.
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!
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
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.
@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.
Modify MyTemplateBase<T> Include and RenderBody methods to return object and be virtual.
Modify MyHtmlTemplateBase<T> (which inherits MyTemplateBase<T>) by overriding those two methods and have them return Raw(base.Include/RenderBody);.
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.
@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 👍
Activity
304NotModified commentedon Jul 22, 2021
I think at least RunHtmlSafe should be included in this library. (also Aysnc stuff). Is a PR accepted for that?
adoconnection commentedon Jul 23, 2021
HtmlSafeAnonymousTypeWrapperis 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.ExtensionsI did not include
@Html.Rawfor several reasons:@htmland it does not inherit MVC behavior.Could you please share what are you going to use RazorEngine for?
also, what Asyncs do you miss? separate issue would be nice
304NotModified commentedon Jul 28, 2021
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)
Of the RazorEngineExtensions for https://github.com/adoconnection/RazorEngineCore/wiki/@Raw - but maybe that isn't really a good solution.
I don't really see how I could RazorEngineCore.Extensions for that, as I want this to be safe:
where
Model.namecould have the content<script>alert('oops')</script>. I really not preferring wrap them all in@Html.Encode...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)
adoconnection commentedon Jul 29, 2021
And the PDF content is based upon user input, right?
this is exactly what
RazorEngineCore.Extensionsdoes:304NotModified commentedon Jul 29, 2021
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 :)
adoconnection commentedon Aug 12, 2021
https://github.com/adoconnection/RazorEngineCore/wiki/@Raw
adoconnection commentedon Aug 12, 2021
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
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.Rawcomes in.Detached RazorEngine has no primary usecase
It can be used in
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.
benmccallum commentedon Aug 13, 2021
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 :)
304NotModified commentedon Aug 13, 2021
Great answer!
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
adoconnection commentedon Aug 14, 2021
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.
benmccallum commentedon Oct 29, 2021
@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.
MyTemplateBase<T>Include and RenderBody methods to returnobjectand be virtual.MyHtmlTemplateBase<T>(which inheritsMyTemplateBase<T>) by overriding those two methods and have themreturn Raw(base.Include/RenderBody);.internal classas it was previously private inside MyTemplateBase.Like this, when
WriteAsyncis called with the RenderBody() or Include() result, it's already aRawContentand the avoidance of html encoding happens.Hope that helps someone else. Almost wonder if it's worth adding this into the docs.
304NotModified commentedon Oct 30, 2021
@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 👍
benmccallum commentedon Nov 3, 2021
@304NotModified , here's a gist.
adoconnection commentedon Nov 30, 2021
this issue seems to be resolved
304NotModified commentedon Dec 1, 2021
Documented by https://github.com/adoconnection/RazorEngineCore/wiki/Package-comparison
Seems good to me :)