httpsecurityowaspsecure-coding

Open Redirect with known page but user-supplied url parms. Possible?


We're reviewing some security findings and I'm trying to understand a finding about open redirects. Essentially the question is: Can a redirect to a hard-coded known-local path with user-supplied parameters in the query component be an open redirect?

Say you have the following in page1.aspx:

Response.Redirect("/page2.aspx?parm=" + Request["user-supplied-value"]);

Can page1.aspx, in and of itself, be an open redirect? Is there any value that can be supplied in the request to page1 that would cause a browser to ignore the "page2.aspx" path of the redirect and instead redirect to the user-supplied-value in the query part of the redirect url?

Please note, I am NOT referring to the situation where page2.aspx then takes the value of the parm and mindlessly redirects to it, that is an open redirect. I'm referring more to something like how a semicolon in a SQL Injection might terminate leading text and allow you to inject a new statement inline. I cannot think of a value for a parm in the query part that would essentially override the path part.

To be explicit, if you think the answer is "Yes, open redirects happen when you redirect to user-supplied inputs" go read the question again. I am not referring to the situation where page2 blindly redirects to the value supplied in the parameter. Rather can the redirect in page1 where the path component is hard-coded but has user-supplied parms be an open redirect?


Solution

  • It is not possible to make a modern browser go to a different page than page2.aspx just by manipulating the parameter. Therefore I wouldn't call this an open redirect, but it still might be a weakness, depending on what exactly page2.aspx does. It might become an actual open redirect as well in somewhat unexpected ways, like for example if there is header injection in page2.aspx and the attacker can inject a whole new Location header. Or this might be used to circumvent weak referrer-based csrf protection. Or it might just provide a way for an attacker to perform phishing by providing a link in a trusted application screen that does something the user didn't want to do.

    So in short this might just be a building block in a more complex attack - but it might be an important one, or not even a weakness, it all depends on page2.aspx.