]
Sent: Thursday, February 23, 2012 5:03 PM
To: Kristoph
Cc: Lee, David; oauth@ietf.org (oauth@ietf.org)
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
As we have shown in our Feb 17th email, the negative consequence is a violation
by the user of the service agreement, that is, the user
In that case the game is the client as it is using the access token to get to
the protected resource (FB graph API in this case). The resource owner can
revoke a granted scope at the authorization server after the fact. That is
how Facebook works now, as near as I can tell.
Not that Facebook
On 24 Feb 2012, at 01:02, Wenjie Lin wrote:
> As we have shown in our Feb 17th email, the negative consequence is a
> violation by the user of the service agreement, that is, the user is able to
> play the game but the client cannot post messages on behalf of the user.
That's not a negative wi
As we have shown in our Feb 17th email, the negative consequence is a
violation by the user of the service agreement, that is, the user is able
to play the game but the client cannot post messages on behalf of the user.*
***
*"Scope Attack*
OAuth authorization of services is associated with serv
Privilege de-escalation is not an attack. Your argument comes down to "I can
change something and no error is shown so it's an attack" but you've not
actually shown any sort of negative consequence because, you know, there isn't
one.
]{
On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote:
> We ass
I'm still not seeing how "user choice" can become an "attack"
While a user might hack the request or a phishing attempt might generate a link
that requests an unusual scope combination, it shouldn't matter since the
authorization server should allow the user to decline specific scopes if they
w
We assume that the authorization server is trustworthy and won’t do
anything that violates the spec. We want to prevent attacks by the client
on the user, as well as the attacks by the user on the client.
The scope attack is by the user on the client. From the point view of the
user it is not
Yes, OpenID Connect deals with the issue by using a signed request extension
in the cases where the client needs to be certain the request is only from the
legitimate client and not tampered with.
As you observe anyone can send a request the client_id and redirect_uri are not
secret in any way
FWIW, it could be that the authorization request was authored by
neither the client nor the user. An unrelated fourth party can
construct an authorization endpoint URL using a client_id that isn't
his own and send a user there. This wasn't possible in OAuth 1 because
of how it used request tokens.
The consensus seems to be, and I agree, that this shouldn't be
considered an "attack," but that's really just nomenclature. I do
concede that there is a spec issue here that I failed to appreciate at
first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued
access token scope is different
On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
>
> On 21 Feb 2012, at 21:59, John Bradley wrote:
>> This 'attack' is one that only works with badly designed clients that are
>> making unwarranted assumptions about the behaviour of the Authorization
>> server.
>
> Unwarranted assumptio
On 21 Feb 2012, at 21:59, John Bradley wrote:
> This 'attack' is one that only works with badly designed clients that are
> making unwarranted assumptions about the behaviour of the Authorization
> server.
Unwarranted assumptions? The spec in 3.3 says:
"If the issued access token scope is d
From: Wenjie Lin
> To: William Mills
> Cc: John Bradley ; "oauth@ietf.org (oauth@ietf.org)"
> ; "Lee, David"
> Sent: Tuesday, February 21, 2012 12:07 PM
> Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
>
> Our understanding is that you agree t
; "Lee, David"
Sent: Tuesday, February 21, 2012 12:07 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
Our understanding is that you agree this is indeed a scope attack, that is, the
user may get services, which are different than the client has agreed.
If the protoc
t out as an implementors note or a nota
> bene type editorial comment?
>
> -bill
>
>
> --
> *From:* Wenjie Lin
> *To:* John Bradley
> *Cc:* "oauth@ietf.org (oauth@ietf.org)"
> *Sent:* Saturday, February 18, 2012 8:18 PM
&
e persistence of scopes in
> tokens
> >> note would be as far as I would go.
> >>
> >> John B.
> >>
> >> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:
> >>
> >> > I agree with others - this is not an attack on the protocol. The use
t;
>> John B.
>>
>> On 2012-02-18, at 3:34 AM, Shane B Weeden wrote:
>>
>> > I agree with others - this is not an attack on the protocol. The user
>> > has
>> > the choice about which scope to grant and the client's redirect to the
>> > authorizati
Wenjie Lin
To: John Bradley
Cc: "oauth@ietf.org (oauth@ietf.org)"
Sent: Saturday, February 18, 2012 8:18 PM
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
We appreciate your attention and response to our report.
Since Authorization Server obtains the scope information
is actually granted. The client needs to handle
> > cases where that differs from what it originally wanted.
> >
> >
> >
> >
> > From: Wenjie Lin
> > To: oauth@ietf.org
> > Date: 18/02/2012 12:12 PM
> > Subject: [OAUTH-WG] A Scope Attack aga
thorization
> server decide which scope is actually granted. The client needs to handle
> cases where that differs from what it originally wanted.
>
>
>
>
> From: Wenjie Lin
> To: oauth@ietf.org
> Date: 18/02/2012 12:12 PM
> Subject: [OAUTH-WG] A
ecide which scope is actually granted. The client needs to handle
cases where that differs from what it originally wanted.
From: Wenjie Lin
To: oauth@ietf.org
Date: 18/02/2012 12:12 PM
Subject:[OAUTH-WG] A Scope Attack against OAuth 2.0
Sent by:oauth-boun...@ietf.org
es, and in fact the auth server is
> expected to communicate to the user what they are approving.
>
> Can an attacker cause a user to approve a token with an unexpected scope?
> That would be a big problem.
>
> ____________
> From: Wenjie Lin
> To: oau
enjie Lin
> To: oauth@ietf.org
> Sent: Friday, February 17, 2012 6:07 PM
> Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0
>
> We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope
> attack, provide a live-demo of the attack on Facebook, and prop
tf.org
Sent: Friday, February 17, 2012 6:07 PM
Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0
We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23),
called scope attack, provide a
live-demo of the attack on Facebook, and propose a fix with discussions.
Scope Attack
OAuth authoriz
We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called *scope
attack*, provide a live-demo of the attack on Facebook, and propose a fix
with discussions.
*Scope Attack*
OAuth authorization of services is associated with service agreement scope.
For instance, Client provides an onli
25 matches
Mail list logo
