7

I'm reading OWASP's Secure Coding Practices Checklist and under their "Input Validation" section they have an item that reads:

Validate data from redirects (An attacker may submit malicious content directly to the target of the redirect, thus circumventing application logic and any validation performed before the redirect).

I'm drawing a total blank on what they mean here!

Are they saying that an attacker could put a redirect request inside an HTTP request and just have the webserver execute the redirect, bypassing the normal URL the request would go to (and any server-side validation accompanying it)? If so, what would such an embedded redirect look like and how to I detect it? What does it mean to validate against it (as they say)?

And, if I'm totally wrong in my interpretation, what is it that they're talking about, and can someone give me a concrete example? Thanks in advance!

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
zharvey
  • 911
  • 3
  • 10
  • 14

2 Answers2

7

Good answer from alexwen, although I think his answer is more of a generic parameter sanitization problem, not exactly what OWASP is referring to. I think OWASP may be referring to any of the following concepts.

Revalidating Data From Redirect

OWASP is talking about a different kind of scheme where one URL does some processing (i.e. validation), then redirects to another URL to complete. For example, imagine two URLs, one is /checkout and the other is /ship. The /checkout URL checks the credit card information, checks that the parts are in stock, etc. then redirects to /ship. The /ship URL actually creates a work ticket to pull the parts and ship them.

If the attacker knows this setup, then attacker can just POST the relevant shipping data directly to the /ship URL, bypassing all of the validation performed in the first URL, and getting some products for free.

I've personally never seen a validation scheme this dumb, but it seems to be what OWASP is referring to.

Post-Redirect-Get Pattern

The PRG pattern means redirecting to a GET request after successfully processing a POST. This is used to avoid the horrendous usability problem of a user clicking the back button in a browser and the browser asking the user an obscure question about whether or not to "repost form data". (I've seen this trip up so many users that it's not even funny.)

I've never seen this used in such a way as to be vulnerable to attack, but in theory a poor authentication scheme might use PRG to process authentication credentials, then redirect to a "members-only" page or something stupid like that. Again, I've never personally seen in this in the wild, so I'm not 100% sure that's what OWASP is talking about, either.

Blind Redirect

I'm not sure that this is what OWASP is talking about, but this is actually a common vulnerability. Unlike the previous two vulnerabilities that I described, I have actually seen this in the wild many times. This common mistake is that the URL to redirect to is specified in the original URL query and is not validated, e.g.:

http://my.badsite.com/redirect.php?destination=http://google.com

If redirect.php unconditionally redirects to whatever URL is passed in (e.g. in PHP, header("Location:$location")), then an attacker can construct a URL that looks safe but actually leads to a dangerous site. For example, if the blind redirect script is at http://nytimes.com/redirect.php, then the attacker sends the victim a link like http://nytimes.com/redirect.php?destination=http://spyware.malware.xxx/get_pwned and a naive user looks at the link and thinks he is going to the NYT website. (Depending on the exact nature of the script, the attacker might be able to URL encode part or all of the destination URL in order to further obfuscate it.)

A redirect script should inspect the destination URL to make sure that it is appropriate, probably through some kind of whitelisting.

Mark E. Haase
  • 1,902
  • 2
  • 15
  • 24
4

A common practice after a form post is to redirect a user to success page:

POST /my-form HTTP/1.1
Host: www.myhost.com


HTTP/1.1 302 Moved Temporarily
Location: https://www.myhost.com/form-success.html?message=%3Cb%3ESuccess!%3C/b%3E

In this example the user is redirected to the form-success.html page, with the message of:

<b>Success!</b>

We have javascript on form-success.html that takes the message and appends it to the document. Without sanitizing the response, you are opening yourself up to an XSS attack.

Because the person coding this fictional website assumed that it would only be accessed through the form post and after the redirect they did not put the proper checks in place on the message parameter in order to prevent a malicious person from substituting a script tag for the benign success message.

You should always validate/escape any content that comes from the browser, in the URL parameters or form posts, irrespective of whether or not it comes after a redirect. Treat all input with suspicion and you will go a long way toward protecting yourself from this style of attack.

alexwen
  • 156
  • 2