Hi Rui, my fault about the Sophos link. I hadn't read your message carefully
enough, otherwise I would have realized that it was unrelated. - Francisco
>
> From: rui wang
>To: Francisco Corella
>Cc: Nat Sakimura ; matake nov ; Yuch
Hi Nat and Rui,
Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication". No misunderstand
analysis I am looking for, this one covering Oauth 1.0a from our
research lab
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf
Regards
Mark
Francisco Corella wrote on 13/05/2011 17:58:01:
> Francisco Corella
> 13/05/2011 17:58
&g
We wrote a security analysis of double redirection protocols that has a section
on OAuth 2.0 as of draft 11. You can find it at
http://pomcor.com/techreports/DoubleRedirection.pdf
Francisco
--- On Fri, 5/13/11, Mark Mcgloin wrote:
From: Mark Mcgloin
Subject: [OAUTH-WG] Formal security proto
Dick,
> Maybe you should stop using Twitter as anyone that can MITM your
> session can tweet as you since Twitter does not enforce HTTPS on
> twitter.com
Thanks for pointing that out. I haven't looked at the security
posture of Twitter, I just mentioned Twitter because Eran did. The
point I was
Eran,
> The only consequence is compromising the *client*
> login/authentication security. I'm not trying to play it
> down, but I we need to be clear. This is not a compromise of
> the protected resources or authorization server.
We are definitely talking about a compromise of the
protected reso
Eran,
> I don’t think your statement that ‘the IETF should endorse
> lack of security’ is accurate or helpful.
If the IETF endorsed a protocol such that a compliant
implementation allows user impersonation and unauthorized
access to protected resource, then the IETF would be
endorsing lack of sec
David,
> If this is changed to a MUST, Facebook will be in violation of the
> specification moving forward. It is untenable to require all of our
> *client* developers to implement TLS endpoints though we certainly
> support developers who wish to do so. This is very different than
> offerring our
> Another example I mentioned earlier is when the client does
> not expose the protected resources back to the bearer of the
> code. For example, a Twitter application sending you emails
> when someone stops following you. Since all it does is get
> the code and then uses it internally (no user log
Eran,
> Google, Facebook, and Yahoo! already indicated they will not enforce
> such a MUST. I could not get a clear answer from Twitter.
>
> However, no one representing this companies has bothered to express
> this view on the list, and to express how they would like the
> specification to handl
Skylar,
> I'm going to summarize (hopefully faithfully) the attacks
> referenced here, with the hope of attempting to sum up the
> scope of attacks being documented.
Thank you for reading and summarizing the attacks.
> On Apr 1, 2011, at 1:29 PM, Francisco Corella wro
Hi Prateek,
> I would like to strongly disagree with this proposal.
>
> It amounts to explicitly making OAuth 2.0 insecure so as to
> satisfy some mysterious and unspecified set of legacy OAuth
> 1.0 deployments.
>
> The SAML web SSO (artifact) profile - which shares many
> characteristics with
Skylar,
> Right, but just so we are clear, the only case you are
> discussing here is the MITM attack, which George, I and
> others have recently outlined.
There several flavors of MITM attacks, and a passive attack.
See
http://www.ietf.org/mail-archive/web/oauth/current/msg04894.html,
http://ww
Skylar,
> Francisco, correct me if I'm wrong, but in your discussion
> you assume that the application is incapable of keeping
> secrets from the public (eg, mobile, desktop apps, etc.).
> According to the spec, those applications should never
> receive client credentials to begin with. They can'
> So we have 2 different communities of Oauth developers that
> will never agree.
>
> SHOULD: Typically the social networking sites that need to
> cater for tail end developers by not enforcing TLS on
> redirect_uri. It is a risk to think that using strong
> language in the spec will help them app
his be a
better way to simplify?
philphil.h...@oracle.com
On 2011-03-31, at 1:06 PM, Francisco Corella wrote:
Skylar,
> So, imagine a website secured inside a corporate
> firewall. This service needs to access the provider's
> services via OAuth and thus exposes one callback o
Hi Torsten,
> > 4.4.1.6 that you reference you propose the following
> > countermeasure:
> >
> > > o The authorization server shall require the client to authenticate
> > > with a secret, so the binding of the authorization code to a
> > > certain client can be validated in a relia
Skylar,
> So, imagine a website secured inside a corporate
> firewall. This service needs to access the provider's
> services via OAuth and thus exposes one callback open to the
> world for purposes of the OAuth handshake. The redirect URI
> is HTTP since the corporation is having trouble acquirin
Hi Torsten,
> We are discussing TLS right now as a mean to prevent
> impersonation of the end-user's session on the client
> site. Correct? It's definitely a good advice to protect
> session from being highjacked that way. But I'm wondering
> whether this really belongs into the scope of OAuth?
>
y required there for other endpoints. But on the
client there is currently no such requirements. Making the callback a MUST use
TLS is a huge change. EHL From: Francisco Corella
[mailto:fcore...@pomcor.com]
Sent: Tuesday, March 29, 2011 3:50 PM
To: George Fletcher; Eran Hammer-Lahav
Cc: Phil H
document this possible exposure in the security section
such that the spec doesn't preclude the use of OAuth2 with non HTTP based
redirect_uri?
Thanks,
George
On 3/29/11 1:05 PM, Francisco Corella wrote: Eran,
It's not a reasonable compromise. #2 MUST use tls UNLESS of course it
tion attacks? The client
should use cookies and the state parameter to ensure the same user-agent it
redirected to the authorization server is the one coming back. EHL From:
Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Tuesday, March 29, 2011 11:46 AM
To: Phil Hunt; Justin Richer;
his possible exposure in the
security section such that the spec doesn't preclude the use of
OAuth2 with non HTTP based redirect_uri?
Thanks,
George
On 3/29/11 1:05 PM, Francisco Corella wrote:
Eran,
> Can you explain how intercepting the authorization code
> without having access to the client credentials is a
> problem? For the sake of discussion, assume that the client
> has valid and secure credentials that an attacker cannot
> access. Also assume that the client has implemented some
> form
Eran,
It's not a reasonable compromise. #2 MUST use tls UNLESS of course it targets
localhost. If #2 is sent without TLS to a Web server, the authorization code
can be easily intercepted by an attacker. The attacker can then use it to
obtain protected resources by submitting the authorizatio
In my opinion the protocol has serious problems.
The authorization code is a credential that provides access to
protected resources via the client, as well as user authentication
when OAuth is used for social login. If an attacker observes or
intercepts the authorization code, the attacker can pr
e this attack. The “other” social network returns
a token that it actually got from Facebook and gets the client app to use it at
Facebook.
--
James Manger
From: Francisco Corella [mailto:fcore...@pomcor.com]
Sent: Tuesday, 1 March 2011 4:17 PM
To: OAuth Mailing List
Hi James,
I think I got it now. Thanks for explaining it so patiently.
The attack is only possible if there are multiple independent authorization
servers that don't trust each other. But the OAuth specification talks about
multiple resource servers but only one authorization server. I think
Hi James,
> A client that follows HTTP redirects (or Link: header or any
> other variety of hypertext) might get directed to an 2nd
> service while still using the token from the 1st service.
But why would a legitimate authorization server redirect the
client to an attacker's server?
Francisco
the Service Provider."
This is the purpose of the "state" parameter during the approval flows.
Cheers,
Brian
On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella wrote:
>
> Hi James,
>
> You raise an interesting point. I hadn't thought about the
> threat of Log
Hi Mike,
In section 3.2 you say:
> To deal with token redirect, it is important for the
> authorization server to include the identity of the intended
> recipients, namely a single resource server (or a list of
> resource servers).
You should add that each resource server must verify that it
is
Hi James,
You raise an interesting point. I hadn't thought about the
threat of Login CSRF.
> Q. Should an OAuth client app list the authorization server
> in the Origin header of requests to resource servers?
>
> In OAuth (delegation) flows a server dynamically issues
> credentials (such as a b
Hi Torsten,
> > The attacker will not get the access and refresh tokens
> > without the client_id, but doesn't need to.
>
> whether this is an obstacle mainly depends on whether a
> client secret is associated with this client_id.
You're right, I meant to say client_secret, not client_id.
> ...
Hi Torsten,
> 4.4.1.2. Threat: Eavesdropping authorization codes
>
> The OAuth specification does not describe any mechanism for
> protecting authorization codes from eavesdroppers when they are
> transmitted from the Service Provider to the Client and where the
> Service Provider Grants an Acce
Hi,
We've written a technical report that has a security analysis of
double-redirection protocols such as OpenID and OAuth. Section 3.5 discusses
OAuth 2.0. Most of section 4 may also be of interest to this list. You can
find the report at
http://www.pomcor.com/techreports/DoubleRedirection.
co
--- On Sat, 1/22/11, Francisco Corella wrote:
From: Francisco Corella
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and
OAuth2 HTTP Authentication Scheme
To: oauth@ietf.org
Cc: "Karen P. Lewison"
Date: Saturday, January 22, 2011, 6:28 AM
Brian,
>
Brian,
> I guess it's somewhat moot now because client assertions
> have been removed from the latest draft. However, I don't
> believe there anything saying that client assertions had to
> be bearer assertions. Nor would that really have been
> appropriate for the framework spec.
Ah, so I was
SAML subject confirmation, please
feel free to review and comment on the SAML Bearer Assertion Grant Type
Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00 :)
-Brian
On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella wrote:
Mike,
As assertion use is described in the s
Mike,
As assertion use is described in the spec, a client assertion does not provide
any security whatsoever. How do you handle subject confirmation in your
implementation? (See section 2.4.1.1 of the SAML specification.) In other
words, how does the authorization server know that the client
Phil,
> What if strong authentication of client (between client and
> AM) happened OOB? Instead of passing a client_assertion, why
> not pass a client_token? In a sense we would be repeating
> the pattern for users and applying it to clients. A client
> use its own client_token to obtain access t
I wanted to point out that an assertion by itself cannot
authenticate the client, contrary to what the draft seems to
imply.
Section 3.2 of the spec says that, when using a client
assertion, the client sends two parameters:
client_assertion_type and client_assertion. This does not
work. A client
Dick,
> An example of a custom scheme would be what Pounce popularized on the iPhone.
> A redirect to pounce:// would load the Pounce app and pass in the URL
Thanks for the tip! I'll have to look at how custom schemes are used on iOS.
Francisco
___
--- On Wed, 1/5/11, Marius Scurtescu wrote:
> > This seems to be saying that the user's machine has a Web
> > server running on it which is reachable from the Internet by
> > sending an http request to the redirection URI. That's
> > unrealistic because the user's machine won't typically have
> >
metimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for
short. FYI, specification will be using JSON Web Tokens (JWTs).
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Franci
Torsten,
> Agreed. So what is then the benefit of the approach you
> proposed with respect to native apps?
Do you mean why didn't I just choose one of the approaches
in section 2.3 or the OAuth spec? Here is what the spec
says:
(now quoting from the spec)
> Native application clients can be i
Torsten,
> Another question: how does the server validate the
> identity/authenticity of the client? In other words, what
> does a malicious app prevent from using the URL and server
> of another native app?
Let me rephrase your question (correct me if I'm wrong): can
a malicious native app obtai
--- On Tue, 1/4/11, Torsten Lodderstedt wrote:
> the attack you described sounds very similar to session
> fixation attacks. TLS (more specifically server
> authentication) is one way to cope with spoofing in general
> (supposed the client has a reasonably CA policy). So it
> should do in this cas
--- On Tue, 1/4/11, Torsten Lodderstedt wrote:
> just to make sure I understood your paper correctly: even
> native clients are required to have a backend server
> component, which receives the authorization results and
> makes it available to the native client?
Yes, a very simple one that respon
--- On Tue, 1/4/11, Justin Richer wrote:
> > > We need a protocol that does both authentication and
> > > authorization. We can take OAuth and adapt it for
> > > authentication, or take OpenID and adapt it for
> > > authorization, or combine OpenID and OAuth (great
> > > solution
> > > for people
--- On Tue, 1/4/11, Marius Scurtescu wrote:
> > We need a protocol that does both authentication and
> > authorization. We can take OAuth and adapt it for
> > authentication, or take OpenID and adapt it for
> > authorization, or combine OpenID and OAuth (great solution
> > for people who love com
Torsten,
> you made a good point. However, the question is if this
> belongs into the OAuth scope since this a general attack on
> a web app's session management.
I gave two variants of the attack. I agree that the first
variant "looks like" an attack against session management,
but the second v
Hi all,
The OAuth spec recommends the use of TLS when sending
requests to the end-user authorization endpoint and requires
it when sending requests to the token endpoint. It says
nothing about using TLS when redirecting the browser back to
the client, which implies that it is not needed for that
--- On Wed, 12/29/10, Marius Scurtescu wrote:
...
> I don't think it adds much complexity. And for implementors it is a
> big help, much simpler to implement /.well-known/host-meta. Imagine
> asking a large website to add a few HTML tags to every single request
> to / as opposed to adding a specia
Hi Marius,
Thank you very much for your detailed reading of the paper
and your very useful comments. I've revised the paper based
on your comments and put a new version online, with an
acknowledgment of your contribution.
> PKAuth seems similar to OAuth 2, I think it would help if you used the s
Hi all,
OAuth provides only weak security when used with
unregistered applications. OTOH compulsory registration is
a bad idea: imagine a situation where a social site becomes
dominant, social login via that site becomes the de facto
authentication standard on the Web, every application has to
re
I forgot to acknowledge in my previous message that the work that let to the
proposal was supported by NSF grant IIP-1013594.
--- On Thu, 9/23/10, Francisco Corella wrote:
From: Francisco Corella
Subject: Not requiring client registration
To: oauth@ietf.org
Date: Thursday, September 23, 2010
56 matches
Mail list logo
