ACTION-278 security and sharing

On Fri, Feb 12, 2010 at 4:53 PM, Tyler Close <tyler.close@gmail.com> wrote:
> 1. Note that nowhere does my draft text require that an unguessable
> URL alone be sufficient to grant access to a resource. It only says
> that private resources SHOULD use unguessable URLs. It doesn't say
> that you can't use additional security measures.

I wonder if it would help if we separated the two cases (1) changing
existing sites (such as those for banks) so that they are resistant to
CSRF attacks, (2) endorsing / explaining / amplifying current
unguessable-URI practices for sharing e.g. Google documents. I think
some people in the conversation have been conflating the two
motivations, assuming that when you do (1) you would do it to replace
rather than augment other protections.

If the only change to the bank's site is to change its URIs from
guessable to unguessable, without removing or changing any of its
other defenses, then clearly the site is not made less secure; and it
becomes more secure since CSRF depends on being able to guess URIs.
That is, the bank is not replacing session authentication with
web-keys, it's combining the two, with each mechanism addressing
different kinds of threats. The claim is that nowadays to make a
secure site you *have* to use unguessable URIs, so a TAG finding that
appears to advise against the only safe behavior is actively harmful.

Am I totally off base when I say that if the bank added unguessability
AND removed other protections, there might be problems? E.g. Alice is
doing her banking, and sees something really funny on a page's
boilerplate (maybe a mistake or a joke), copies/pastes the block of
text, and sends to Bob for his amusement, without noticing that buried
in the text Alice copied there was a link that would give Bob access
to Alice's account. With conventional protections still in place,
there's no risk because Bob won't be able to authenticate as Alice.
But now the banking site is protected against CSRF.

As for (2) new patterns of sharing of the Google docs kind, i.e.
relying more on unguessability and less on sessions, SOP, etc., the
argument seems to be which cautions to present and how (single-use,
timeout, retractable, audited, only for not-so-confidential things,
beware malware, scary warnings).

Jonathan

Received on Wednesday, 17 February 2010 14:18:32 UTC