RE: Redirection of a POST as a GET

<< it seems VERY reasonable to not allow the
scheme to change in a redirect ... certainly not a down grade in security
level.>>

Even here there's likely to be a problem.  A common pattern for web-based logins is to send credentials to a HTTPS page, and that returns a redirect with a Set-Cookie header containing an authenticated token.  The redirected page is very often a HTTP page, and hence would trigger the warning in your model.

-Eric

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On Behalf Of David Morris
Sent: Thursday, March 08, 2007 1:12 PM
To: Adrien de Croy
Cc: ietf-http-wg@w3.org Group
Subject: Re: Redirection of a POST as a GET



If you have a trust relationship with the original server, you darn well
better beable to trust what that server does with your data ... and in my
mind, that extends to trusting that server to not redirect to an untrusted
server.

In any case, if this data is sensitive, you should make sure it is sent in
an SSL protected session and it seems VERY reasonable to not allow the
scheme to change in a redirect ... certainly not a down grade in security
level.

Telling the average user there is a concern isn't worth the effort.

On Fri, 9 Mar 2007, Adrien de Croy wrote:

>
>
> one thing - are there any security implications with a browser say
> automatically resubmitting some POST data to another server based on a
> redirect code?
>
> Quite often this data will be usernames and passwords.
>
> I'm not sure how comfortable I would be typing my username and password
> into a form, and then having my browser automatically sending that
> information off to another site without my knowledge because the site
> sent back a 307.  There's no obvious trust association.  By rights I
> really should have been redirected to the new site by the request that
> served the form.
>
> For robots I can see the need to do that.  Maybe the answer is
>
> 1. Redefine 301/302 to allow GET after a POST, making the entire
> industry compliant.
> 2. Leave 303 as is.
> 3. MUST use 307 if you want it to be the same method.
>
> servers and proxies and websites are going to bear the brunt of any
> changes to this - it's trivial to support both the new and old codes in
> a client, but when to choose which one to use in a server is another matter.
>
> knowing there is widespread understanding of the new codes in browsers
> allows a server to start using them, but then there's the issue of the
> countless CGI applications that set their own return codes from script.
> A server hosting such a script could automatically translate the code I
> guess, with the expectation that if it was a POST, then translate
> 301/302 to 303, with optional configuration override.
>
> Adrien
>
> Julian Reschke wrote:
> >
> > Anne van Kesteren schrieb:
> >>
> >> On Thu, 08 Mar 2007 00:57:14 +0100, Henrik Nordstrom
> >> <henrik@henriknordstrom.net> wrote:
> >>> In terms of spec writing it's quite disappointing that this industry
> >>> can't accept a clear and well specified "thats the wrong thing to do",
> >>> and instead continues doing the wrong thing forever countless software
> >>> generations after the implementation error has been pointed out.. This
> >>> attitude is quite saddening for the future of the web..
> >>
> >> In terms of implementing it's quite disappointing that spec writers
> >> don't always see a clear message that the industry doesn't want it
> >> the way things are specified and instead requests a different approach.
> >>
> >>
> >> (This is also true, for instance, with the fatal error handling rules
> >> in XML which clearly don't work for the web.)
> >
> > Well, I think it clearly does work (minus the Content-Type encoding
> > issue) for many things, such as feed reading (*), client-side XSLT, or
> > WebDAV. All of these are part of the web.
> >
> > It doesn't work well for XHTML, but that's because the most widely
> > used user agent doesn't support it. I think it's incorrect to blame
> > fatal error handling here.
> >
> > Best regards, Julian
> >
> > (*) The RSS/Atom support in IE7 IMHO requires well-formed content, and
> > gets away with it. Bravo!
> >
>

Received on Thursday, 8 March 2007 21:18:21 UTC