Contextual auto-escaping corner cases

2013/3/12 Tab Atkins Jr. <jackalmage@gmail.com>:
> Ian provided several examples of code where it seems like it would be
> impossible to auto-escape properly, and an author relying on
> auto-escaping because they've been trained that it works elsewhere
> could be easily misled and inadvertently cause an XSS vulnerability.
> Could you go over those and answer how you think your ideas for
> auto-escaping would address the problems he raised?

2013/3/12 Ian Hickson <ian@hixie.ch>:
> What would be autoescaped in something like:
>
>    h`<img src="${scheme}://${host}:${port}/${path}/${file}.${ext}"
>          srcset="${file1} ${w1}w ${file2} ${w2}w"
>          alt="${alt}"
>          data-logger-url="logger?id=${id}&key=1234">
>
> ...? (where h`` is your autoescaper; obviously pretend that part is the
> done however your syntax would really work, and strip newlines if
> necessary, obviously.)

The parts in the src are all URI encoded.  Any parts that appear after
a literal '?' or '#' are encoded so as to prevent parameter splitting.

In the closure-templates and Go versions, we have heuristics to let us
determine if custom attributes or data-* attributes are URL content.
This was based on an inspection of template code prior to the
introduction of contextual auto-escaping, and since Closure templates
are compiled statically it allows our pen-testers to keep a list of
known attributes that pass the heuristic and flush out new
non-standard attributes that don't.

The custom attribute scheme allows for a few security postures:

1. A company with a high security profile and a group of pen-testers
uses a combination of white-lists, presubmit checks, and a heuristic
to make sure that URLs are recognized.  Contextual auto-escaping
allows pen-testers to quickly find exceptions to the rule, and focus
on vectors besides XSS.

2. A company with a low security profile and an informal
release/verification process can reduce their attack surface markedly
by using contextual-autoescaping, but holes still exist.

3. A company with a high security profile that acquires a company with
a low security profile (and its source code) can transition code to
contextually auto-escaped, and the acquired dev-team focuses on fixing
over-escaping bugs, while the acquirers pen-testers build a schema of
custom elements&attributes based on their probing and subsequent
white-box examination.


> Or this:
>
>    x`<div style="color: ${colorModeA}"
>           data-style-mode-a="color: ${colorModeA}"
>           data-style-mode-b="color: ${colorModeB}"
>           data-style-mode-c="color: ${colorModeC}"></div>`
>
> ...where script switches in the new style="" attribute values dynamically
> based on e.g. some game state?

This is no different in principle than the first.  Closure templates
does not include heuristics for style, since it never showed up in any
template code -- web devs manipulate the class attribute when they
want to switch styling.


> How about this:
>
>    x`<img width="${width}"
>           src="${profile.cgi?username=${username}&size=${width}}">
>      <script>
>       var x = new Image(${width});
>       x.src = 'profile.cgi?username=${username}&size=${width}';
>      </script>`;

Quite.  We really need an intercession layer for the DOM that lets us
intercept assignments to sensitive properties and do late-binding of
escaper to templates.  Yay proxies.


> How about:
>
>    x`<p>Paste this WLAML command: AB=2%\*2*11*22;GA=${GADATA}*41</p>`

Social engineering will affect all technical solutions as shown in
this E4H template

<>{x}</>

with

x = "Paste this into your URL bar : javascript:pwnMe()"

Received on Thursday, 14 March 2013 20:47:23 UTC