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.pr...@gmail.com
> <mailto:karv.pr...@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+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.
