[Flow] Fluid escaping interceptor not called when rendering view helpers with shorthand syntax

[Bastian Waidelich]

Helmut Hummel wrote:

Hi Helmut,

sorry for the late response ;)

>> Ok, let's just agree to disagree on that matter ;)
>
> You disagree that context aware escaping in a templating engine[1] would
> reduce the risk of introduction of security issues?

Maybe not that strict and universal but personally I doubt that putting 
in "more magic" makes Fluid safer.
Context aware escaping is definitely an interesting approach, but there 
will always be edge-cases unless we build a HTML engine into Fluid ;)

One thing I could imagine is some kind of global modifier (global as in 
Per template file) to define the escaping behavior at the top of a 
template (similar to the {namespace...} tags).
Apart from that we should try to communicate


http://google-ctemplate.googlecode.com/svn/trunk/doc/auto_escape.html

>>> <p style="color: {obj.color};" title="{obj.title}">;
>>>
>>> {obj.color} -> wrong escaping
>>
>> Why would that be wrong?
>
> This is one of the many HTML contexts where htmlspecialchars encoding is
> not enough, since ";:" are not encoded, you can apply all styles you
> want and you can do a lot with CSS3 nowadays ;)
>
>>> <script type="text/javascript">
>>> var userName = {user.name};
>>> </script>;
>>>
>>> {user.name} -> wrong escaping
>>
>> I'm not trying to defend Fluid here, but I wouldn't call this "wrong"
>> either, the variable would be "htmlspecialchared" which might be desired
>> and could be avoided with {user.name -> f:format.raw()}
>
> It (documenting implications and behavior) is not about if Fluid is good
> or bad, but what it does when and what it does not.
>
>> BTW: running a variable through a ViewHelper does not disable the
>> escaping per se - only for the VH arguments.
>> That means that the format.* ViewHelpers do not disable escaping for
>> example.
>>
>> There are nasty exceptions though:
>>
>> {string -> f:format.crop(maxCharacters: 10)} // escaping active
>> {f:format.crop(value: string, maxCharacters: 10)} // escaping inactive!
>
> Wow. While I understand this from a technical point of view, from
> (repeating myself) a user perspective this is impossible to grasp. At
> least it is very likely to do wrong.
>
>> This is consistent in the technical sense, but it is obviously very
>> error-prone and I suggest to fix those rare cases by applying the
>> escaping manually where applicable.
>
> I don't have an overview what places exactly you mean, but more
> consistency in that regard would be good.
>
> Would be great if we could discuss these issues in person. When is the
> next code sprint?
>
> Kind regards,
> Helmut
>
> [1]http://googleonlinesecurity.blogspot.de/2009/03/reducing-xss-by-way-of-automatic.html
>
>


-- 
Bastian Waidelich