The Oauth2.0 protocol says the following:
https://www.rfc-editor.org/rfc/rfc6749#section-10.6
When the attacker's user-agent is sent to the authorization server to grant access,
the attacker grabs the authorization URI provided by the legitimate client and replaces
the client's redirection URI with a URI under the control of the attacker. The attacker
then tricks the victim into following the manipulated link to authorize access to the
legitimate client.
How can an attacker trick/redirect the victim to a manipulated link? How easy is that to do? Can someone give me an example of this attack?
I'd read the next paragraph:
The victim is then redirected to an endpoint under the control of
the attacker with the authorization code. The attacker completes
the authorization flow by sending the authorization code to the
client using the original redirection URI provided by the client.
The client exchanges the authorization code with an access token
and links it to the attacker's client account, which can now gain
access to the protected resources authorized by the victim (via the
client).
how it works? the attacker owns his website, www.attacker.com. after grabbing the authorization URI, the attacker replaces the "redirect_uri" param and places there his own URL, "www.attacker.com". then, the oauth-server redirects back to this URL, with the auth code as a param (this is the response). this way the attacker gets the code, and then easily he exchanges it with an access token, and bang! he has access to the "resource server" on behalf of the poor victim.
Related
I'm working on authentication part with Google OAuth2 API.
I'm using "server" flow, not "implicit".
When implementing step 1 for obtaining code guidelines recommend using the state parameter to ensure that in the end, the service provider will receive the response that correlates to the auth request he initiated.
See https://developers.google.com/identity/protocols/OpenIDConnect#createxsrftoken
I understand that there is a possibility that code can be stolen, and redirect_uri guessed.
But I don't understand why this is called anti-CSRF protection?
According to wiki CSRF attack "exploits the trust that a site has in a user's browser".
As I understand something sensitive should be kept in the browser to make CSRF attack possible. The most classic example - an authentication cookie.
But what is kept in the browser in relation to OpenID-connect code flow?
It is just two consequent redirects from service provider to identity provider and back. The code itself is passed on callback as a URL param.Browser's role is passive - to be redirected two times. Nothing is stored here.
So my question is what exactly kind of CSRF attack does state prevent? Can anyone give a detailed example? Or is it just misusing of term "CSRF" in google guidelines?
When using the authorization code flow in OAuth2, the user browses to the client application, which then redirects the browser to the authorization server to be logged in and get an access token.
302 https://auth.server/authorize?response_type=code&client_id=....
After you've signed in on the authorization server, it will redirect you back to the registered redirection URI with the issued code. The client application will then exchange the code for an access token and optionally go to a URL encoded in the state parameter.
Now, an attacker could trick you into clicking a link (from an email or something) like:
<a href="https://auth.server/authorize?response_type=code&client_id=...."
This would execute the same request to the authorization server. Once you logged in and the authorization server redirects you back to the client application, the client application has no way of knowing whether the incoming GET request with the authorization code was caused by a 302 redirect it initiated or by you clicking that hyperlink in the malicious email.
The client application can prevent this by sticking some entropy in the state parameter of the authorization request. Since the state parameter will be included as a query parameter on the final redirect back to the client application, the client application can check if the entropy matches what it kept locally (or in a secure HTTP only cookie) and know for sure that it initiated the authorization request, since there's no way an attacker can craft a URL with entropy in the state parameter that will match something the client application keeps.
The objective of CSRF is to dupe the user into performing an action (usually a destructive write action that the user wouldn't do under normal circumstances) in a website by clicking on a link sent by the attacker. An example of such an activity could be deletion of user's own account in the website. Assuming that the user is logged into the website, the requests originating from the user's browser are trusted by the website server which has no way to find out (without the CSRF token) that the user is actually duped into making that request.
In case of Google OAuth2 (Authorization code grant type), note that the initial request to the Google auth server contains the url that the user actually wants to visit after succesful authentication. An attacker can carefully contruct that url with some malicious intent and make the user use it.
The state token check enables the server ensure that the request is indeed originated from its own website and not from any other place. If the attacker creates the url with some random state token, the server wouldn't recognise that and reject the request.
If you have such doubts, best resource you must refer is the specification. For OAuth 2.0, this is RFC6749 . There is a dedicated section in the specification which discuss about Cross-Site Request Forgery
Cross-site request forgery (CSRF) is an exploit in which an attacker
causes the user-agent of a victim end-user to follow a malicious URI
(e.g., provided to the user-agent as a misleading link, image, or
redirection) to a trusting server (usually established via the
presence of a valid session cookie).
From the specification perspective, you must implement state handling mechanism into your application
The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.
And about a detailed explanation, directly from specifaciton
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's
Injecting an authorisation code from attacker, then manipulating your application to behave in a manner attacker wants.
I've read through a lot of long explanations of CSRF and IIUC the core thing that enables the attack is cookie based identification of server sessions.
So in other words if the browser (And note I'm specifically narrowing the scope to web browsers here) does not use a cookie based session key to identify the session on the server, then a CSRF attack cannot happen. Did I understand this correctly?
So for example suppose someone creates a link like:
href="http://notsosecurebank.com/transfer.do?acct=AttackerA&amount;=$100">Read more!
You are tricked into clicking on this link while logged into http://notsosecurebank.com, however http://notsosecurebank.com does not use cookies to track your login session, and therefore the link does not do any harm since the request cannot be authenticated and just gets thrown in the garbage?
Assumptions
The OpenID Connect Server / OAuth Authorization server has been implemented correctly and will not send authentication redirects to any URL that you ask it to.
The attacker does not know the client id and client secret
Footnotes
The scenario I'm targeting in this question is the CSRF scenario most commonly talked about. There are other scenarios that fit the CSRF tag. These scenarios are highly unlikely, yet good to be aware of, and prepared for. One of them has the following components:
1) The attacker is able to direct you to a bad client
2) The attacker owns that client
3) The attacker has the secret for that client registered with the OAuth Authorization Server
4) The attacker is able to tell the Authorization Server that authenticates you to redirect back to the bad client after you have been authenticated with the proper server.
So setting this up is a little bit like breaking into Fort Knox, but certainly good to be aware of. For example OpenID Connect or OAuth Authorization Providers should most likely flag clients that register redirect URLs pointing to redirect URLs that other clients have also registered.
The most common / usually discussed CSRF Cross Site Request Forgery scenario can only happen when the browser stores credentials (as a cookie or as basic authentication credentials).
OAuth2 implementations (client and authorization server) must be careful about CSRF attacks. CSRF attacks can happens on the client's redirection URI and on the authorization server. According to the specification (RFC 6749):
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.
[...]
A CSRF attack against the authorization server's authorization
endpoint can result in an attacker obtaining end-user authorization
for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its
authorization endpoint and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of
the resource owner
Theory is, CSRF is not related to the authentication method. If an adversary can have a victim user perform actions in another application that the victim didn't want, then that application is vulnerable to CSRF.
This can manifest in several ways, the most common being that a victim user visits a malicious website which in turn makes requests from the victim's browser to another application, thus performing actions the user didn't want. This way it is possible if credentials are sent by the victim browser automatically. By far the most common scenario is a session cookie, but there can be others as well, for example HTTP Basic auth (the browser remembers that as well), or Windows authentication in a domain (Kerberos/SPNEGO), or client certificates, or even some kind of an SSO under certain circumstances.
Also sometimes application authentication is cookie-based, and all non-GET (POST, PUT, etc.) requests are protected against CSRF, but GETs are not for obvious reasons. In languages like PHP, it is easy to make calls intended to be POST requests also work as GETs (think of using $_REQUEST in PHP). In that case, any other website can include something like <img src='http://victim.com/performstuff¶m=123> to have actions performed silently.
There are also less obvious CSRF attacks in complex systems or flows, like for example the CSRF attacks against oauth.
So if a web application uses say tokens (sent as request headers, instead of session cookies) for authentication, meaning a client will have to add the token to each request, that is probably not vulnerable to CSRF, but as always, the devil is in the details.
Here is the attack scenario of how an attacker can takeover victim's account:
Attacker is authenticated at provider.com
Attacker initiates a process of authenticating with provider.com at some site.com
Attacker doesn't exchange an auth code for an access token and copies the link https://provider.com/oauth/authenticate?code={authorization-code}which is then sent to a victim
The victim is authenticated on provider and clicks the above link, exchanges an auth code for an access token and ends up being authenticated on site.com with the victim's account
Attacker now continues the authorization process and exchanges the same auth code for an access token and ends up being authenticated on site.com with the victim's account.
How to prevent this kind of attacks that exploit a weakness in the OAuth protocol?
Thanks all in advance!
If a state parameter was maintained by site.com then the attacker's state code would be bound to his/her browser but not the victim's. Therefore site.com would not be able to correlate the state code with the victim's browser session when he/she clicks on the malicious URL.
Have a look at what the Oauth2.0 spec says about this.
The victim authenticates via system browser at the Authorization Server in a Oauth2 authorization code flow and is issued a session cookie by the Authorization Server
The victim is tricked into clicking at a link on attackers web site which launches an Oauth2 authorization request via victims browser towards the Oauth2 Authorization Server with client ID and redirect URI for the attackers Oauth2 client
The Authorization Server will not need to authenticate victim since a session cookie is already issued by the Authorization Server but just ask victim to grant the attackers client access – which in this case the victim is assumed to do
The Authorization Server will redirect victims browser to the attackers redirect URI (which is assumed to point to a web application) with authorization response with Authorization Code for victim
The attacker is now in possession of Authorization Code for the victim, that he or she can exchange for refresh & access token
What are the best possible precautions against this except for the victim not to accept to grant the attackers client access?
I mean the average internet user will typically click accept to a lot of stuff on a normal day without thinking much about it.
For this to work, the attacker would have to register his client with the authentication provider, which in an enterprise setting should not be possible. Also as the redirect URI is not registered, the AP should never redirect the user back to the attacker.
In case of public APs where anyone can register a client, this is indeed a problem, but this is also the point in a sense. If the user authorizes the attacker's app, then the attacker's app will have access. As it is not different from normal apps in this regard, users will have to take care (while you are right, the majority of users will just click OK to anything).
The AP could still maintain a blacklist based on user reports for example, but that is a weak control. The best an AP can probably do is provide adequate information and warnings for the user, delaying the OK button for a few seconds to try to get them to read, etc.
In Implicit Grant, the access token is sent back in the callback URL. Is this not a security risk because, if this callback URL is cached in the hop. In general it is advised, not to send sensitive data in URL params, and this access token will be a token to access all secured user resources. So why is it getting passed as fragment in URL
Hmmm, I am afraid there are some misunderstandings in the answers above. While URL query strings are secured when using TLS, and thus the access token is protected in flight, it is exposed in the users browser (part of their history) and also in the destination web browser logs. Most web browsers will log the entire URL of the incoming request. Their is an additional issue known as the "referer" leak problem wherein the query string will be passed to third-party sites. A good overview may be found at:
http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Elaborating on #vlatko's response...
To mitigate the risk of sending the token in the fragment (or via any other OAuth2 grant):
ensure that the OAuth endpoint and the callback endpoint are TLS (https) (See countermeasures)
send a state parameter to prevent cross-site forgery (Also see: https://www.rfc-editor.org/rfc/rfc6749#section-4.2.1)
Issuing short-lived access token (as #vlatko said) will reduce the impact of a leaked token, but is not a preventative measure.
Like you pointed out, the token is passed the URI fragment. Since browsers don't send fragments of URLs to HTTP servers, the chances that someone will eavesdrop and pick up the access token are drastically reduced.
There are also additional security measures, like only issuing short lived access tokens in the implicit grant flow.
More info in the OAuth2 threat models document.