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.
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.
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.:
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.