W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: User confirmation and 307 redirects

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 19 Aug 2010 15:11:08 -0700
Cc: Adam Barth <ietf@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-Id: <7C1D1297-A697-43AB-9866-9063FAD46D0D@gbiv.com>
To: Mark Pauley <mpauley@apple.com>
On Aug 19, 2010, at 2:27 PM, Mark Pauley wrote:

> I agree, if a 3rd party can send you a redirect, they probably have your bytes too.  TLS is the only mechanism I can think of that can beat this threat and TLS makes the UI confirmation unnecessary, because we've already established that we trust the endpoint enough to send them our sensitive data.

Revealing data is not the issue.  It is relatively easy to construct a
request that has one meaning on one site (e.g., "unsubscribe me from
your spam list") and an entirely different meaning when redirected
to a different site (e.g., "send this spam message to all of my
facebook friends").  Both sites can be using TLS.  It is a similar but
slightly different problem as CSRF, with the main difference being
that the redirected request is caused by HTTP (as opposed to phishing
or javascript).

Likewise, you don't want write or delete requests made to your game's
webdav file share to be able to make changes to your Apple network
file server.  There are hundreds of other non-browser applications
of HTTP that would be adversely impacted by such a change.

The fact that there are different ways to trigger the same vulnerability
in HTML with javascript and XHR POST is a separate issue that *this* WG
has no ability to fix.  The IETF does not deliberately add new security
holes to a standards-track protocol just because some developers are
irresponsible.

....Roy
Received on Thursday, 19 August 2010 22:11:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:24 GMT