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 <javascript:> 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
>
> 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)
> - Something similar to Element.setAttribute to change attributes of DOM
> elements (
> 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,
>> 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)
>>
>> But the huge con you are ignoring is the Security Model. (
>> 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 <javascript:>.
> For more options, visit 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.
