Why does automatic escaping make html/template completely impractical? (Or did
I guess the antecedent of “it” incorrectly?)
Andy
> On Sep 13, 2017, at 4:30 PM, Karv Prime <karv.pr...@gmail.com> wrote:
>
> Thank you for the heads up. So it is completely impractical for the needed
> purpose.
>
> In that case it would be truly bad. That's why user input should always be
> checked. Such a blogpost shouldn't even come that far. ^^ Either it's escaped
> before it gets to the database (not truly necessary due to prepared
> statements etc., but depends on the use case scenario), but at least it
> should be escaped before it hits the visual representation.
>
> Let's stay with the blogpost example to give some further insight and assume
> the following [folder]/file structure:
> [site]
> - site.html (the full site, but without nav, and main, as well as data that
> depends on which page is shown, language, etc. (html lang, title, keywords,
> etc.)
> - nav.html (only the navigation, which isn't depending on anything, but
> exists as its own module)
> - main.html (main content - in our case the blog - that has different
> blogposts)
> [modules]
> - blogpost.html (a singular blogpost and how it should look like)
>
> So the application should at first stick together site, nav, and main. If
> that happens at runtime or if it creates a template beforehand is a matter of
> optimization, but doesn't really matter in our example. As the user requested
> the page in Latin, lang, title, keywords, etc. are filled in accordingly. Up
> to that point any code injection could be possible but then there are other
> security concerns as until then no user data has been used. We have 5
> blogposts as our blog came to live a day ago and up to now only spambots were
> here. But user entries are user entries, so let's parse them. Take the
> blogpost.html file and fill <div class="username"></div> as well as <div
> class="userpost"></div> with their content: Escape the content, then fill it
> in the same way as innerHTML from JS works. Put these 5 blogposts into main
> and send it to the user.
> Another user clicks "blog" in the navigation but has JS activated - so it
> only loads the main content. Again the 5 blogposts, but not the full site.
> Some other user is active on the blog, but gets updates every 10 minutes or
> due to server side events - as the previous user complained about the
> botposts he now only gets a representation of blogpost.html sent with the
> content to be prepended before the other posts.
>
> Yes, one could realize that solely with templates. But everytime just a
> little thing has to be changed (i.E. another navigation link added) someone
> has to touch the whole site.html file (GIT be praised, but nonetheless it's
> not that good for really big sites, so a separation is at least sometimes
> practical). The downside is that every HTML guy needs to learn the "how to
> templating in language X", be it Golang, Twig, Smarty, ... instead of just
> creating plain simple HTML which can be manipulated by the code via the HTML
> DOM. And if there's something missing it creates a warning which is practical
> too (as, if the full site without the dynamic stuff gets stitched together
> beforehand from some kind of easy maintainable [meta] page, it could stay
> with the previous version until the oversight is solved, or whatever one
> wants to do with that information). And the problem "some coders could
> actually forget to check user input" can be solved with taint checking (if
> the content comes from a "secure" source (i.E. a .html file) there is no need
> for a warning, but if it's from a database all hell should break loose) - but
> as files could under certain circumstances also be user-created (i.E. some
> esoteric database where every blog entry is a file) there's a problem here.
> One can't prevent coders from making mistakes. PHP tried, it failed. ^^ Java
> has no taint checking if user data is injected into a SQL query, Perl and
> Ruby have it. Maybe the solution would be to allow a coder to choose between
> an unescaped innerHTML and an escaped one.
>
> Am Donnerstag, 14. September 2017 00:43:10 UTC+2 schrieb Andy Balholm:
> You may not be aware that the html/template package does automatic escaping.
> So if a template has <div id=not-so-secure-blogpost>{{.Blogpost}}</div> and
> Blogpost contains <script>alert(“Pwned”)</script>, the result will be
> something like <div
> id=not-so-secure-blogpost><script>alert("Pwned")</script></div>
>
> Assigning to the div’s innerHTML would be bad in this case, but appending a
> text node to the div would be safe.
>
> Andy
>
>> On Sep 13, 2017, at 2:10 PM, karv....@ <>gmail.com <http://gmail.com/> wrote:
>>
>> I don't know why it's unclear, what I'm proposing, but I'll try a 2nd time:
>>
>> Something similar to: http://php.net/manual/en/book.dom.php
>> <http://php.net/manual/en/book.dom.php>
>>
>> Or, even simpler:
>> - Find Tags, IDs, Classes, etc. in an HTML document.
>> - Something similar to Element.innerHTML to put content into these tags
>> (https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
>> <https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML>)
>> - Something similar to Element.setAttribute to change attributes of DOM
>> elements
>> (https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute
>> <https://developer.mozilla.org/en-US/docs/Web/API/Element/setAttribute>)
>> - Maybe some validation if the HTML DOM is correct
>> - Possibly some sanitation to check if there are any empty tags or empty tag
>> attributes (i.E. empty content on some meta tag)
>>
>> In short: Load some HTML code, and manipulate the HTML Document Object Model
>> instead of being dependent on placeholders.
>>
>> Yes, a standard library shouldn't do everything. But same goes with
>> templating, so that isn't really an argument against implementing it into
>> the codebase if one of the main foci of Golang is the Web.
>>
>> I wasn't ignoring the Security Model. If someone uses Golang to create a
>> comment section in the web, the same could happen with Templates, if the
>> developer isn't aware of possible security issues. There is no difference if
>> some unchecked user content is injected into <div
>> id="not-so-secure-blogpost>{{blogpost}}</div> or <div
>> id="not-so-secure-blogpost></div>. So I really don't see where
>> "html/template" avoids this issue if some coder doesn't watch out how user
>> content is handled. Escaping the user content (or other security features)
>> can be implemented too, yes - but that should be some other package imho.
>>
>> Kind regards
>> Karv
>>
>> Am Mittwoch, 13. September 2017 21:58:47 UTC+2 schrieb Egon:
>> If you want to manipulate HTML files then there is
>> https://godoc.org/golang.org/x/net/html
>> <https://godoc.org/golang.org/x/net/html>,
>> but it comes with all the dangers of potential injection attacks and so
>> on... which "html/template" avoids.
>> Writing something that injects into the specific nodes and afterwards
>> encodes shouldn't be a big problem.
>>
>> If you want to write HTML directly from code then writing a simple html
>> encoder with the necessary models
>> isn't too complicated
>> (https://github.com/egonelbre/exp/blob/master/htmlrender/main.go
>> <https://github.com/egonelbre/exp/blob/master/htmlrender/main.go>)
>>
>> But the huge con you are ignoring is the Security Model.
>> (https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition
>>
>> <https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition>)
>>
>> Anyways it's unclear what you are proposing or needing: in general standard
>> libraries shouldn't do everything
>> and probably this, whatever it is, should belong to a 3-rd party package.
>>
>> + Egon
>>
>> On Wednesday, 13 September 2017 22:02:02 UTC+3, Karv Prime wrote:
>> Hello,
>>
>> I only recently found my way to go. I'm a (former?) fullstack web-dev and as
>> I ran into a PHP related problem (DOMDocument not working with HTML5 tags,
>> I'd choose another solution stack if the language wouldn't be a fixed point
>> in history) I was looking if Go already has a good way to manipulate HTML
>> files. The templating is fine, but in my humble opinion there's a problem...
>>
>> Problem: IMHO templating in the current form is flawed. To insert
>> placeholders (i.E. "{{.nav}}") probably isn't an optimal solution as it just
>> tells the code "hey, act upon me". It seems to be a shallow solution to
>> prevent code-mixins, but fails to really separate the concerns.
>>
>> Solution: If there would be a Go package to directly manipulate the DOM it
>> would be very helpful to separate Markup and Code. The code would act onto
>> the markup file (*.html) to create the page/site/module/... (whatever is
>> needed).
>>
>> Pros:
>> - Frontend devs could create their own pages, modules, etc. without thinking
>> about any special tags they'd need.
>> -> '<main></main>' instead of '<main>{{.content}}</main>'
>> -> '<meta name="description" content="">' instead of '<meta
>> name="description" content="{{.description}}">'
>> - Error/Exception if some tag/id/class/... has not been found instead of
>> admins possibly not knowing about it.
>> -> You can act upon it and tell the users "Oops, something went wrong, we're
>> looking into it." so they know that the current state of the site isn't what
>> they should see.
>> -> Better an empty element (and the admin knows about it) instead of users
>> seeing placeholders.
>> - It's easier to avoid any problems with funny users trying to trick the
>> system.
>> - In theory faster than templating solutions (untested claim, so there's a
>> big questionmark)?
>> - It prefers modular frontends (main site, nav, main content, reusable
>> modules (i.E. for items on a sales platform)) instead of a single file with
>> placeholders
>> - It prefers cleaner code and true SoC instead of the ofttimes preferred
>> workflow "just a little HTML in the code to create each item faster" or vice
>> versa.
>> - ...
>>
>> Cons:
>> - If there are elements unknown to the backend-devs, they will probably stay
>> empty
>> -> Possible solution could be some kind of taint-checking for empty elements
>> after page creation
>> - "Duplicate" code if there's frontend-scripting that is changing parameters
>> accordingly to AJAX results, but that's almost unavoidable.
>> - Probably more communication needed between backend- and frontend-devs
>> -> Possible solution, the aforementioned taint-checking, to see these
>> problems in testing, if they should arise
>> - ...
>>
>> Feel free to contribute your thoughts, other pros/cons, etc. :)
>>
>> Kind regards
>> Karv
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@ <>googlegroups.com <http://googlegroups.com/>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
