Phil,
You know not everyone gets a personalized example:)
In the below examples there is no proxy or other compromise of the client
required only the ability to do what appears to be a SSO login using OAuth.
The attacker needs only a web browser.
When they tales about compromised clients, th
See below...
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-06-29, at 1:54 PM, John Bradley wrote:
> No,
>
> Trying to explain this over email is a challenge:)
>
> This apples to both native apps and Web Servers who are OAuth Clients.
>
> Imagine there are two web
No,
Trying to explain this over email is a challenge:)
This apples to both native apps and Web Servers who are OAuth Clients.
Imagine there are two web servers that authenticate people with Facebook
Connect (just an example).
Site A is I love Puppies (An evil site)
Site B is I Hate Larry Ell
John,
I think that helps to clarify the authorize issue.
But they were talking about a phishing site obtaining a legit access token from
Facebook.
> Let's take Soluto's metro app as an example to describe the problem. The app
> supports Facebook Login. As an attacker, we can write a regular Fac
The attack requires a web browser that allows modifying the value of the of the
redirect URI. It is dead simple cut token or code from the string and paste
in the token or code that was granted by the user you want to impersonate.
OAuth responses are not signed or audience restricted to the cl
If an attacked can modify the communications over TLS between the client and
the authorization server, then I think there are many other options open to the
attacker.
-- Dick
On Jun 29, 2012, at 11:53 AM, Phil Hunt wrote:
> I'm not seeing how client id helps if a proxy server is somehow involv
We need more info on the inject method the researchers used before we can
account for it.
Phil
On 2012-06-29, at 12:16, John Bradley wrote:
> The same thing can be done with code.
>
> If the token endpoint checks the client_id before giving out the access token
> then the attack on code can
The same thing can be done with code.
If the token endpoint checks the client_id before giving out the access token
then the attack on code can be prevented, as the token endpoint won't return
the access token.
The spec dosen't require authenticating public clients currently so it is a
slightl
I'm not seeing how client id helps if a proxy server is somehow involved with
inserting the bearer token as the researchers suggested.
Phil
On 2012-06-29, at 11:30, John Bradley wrote:
> I think they only exploited the implicit flow.
>
> My point was that there is a way you could do the s
I think they only exploited the implicit flow.
My point was that there is a way you could do the same thing with code if it is
a public client that is not authenticating to the token endpoint.
In general making identity assumptions in the client based on a code or
access_token has risks that
I agree, If there is no good reason for the token endpoint not to check the
client_id with public clients then we should add that it SHOULD or MUST be
checked for authorization_code and refresh_token grant_type.
Though I don't know if we want to get carried away with the whole agreeing
thing.
I'm not clear whether the MS Security Researcher hack was with the
authorization code or the access token. If the latter, the client_id is out of
the picture isn't it?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-06-29, at 11:14 AM, Dick Hardt wrote:
>
> On Jun
+1 to Dick's suggestion
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick
Hardt
Sent: Friday, June 29, 2012 11:14 AM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue
On Jun 29, 2012, at 11:06 AM, J
On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
> It is nice to know that I may occasionally be correct:)
You must be delighted when it happens! ;)
> While you may assume that it is reasonable for a client with a code to make a
> request to the token endpoint including it's client_id and the
It is nice to know that I may occasionally be correct:)
For Server based confidential clients the risks are quite minimal as Justin
points out. There are likely other more interesting things you could do if
you already have the ability to run arbitrary code on the server.
No matter what flow
It's all about how you can swipe a token and inject it into another
application. It's easier to trap and inject a token in the implicit flow
because it's exposed to the user agent and there's no client secret tied
to the token's issuance. To get the same trick to work with the code
flow on serv
Hi John
On Jun 29, 2012, at 1:43 AM, John Bradley wrote:
> Authenticating to the client is NOT safe with all of the flows
you are perfectly right here. At the begin of this discussion and reading your
blog post I was under the impression that this "attack" was tight to the use of
the implicit
17 matches
Mail list logo
