Can we disable escapers for html attributes?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Can we disable escapers for html attributes?

Juan Pedro Gonzalez
Hi,
I'm trying to add some schema.org for SEO but the attributes get escaped giving an ugly view of the code; further more, I'm not sure search engines will be able to handle this data the correct way. ¿Can't it be disabled?    
Reply | Threaded
Open this post in threaded view
|

Re: Can we disable escapers for html attributes?

Marco Pivetta
There is no problem (from an SEO perspective) in having escaped attributes.

Also, UTF-8 is big and scary: don't disable escaping, it's just like asking
for trouble ;-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 18 January 2016 at 07:51, Juan Pedro Gonzalez <[hidden email]>
wrote:

> Hi,
> I'm trying to add some schema.org for SEO but the attributes get escaped
> giving an ugly view of the code; further more, I'm not sure search engines
> will be able to handle this data the correct way. ¿Can't it be disabled?
>
Reply | Threaded
Open this post in threaded view
|

RE: Can we disable escapers for html attributes?

Juan Pedro Gonzalez
I don't understand the impact of having some non-escaped attributes. 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. The "itemtype" attribute of for schema.org is simply an absoulte url and it gets escaped... 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.
IMHO a framework should be so much involved on the output as it seems hard to sutomize this issue. If I'm not mistaken, in order to get non-escaped attributes I should write my own view helpers... 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 would understand it if it was a CMS or something of the kind, but beeing a Framework I guess it hould be up to the developer if he want to escape the attribute or not. In my case I wouldn't want to escape the attributes of the "htmlTag" which I'm using for the schema main itemtype. Neither i find it usefull to escape the attributes from the navigation menu. And there seems to be no easy way to solve this.
Best regards

From: [hidden email]
Date: Mon, 18 Jan 2016 09:21:39 -0700
Subject: Re: [fw-general] Can we disable escapers for html attributes?
To: [hidden email]
CC: [hidden email]

There is no problem (from an SEO perspective) in having escaped attributes.

Also, UTF-8 is big and scary: don't disable escaping, it's just like asking for trouble ;-)
Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/


On 18 January 2016 at 07:51, Juan Pedro Gonzalez <[hidden email]> wrote:
Hi,

I'm trying to add some schema.org for SEO but the attributes get escaped giving an ugly view of the code; further more, I'm not sure search engines will be able to handle this data the correct way. ¿Can't it be disabled?                                      
     
Reply | Threaded
Open this post in threaded view
|

RE: Can we disable escapers for html attributes?

Juan Pedro Gonzalez
In reply to this post by Marco Pivetta
By the way, there IS a problema from a SEO perspective. Using yandex microdata validator I get an error with the escaped string:
"WARNING: itemtype http&#x3A;&#x2F;&#x2F;schema.org&#x2F;ContactPage not recognized by validator"
There is no error if the itemtype is NOT escaped. Don't know if other search engines will react this way but yandex will certainly have troubles with that escaped string and, therefore, Zend Framework will ruin the SEO. :(

> From: [hidden email]
> Date: Mon, 18 Jan 2016 09:21:39 -0700
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [fw-general] Can we disable escapers for html attributes?
>
> There is no problem (from an SEO perspective) in having escaped attributes.
>
> Also, UTF-8 is big and scary: don't disable escaping, it's just like asking
> for trouble ;-)
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 18 January 2016 at 07:51, Juan Pedro Gonzalez <[hidden email]>
> wrote:
>
> > Hi,
> > I'm trying to add some schema.org for SEO but the attributes get escaped
> > giving an ugly view of the code; further more, I'm not sure search engines
> > will be able to handle this data the correct way. ¿Can't it be disabled?
> >
     
Reply | Threaded
Open this post in threaded view
|

Re: Can we disable escapers for html attributes?

Marco Pivetta
On 18 January 2016 at 10:12, Juan Pedro Gonzalez [via Zend Framework
Community] <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Re: Can we disable escapers for html attributes?

Marco Pivetta
In reply to this post by Juan Pedro Gonzalez
On 18 January 2016 at 11:08, Juan Pedro Gonzalez <[hidden email]>
wrote:

> By the way, there IS a problema from a SEO perspective. Using yandex
> microdata validator I get an error with the escaped string:
> "WARNING: itemtype http://schema.org/ContactPage not recognized by
> validator"
> There is no error if the itemtype is NOT escaped. Don't know if other
> search engines will react this way but yandex will certainly have troubles
> with that escaped string and, therefore, Zend Framework will ruin the SEO.
> :(
>

This actually indicates that yandex microdata validator is not DOM
compliant, and may even be vulnerable to XSS injections (OUCH!) when
re-generating output from user input (can't verify it though, as I don't
have a pentesting tool at hand).

I suggest that you look at http://r12a.github.io/apps/conversion/ to check
that the escaping matches your data, if that's what you fear.

Also see https://jsfiddle.net/5toL1c5r/ (proper escaping)
Also see https://3v4l.org/PE8hk (proper parsing via DOM compliant APIs)

Hope that helps

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
Reply | Threaded
Open this post in threaded view
|

Re: Can we disable escapers for html attributes?

Marco Pivetta
In reply to this post by Marco Pivetta
On 18 January 2016 at 12:21, Juan Pedro Gonzalez <[hidden email]>
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 <[hidden email]>
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: [hidden email]
> Date: Mon, 18 Jan 2016 11:51:47 -0700
> Subject: Re: [fw-general] Can we disable escapers for html attributes?
> To: [hidden email]
> CC: [hidden email]
>
>
> On 18 January 2016 at 10:12, Juan Pedro Gonzalez [via Zend Framework
> Community] <[hidden email]> 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/
>
>
Reply | Threaded
Open this post in threaded view
|

RE: Can we disable escapers for html attributes?

Juan Pedro Gonzalez
In reply to this post by Marco Pivetta
No that's not my fear... My fear is that a search engines won't index my pages correctlly. A stated earlier yandex microdata validator will issue a warning and doen't understand the schema.org microdata structure. Vulnerable to XSS attacks or not, Yandex has a share over a 50% of the russian market. Therefore my page won't have the same SEO impact on the russian market as a competitors page not escaping this attribute. If Zend Framework is aimed to personal sites there is no problem at all as SEO may not be so important, but a companies page could possible have troubles if SEO is not as good as posible and even a money waster if they have aquired some SEO services and they think it's working as expected but some search engines are ignoring microdata.
I really don't see what troubles could arrise from not escaping "itemtype" and "itempscope" attributes, as I don't see any reason why user input or javascript should access this two attributes. It would be nice if the attribute would selectivelly escape or not... Adding an array of non-escaped attributes or something like that. As mentioned the schema microdata would affect all helpers extending the AbstractHtmlElement and therefore would be duplicating a bunch of code just to be able to get SEO working on search engines such as yandex and addinf a perfomance downgrade which would also affect SEO as more memory would be used keeping duplicate view helpers just to avoid 2 attributes from being escaped.
There is no easy work arround as the attribute code in inside the AbtractHtmlElement and therefor that would be the element to extend, but all the real helpers extend it and therefor there should be a new abstract helper and every single html object copied to and with the namespace changed in order for it to work. The other way around is allowing overriding the view plugin and completelly disable the escaper by creating a new escaper that only returns the value passed. None of them are nice solutions as creating the custom views means extra maintenance as new changes to Zend\View should be implemented on the custom view helpers as they have the same code since they cannot be extended. Leaving everithing without escaper is not the best solution... But, how could some attributes be kept without escaping? I don't want to go into every single search engine to see if the microdata get's indexed correctlly or not.

From: [hidden email]
Date: Mon, 18 Jan 2016 12:04:09 -0700
Subject: Re: [fw-general] Can we disable escapers for html attributes?
To: [hidden email]
CC: [hidden email]

On 18 January 2016 at 11:08, Juan Pedro Gonzalez <[hidden email]> wrote:
By the way, there IS a problema from a SEO perspective. Using yandex microdata validator I get an error with the escaped string:

"WARNING: itemtype http://schema.org/ContactPage not recognized by validator"

There is no error if the itemtype is NOT escaped. Don't know if other search engines will react this way but yandex will certainly have troubles with that escaped string and, therefore, Zend Framework will ruin the SEO. :(

This actually indicates that yandex microdata validator is not DOM compliant, and may even be vulnerable to XSS injections (OUCH!) when re-generating output from user input (can't verify it though, as I don't have a pentesting tool at hand).

I suggest that you look at http://r12a.github.io/apps/conversion/ to check that the escaping matches your data, if that's what you fear.

Also see https://jsfiddle.net/5toL1c5r/ (proper escaping)
Also see https://3v4l.org/PE8hk (proper parsing via DOM compliant APIs)

Hope that helps
Marco Pivetta

http://twitter.com/Ocramius     

http://ocramius.github.com/ 
     
Reply | Threaded
Open this post in threaded view
|

RE: Can we disable escapers for html attributes?

Juan Pedro Gonzalez
In reply to this post by Marco Pivetta
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: [hidden email]
Date: Mon, 18 Jan 2016 12:39:12 -0700
Subject: Re: [fw-general] Can we disable escapers for html attributes?
To: [hidden email]; [hidden email]


On 18 January 2016 at 12:21, Juan Pedro Gonzalez <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Date: Mon, 18 Jan 2016 11:51:47 -0700
Subject: Re: [fw-general] Can we disable escapers for html attributes?
To: [hidden email]
CC: [hidden email]

On 18 January 2016 at 10:12, Juan Pedro Gonzalez [via Zend Framework Community] <[hidden email]> 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/