2

I'm trying to determine what a client should do with headers on receiving a 303 (See Other) from the server. Specifically, what should be done with the Authorization header that was sent on the initial request?

Here's the problem: the client makes a request to myserver.com (HTTP request method is not relevant here) and the server at myserver.com responds with a 303 and the Location header contains otherserver.com/some_resource/. Tools like Postman and curl will follow the redirect by passing all the same headers in the subsequent request to otherserver.com. I haven't found a way to make these tools drop the headers.

In the case I've described, sending the Authorization header to otherserver.com seems like a security risk: otherserver.com now knows my token and possibly what host it can be used on so now the token is compromised. This can also cause errors, depending on how the destination host is configured. In the case where the redirect is to another resources on the same host (ie, myserver.com) then the Authorization header will (probably) need to be sent, and because it's the same host nothing is compromised.

Effectively, in different situations it seems that the correct behaviour is different. The relevant section in the RFC does not address this issue. In developing my own API, I've written documentation telling API clients to drop the Authorization header on redirect to otherserver.com. However, based on mucking around with curl and Postman, it's not clear to me either (a) what the default behaviour is for a typical HTTP client library or (b) whether HTTP client libraries permit easy modification of the HTTP headers before following a 303 redirect. As a result, it's possible my suggestion isn't practical. I also know of no way for the server to instruct the client as to what it should do with headers on following the 303 redirect.

What should a HTTP client do with the headers when it follows a 303 redirect? Who is responsible for deciding whether to use the same headers on the redirect, the HTTP client or server?

Community
  • 1
  • 1
Paul Holden
  • 850
  • 1
  • 8
  • 24

1 Answers1

-1

You can argue that when sending the 303 with otherserver.com's Location, myserver.com trusted otherserver.com to handle your token. It could have sent the token in the background as well. From the client's perspective, the client trusts myserver.com to handle the token, store and verify it securely, etc. If myserver.com decides to send it on to otherserver.com, should the client override? In this case it can of course, but in general I don't think it should.

As an attacker does not control the response headers from myserver.com which is a legit resource, I think in general it is secure to send the token by default to the other server it specifies, maybe unless you have some good reason not to (say an explicit policy on the client).

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
  • Downvoter: may I ask why? I may be wrong, but can you point out where? – Gabor Lengyel Apr 03 '18 at 16:32
  • I'm not the downvoter, but I can give you my thoughts. The RFC doesn't say anything about whether the server should trust the destination to which it's redirecting the client. I don't see any reason, for example, that I can't redirect a client to Google, or whatever. If I could only use 303 with sites I trust, then it would be of more limited use. The RFC doesn't suggest such limited use of 303s. – Paul Holden Apr 05 '18 at 00:14
  • @PaulHolden I think I can see your point, but look at it from the credential holder's (the user's) perspective. He has a token that he sends to the server. If the server is careless, it could store it in a plaintext file. It could send it in a plain email. Or it could call another api with the credentials in the background, and return the results, which it doesn't want to do, because it's much more resource efficient if the client calls the other one directly. The client has an inherent trust in the server *anyway*. Why would it pick this one bit of info, the 303 location, as untrusted? – Gabor Lengyel Apr 05 '18 at 11:39