Ok, let's see... The controller is dealing with the presentation logic as some of the schema.org objects are best suited to be inside the <html> tag or the <body> tag. Both of this tags are part of the layout template. Same as in Google where the itemtype "http://schema.org/WebPage"; goes in the <html> tag. My template contains the "htmlTag" view helper, with a listener I set the "lang" attribute and inside the controller action I set the itemtype if suitable. For example, inside the contact controller, indexAction I set the itemtype attribute of the htmlTag to "http://schema.org/ContactPage";. Some other actions on View Helpers are also performed on the controller, such as setting the OpenGraph metas and Twitter cards. Ok, it could be moved out of the controller and placed on the template for that controller action but in some modules I wish to take care of it in the controller and don't have to think much about it inside a new template file in case of a theme change.
Leaving the escaper do it's job is an option, but loosing more than a 50% of the share yandex has in russia... that could be certainlly out. Right now I'm having a project where the goverment of the region the project is taking place is aiming towards the russian market. If the gobverment wastes money attracting russians but my site goes badly indexed due to microdata structures... That doesn't seem a choice, neither would it be a choice for a russian developper. Well it is also a great plus to loose your employment contract if you can't aim a site towards a certain audience because the search engine your audience is using won't index your pages as expected. That would be like selling meat to a vegetable restaurant. I'm not talking about opting out of security buy having the decision to make some attributtes not escape. I see less risk in being able to tell a class "Hey! Don't escape itemtype and itemscope attributes" than having the "url" view helper returning a non-escaped href attribute as javascript sometimes gets access to the href attribute inside <a> tags. ¿Telling search engines to fix their errors? I really would choose to get doubled code that go over all the internet testing microdata structures in each of the most used search engine to see if it works or it doesn't and keeping mails with all of them. Yandex is one I've tested because it's an interesting search engine right now. But I can't tell if Bing, Aol, Wow, Yahoo, ask, webcrawler,... have the same issue or not. It's not a "wish to use" security decision, is more like a "I certainlly don't need it here as no dynamic data will be appended here". As I told you before, there is more risk on the "url" View Helper, wich does not return the href attribute escped and there are some javascript plugins which will append to those urls than allowing a developper to say "Please, don't escape this attributes as I know what I'm doing". Or is it a bug in the "url" view helper? From: [email protected] Date: Mon, 18 Jan 2016 12:39:12 -0700 Subject: Re: [fw-general] Can we disable escapers for html attributes? To: [email protected]; [email protected] 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/
