W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #328: user Intervention on Redirects

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 17 Feb 2012 15:08:40 -0800
Message-ID: <CABkgnnUCHw4=yM0jO6apkuSJe+vLkGKRPZGDvxwiV3_WXuUkOg@mail.gmail.com>
To: Henrik Nordström <henrik@henriknordstrom.net>, Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
2012/2/15 Henrik Nordström <henrik@henriknordstrom.net>:
> tis 2012-02-07 klockan 08:38 -0800 skrev Martin Thomson:
>> There isn't a security problem.  X has the information and could
>> forward to Y itself.
> No it doesn't. Y may require authentication / session cookies / IP based
> access lists etc which X can not provide on it's own.

Damn, I can be dense sometimes.  Obviously, if I can convince you to
send me a POST that says "transfer $10 to acct number X" (which is
trivially easy) and then redirect you to your bank, if you have an
open session and the bank doesn't check Referer (though that wouldn't
necessarily help), you've just made an easy $10.

Are there any measures that browsers could take to limit this sort of
thing?  I'm thinking for Julian's 308 draft in particular.  Obviously
it already applies to 307.  The 308 draft only cites Section 11 of p2,
which doesn't even mention this particular problem.

Just off the cuff, it seems to me that a method preserving redirect
(307, 308) should almost operate in the same sort of security context
as a cross domain request (CORS).  That means that user credentials
are removed unless the target resource explicitly accepts them.  Or
you could just take the position that this is a problem for the target

Problem?  Or have I just missed something else?
Received on Friday, 17 February 2012 23:09:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC