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 3.1.2.1) :
“redirect_uri
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?
leastprivilege.com 
It really should be a thing of the past but unfortunately I am sure there are still plenty out there that have an “overconfidence” with their partners and blatantly trust any input given to them without any second thought. If it’s not rule #1, it’s definitely in the top 10… don’t trust any of your input; client or server side.
That’s not the point – you don’t allow dynamic redirect URIs. (period). It’s not the first time this went wrong (see facebook, github etc)
The spec says it, the threat model says it. If you still do it you a) implement the protocol incorrectly, b) violate most basic security 101
I suppose it would have been better stated as validate that the input matches a pre-defined configuration/registration and then use what you have from that config/reg; not what is provided. If so, then the whole dynamic redirect threat is basically non-existent.
We are setting and running Identity Server and Authorization Server together. We try some functionality for us program but we didnt find any solutions.
For exp.
Class A {
[CompanyAuthorization(EntityName=’x’, Action=’BusinessProcess’, Module=”A”, SubModule=”B”]
public void Businessprocess()
{
}
}
we try authorize this method using IdentityServer and AS mixed but we cant find how we must set authorization server for this case. (Application, Client, Scope etc) We dont use web api, our project is Desktop and Web Mixed.
if a User login for a A company can do that ( EntityName=’x’, Action=’BusinessProcess’, Module=”A”, SubModule=”B” ), other companies not allowed.
can u advice for this case.
best regards,