This is similar to this question, but a bit more specific.
TL;DR; Are there any security concerns with allowing user-provided relative URLs in the Location:
header on redirect?
Background:
I'm writing a small proxy for use in front of CouchDB. To authenticate to the CouchDB API, one must submit a POST to the /_session
endpoint as described here.
This endpoint takes an optional query parameter, next
, which, when present, will cause a successful authentication request to respond with 302
and a Location:
redirect, rather than a simple 200
.
Now CouchDB has what appears to me to be an insecure implementation of this. The next
value is simply appended to the server hostname (with no slash!!). So a request like this:
POST /_session?next=foobar
Will get a response which includes:
Location: http://someserver.comfoobar
I think this is pretty clearly bad, but at least the damage is only limited to authenticated requests, so a random phisher probably can't do a lot with it. But it still makes me a bit uneasy.
So it seems to me that some validation needs to be done. At minimum, a /
should be pretended to the user-provided URL. But I'm thinking a simpler approach might be to simply validate that the user-provided URL is relative, and then just respond with that alone.
So for my example:
POST /_session?next=foobar
Would respond with:
Location: /foobar
Is this a safe approach?