On 18 January 2016 at 12:21, Juan Pedro Gonzalez <[email protected]> wrote:
This: > inside the contact controller you could add the code to set the htmlTag > attributte to show it is a contact page... > First of all, why is the controller dealing with presentation logic? > The other way around this issue that I can think of would be having a > layout per itemtype and that wouldn't solve the issue as the itemtype could > go in the htmlTag or any other tag inside the page... So there should also > be partials all around to define every single piece of microdata. That > would be almost as having a bunch of static pages and not using MVC at all. > Or... just allow the escaper to do its work, and that's it? > Writing custom view helpers to allow the microdata for schema.org would > imply writting copy of almost every viewhelper extending HtmlElement. > Correct, and you are not supposed to do that anyway, since the escaping provided follows sane and secure defaults > I undestand that non-escaped string could cause XSS attacks if some user > provided data is added to the attribute string ¿Am I mistaken? > This is correct, but in security there is no "may". If an attack is possible, it NEEDS to be fixed, period. There is no such thing as "opting into security" (or even worse "opting out of security"), that is a suicide, from a developer perspective, and it also really is the quickest way to end your current employment contract (if you're responsible for the decision). > Then why not allow the developper to escape data on those cases? > Hoping that developers will escape data everywhere is great, but not a realistic expectation: that's why sane defaults are provided, and opting out (see answer right above) is something that we (zf developers) don't want to provide, as it is just dangerous and reckless. > In this case it seems like a decision between SEO vs Security and assuming > the developper won't take care of security he gets SEO crippled as some > microdata test will go through on some search engines but not in others. I > thinks thats assuming a decision over the developper. > Again: stop saying that this will damage SEO. If yandex has broken validation, then mail them and tell them to fix their shit (not kidding, this looks really bad!). Any DOM compliant parser will transparently deal with un-escaping content at parse time without any issues at all. > > I guess it should be optional, maybe something like: > public function addAttribute($name, $value, $escape=true) > ABSOLUTELY NOT. We value security, and not escaping strings in any data that will (on the consumer side) go through an HTML/CSS/JS/XML parser is an edge case that indicates broken user agents. You are fixing the symptom, not the cause, and by doing so, you are even introducing security issues (see ZF2014-03, as linked above). Allowing unescaped output is not something that ZF should take into consideration, and re-implementing the view helpers in your own namespace (without involving the framework) is indeed the way to go, if you want to hurt your own security context. Security is an all-or-nothing scenario: it defeats any business requirements, regardless which ones. > ...but allowing to have non-escaped strings in the attributes. or even a > general configuration key to disable escaping attributes and leave it > active by default but being able to disable it if you don't wish to use it. > There is no "wish to use it" - security is not a decision. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 18 January 2016 at 12:21, Juan Pedro Gonzalez <[email protected]> wrote: > The microdata for schema.org should be set by the developper or some code > in the system using Zend Framework. For example, if someone is creating a > blog module you could add the itemtype as BlogArticle. If it is a contact > page (Like my example) inside the contact controller you could add the code > to set the htmlTag attributte to show it is a contact page... The other way > around this issue that I can think of would be having a layout per itemtype > and that wouldn't solve the issue as the itemtype could go in the htmlTag > or any other tag inside the page... So there should also be partials all > around to define every single piece of microdata. That would be almost as > having a bunch of static pages and not using MVC at all. > > Writing custom view helpers to allow the microdata for schema.org would > imply writting copy of almost every viewhelper extending HtmlElement. I > undestand that non-escaped string could cause XSS attacks if some user > provided data is added to the attribute string ¿Am I mistaken? Then why > not allow the developper to escape data on those cases? In this case it > seems like a decision between SEO vs Security and assuming the developper > won't take care of security he gets SEO crippled as some microdata test > will go through on some search engines but not in others. I thinks thats > assuming a decision over the developper. > > I guess it should be optional, maybe something like: > public function addAttribute($name, $value, $escape=true) > > ...but allowing to have non-escaped strings in the attributes. or even a > general configuration key to disable escaping attributes and leave it > active by default but being able to disable it if you don't wish to use it. > > > > > > ------------------------------ > From: [email protected] > Date: Mon, 18 Jan 2016 11:51:47 -0700 > Subject: Re: [fw-general] Can we disable escapers for html attributes? > To: [email protected] > CC: [email protected] > > > On 18 January 2016 at 10:12, Juan Pedro Gonzalez [via Zend Framework > Community] <[email protected]> wrote: > > I don't understand the impact of having some non-escaped attributes. > > > That is indeed why security experts worked on this (specifically, we fixed > this in 2014: http://framework.zend.com/security/advisory/ZF2014-03 ). > > > For example, the "url" view helper won't escape the "href" tag, however > the "navigation" helper (More preciselly the "menu" plugin inside that view > helper) will escape the "href" tag. > > > This is a valid point, and we should probably secure this endpoint as well > (adding escaping). > Please see http://framework.zend.com/security/, or else I'll try > inspecting if it is an immediate attack vector. Further discussion about > this shouldn't be continued on the public mailing list though. > > > The "itemtype" attribute of for schema.org is simply an absoulte url and > it gets escaped... > > > An absolute URL provided by whom? The navigation view helpers don't know > that. > > > I may understand someone will wnt to escape the translated texts inside > the "alt" atrribute, or something like that, but also not to escape some > other attributes... Even the class names inside the "menu" plugin of the > "navigtion" view helper get escaped. If the browser is homebrewed and > hasn't taken care of it the output may get ruined. > > > The navigation component HAS to treat anything like user input, since it > is a general purpose component. > > > IMHO a framework should be so much involved on the output as it seems hard > to sutomize this issue. > > > Disagree: ZF2 is quite disengaged on this as well, as the escaping is > usually added by users, unless they use our own internal helpers. > > > If I'm not mistaken, in order to get non-escaped attributes I should write > my own view helpers... > > > Unescaped attributes must be ABSOLUTELY avoided unless the output data is > not dynamically defined. > > > As the MVC module will load the Zend\View View Helpers that means that in > order to lower the resource I should also avoid using the Zend\Mvc > namespace or, atleast change all the files under Zend\Mvc\Services to use > my own so it will load my own application with my own services and, this > way loading my custom ViewHelpers without loading Zend's. ¡That's a hell of > task! But if I wish to maintain control over my output there seems to be > no other solution. Atleast sticking to Zend Framework. > I really don't understand the reason to enforce attribute escaping. > > > I repeat: that's why this is done by security experts (that understand the > domain of security and escaping), and not by general users. > > Cheers, > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > >
