On Thursday, 14 September 2017 02:40:41 UTC+3, Karv Prime 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. >
See https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html#problem_definition it goes into depth on the implications of a particular design. tl;dr; practice has shown that people forget proper sanitization. Automatic sanitization with type-inference is easy to use and gets things right unless you start messing with the template.HTML directly. > 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 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. >> 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.