URI filtering and zSoyz

[Nick Santos]

I noticed that if I have a template like this:

{namespace x autoescape="contextual"}

/**
* An anchor.
* @param href
*/
{template .anchor}
<a href="{$href}">text</a>
{/template}

Then, by default, closure-templates will apply the
"filterNormalizedUri" to $href. This has a number of bizarre
behaviors:

1) If I pass in href="ftp://somelink", and goog.DEBUG=true, then the
template engine will throw an error
2) If I pass in href="ftp://somelink", and goog.DEBUG=false, then the
template engine will return "#zSoyz"

One one hand, it's not totally clear to me why ftp urls are invalid.
On the other hand, throwing an error seems like it defeats the whole
point of using a template engine to sanitize user inputs. On the third
hand, shouldn't the default 'error link' be configurable, rather than
hard-coding '#zSoyz'?

Can somebody elaborate on the reasoning behind this, and if the
maintainers would be willing to change it?

Thanks!
Nick

[Mike Samuel]

2013/10/22 Nick Santos <nicholas...@gmail.com>:

> I noticed that if I have a template like this:
>
> {namespace x autoescape="contextual"}
>
> /**
> * An anchor.
> * @param href
> */
> {template .anchor}
> <a href="{$href}">text</a>
> {/template}
>
> Then, by default, closure-templates will apply the
> "filterNormalizedUri" to $href. This has a number of bizarre
> behaviors:
>
> 1) If I pass in href="ftp://somelink", and goog.DEBUG=true, then the
> template engine will throw an error
> 2) If I pass in href="ftp://somelink", and goog.DEBUG=false, then the
> template engine will return "#zSoyz"

> One one hand, it's not totally clear to me why ftp urls are invalid.

We chose a small white-list. "http", "https", and "mailto" are
allowed protocols. Protocol relative and path relative URIs are also
allowed.
"ftp" and "tel" did not make the cut.

> On the other hand, throwing an error seems like it defeats the whole
> point of using a template engine to sanitize user inputs. On the third

The idea was to fail hard during testing where a developer is most
likely to see the problem, and fail gracefully when it's an end-user
staring at the browser. I can see your point though.

> hand, shouldn't the default 'error link' be configurable, rather than
> hard-coding '#zSoyz'?

The idea was to pick a unique phrase that when put into your favorite
search engine would point you to the link above, and the workaround
for content that is known to be safe but which does not pass the
filter: https://developers.google.com/closure/templates/docs/security#sanitizedcontent

> Can somebody elaborate on the reasoning behind this, and if the
> maintainers would be willing to change it?

This behavior is described at

https://developers.google.com/closure/templates/docs/security#in_urls

> When {$x} appeared inside a URL or as a CSS quantity, we rejected it because it had a protocol javascript: that was not http or https, and instead output a safe value #zSoyz. Had {$x} appeared in the query portion of a URL, we would have percent-encoded it instead of rejecting it outright (< → %3C).

[Nick Santos]

On Wed, Oct 23, 2013 at 7:10 PM, Mike Samuel <mikes...@gmail.com> wrote:
> We chose a small white-list. "http", "https", and "mailto" are
> allowed protocols. Protocol relative and path relative URIs are also
> allowed.
> "ftp" and "tel" did not make the cut.

for my education, are there any known security issues with ftp? Or was
this just to be safe?

> The idea was to fail hard during testing where a developer is most
> likely to see the problem, and fail gracefully when it's an end-user
> staring at the browser. I can see your point though.

I don't think that "goog.DEBUG is true iff testing" is a reasonable
assumption. As far as I know, a lot of closure users regularly turn on
debug-mode logging in prod to diagnose production problems. We were
pretty surprised when turning on debug logging made the entire page
load sequence throw exceptions.

> The idea was to pick a unique phrase that when put into your favorite
> search engine would point you to the link above, and the workaround
> for content that is known to be safe but which does not pass the
> filter: https://developers.google.com/closure/templates/docs/security#sanitizedcontent

Fair enough. I appreciate that without a common logging system, there
aren't any decent options here.

[Mike Samuel]

2013/10/23 Nick Santos <nicholas...@gmail.com>:

> On Wed, Oct 23, 2013 at 7:10 PM, Mike Samuel <mikes...@gmail.com> wrote:
>> We chose a small white-list. "http", "https", and "mailto" are
>> allowed protocols. Protocol relative and path relative URIs are also
>> allowed.
>> "ftp" and "tel" did not make the cut.
>
> for my education, are there any known security issues with ftp? Or was
> this just to be safe?

IIRC, ftp was particularly problematic when phishers were using the
userinfo part to make the URL in the url bar appear to be part of a
site, but actually using a different domain.

http://archive.arstechnica.com/news/posts/1071194883.html

I don't think that is an issue for modern browsers though.

>> The idea was to fail hard during testing where a developer is most
>> likely to see the problem, and fail gracefully when it's an end-user
>> staring at the browser. I can see your point though.
>
> I don't think that "goog.DEBUG is true iff testing" is a reasonable
> assumption. As far as I know, a lot of closure users regularly turn on
> debug-mode logging in prod to diagnose production problems. We were
> pretty surprised when turning on debug logging made the entire page
> load sequence throw exceptions.

Understood. I'll reraise this with Kai and Garry.

[Nick Santos]

Thanks! That url bar vulnerability is actually pretty clever.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "Closure Templates Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to closure-templates-...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.