In the era where security vulnerabilities have logos, stickers and mainstream media coverage – it seems to be really easy to attract attention with simple input validation flaws. Quoting:
“Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners.”
Oh yes – and amongst a myriad of other scenarios this also applies to URLs of redirect based authentication/token protocols like OAuth2, OpenID Connect, WS-Federation or SAML2p. And guys like Egor Homakov have already shown a number of times that you are bound to be doomed if you give external parties too much control over your redirect URLs.
The good thing is, that every serious implementer of the above protocols also reads the specs and accompanying threat model – e.g. quoting the OpenID Connect spec (section 22.214.171.124) :
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison)”
Or my blog post from over a year ago:
“If you don’t properly validate the redirect URI you might be sending the token or code to an unintended location. We decided to a) always require SSL if it is a URL and b) do an exact match against the registered redirect URI in our database. No sub URLs, no query strings. Nothing.”
So this type of attack is really a thing of the past – right?