Re: User confirmation and 307 redirects

On Thu, Aug 19, 2010 at 3:11 PM, Roy T. Fielding <> wrote:
> 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.

If you think that 307 redirects are a security vulnerability, then
should should remove them from the protocol.  Trying to atone for the
security sins of the protocol by punting security to the user is
security theater.


Received on Thursday, 19 August 2010 22:21:08 UTC