Re: Remove paths from CSP?

On 05-Jun-14 13:03, Mike West wrote:

>     Images can normally be served static from a site, so is not the main
>     problem, and no different than the existing problem. For documents, the
>     question is if the "blank" page can be distinguished from the normal
>     login page.
> 
> Leaving images aside (because you're right, they prove too much) the
> sorts of attacks detailed in
> http://www.contextis.com/documents/2/Browser_Timing_Attacks.pdf would
> still worry me.
> 
>     For a suitable definition of "blank", this should be hard,
>     and it should be possible for webmasters to make their login pages look
>     just like the "blank" page to further minimize that chance.
> 
> 
> I think I'm missing this point. A blank login page would be not
> particularly useful. What does "blank" mean to you? :)

Timing attacks work based on the difference between the login page, and
the page being redirected to. The proposal is to replace the
redirected-to page with a "blank" page. So now timing attacks will have
to find the differences between this "blank" page, and the regular login
page. If our "blank" page is actually a page containing a login form,
such differences would be minimal, and webmasters could make them even
more minimal still, by altering their own login page. (Our "blank" page
might still be visually blank, as seen by users.)

Alternatively, our "blank" page might be what is returned by a 200
response on an authentication-less (e.g. no cookies) requests to the
same URL. (To avoid timing attacks on the response time, that request
would have to be fired off simultaneously, so this might increase
traffic, unless we have good heuristics for when to use it.)


>     One of my concerns is that we will open a new hole which webmasters
>     cannot close. A solution might be to add a CSP HTTP header when doing
>     cross-domain requests which may be used for redirection detection. This
>     would enable webmasters so inclined to detect such requests, and always
>     give the same response.
> 
> Interesting. How does this work?
> 
> Assume that `evil.com <http://evil.com>` triggers a request to
> `example.com/loggedin` <http://example.com/loggedin`> (which redirects
> to `accounts.example.com <http://accounts.example.com>`). What would be
> sent in the header along with the request to `example.com
> <http://example.com>`? The active policy of the page requesting the
> resource?

A header saying e.g.:
CSP-warning-header: "If you redirect, you might leak the redirected-to
URL to evil.com, so don't redirect if you don't want to risk this"

(Obviously shortened somewhat.) This header would then be sent whenever
there is a relevant policy which allows redirection detection.

> Does that have properties significantly different from the `Referer` or
> `Origin` headers?

Referer is optional, and doesn't happen on https, and Origin only on
CORS. Referer doesn't say anything about inline or not (Origin implies
inline resource). An "Is-inline-element-on-embedding-URL: evil.com"
header might achieve the same (which is essentially an Origin header
applied to CSP-controlled requests).


-- 
Sigbjørn Vik
Opera Software

Received on Thursday, 5 June 2014 12:12:32 UTC