Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Jim Manico]

The basic theme from the web attacker community is:

1) XSS is a game over event to web clients. XSS can steal or abuse 
(request forgery) tokens, and more.


2) Even if you prevent stolen tokens from being used outside of a web 
client, XSS still allows the attacker to force a user to make any 
request in a fraudulent way, abusing browser based tokens as a form of 
request forgery.


3) There are advanced measures to stop a token from being stolen from a 
web client, like a HTTPonly cookies and to a lesser degree, JS Closures 
and Webworkers.


4) However, these measures to protect cookies are mostly moot. Attackers 
can just force clients to make fraudulent requests.


5) Many recommend the BFF pattern to hide tokens on the back end, but 
still, request forgery via XSS allows all kinds of abuse.


XSS is game over no matter how you slice it.

Crypto solutions do not help. Perhaps the world of OAuth can start 
suggesting that web clients use CSP 3.0 in specific ways, if you still 
plan to support Implicit type flows or tokens in browsers?


Respectfully,

- Jim


On 12/9/20 12:57 PM, Brian Campbell wrote:
Thanks Philippe, I very much concur with your line of reasoning and 
the important considerations. The scenario I was thinking of is: 
browser based client where XSS is used to exfiltrate the refresh token 
along with pre-computed proofs that would allow for the RT to be 
exchanged for new access tokens and also pre-computed proofs that 
would work with those access tokens for resource access. With the 
pre-computed proofs that would allow prolonged (as long as the RT is 
valid) access to protected resources even when the victim is offline. 
Is that a concrete attack scenario? I mean, kind of. It's pretty 
convoluted/complex. And while an access token hash would reign it in 
somewhat (ATs obtained from the stolen RT wouldn't be usable) it's 
hard to say if the cost is worth the benefit.




On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck 
> wrote:


Yeah, browser-based apps are pure fun, aren’t they? :)

The reason I covered a couple of (pessimistic) XSS scenarios is
that the discussion started with an assumption that the attacker
already successfully exploited an XSS vulnerability. I pointed out
how, at that point, finetuning DPoP proof contents will have
little to no effect to stop an attack. I believe it is important
to make this very clear, to avoid people turning to DPoP as a
security mechanism for browser-based applications.


Specifically to your question on including the hash in the proof,
I think these considerations are important:

1. Does the inclusion of the AT hash stop a concrete attack scenario?
2. Is the “cost” (implementation, getting it right, …) worth the
benefits?


Here’s my view on these considerations (*/specifically for
browser-based apps, not for other types of applications/*):

1. The proof precomputation attack is already quite complex, and
short access token lifetimes already reduce the window of attack.
If the attacker can steal a future AT, they could also precompute
new proofs then.
2. For browser-based apps, it seems that doing this complicates
the implementation, without adding much benefit. Of course,
libraries could handle this, which significantly reduces the cost.


Note that these comments are specifically to complicating the spec
and implementation. DPoP’s capabilities of using
sender-constrained access tokens are still useful to counter
various other scenarios (e.g., middleboxes or APIs abusing access
tokens). If other applications would significantly benefit from
having the hash in the proof, I’m all for it.

On a final note, I would be happy to help clear up the details on
web-based threats and defenses if necessary.

—
*Pragmatic Web Security*
/Security for developers/
https://pragmaticwebsecurity.com/ 



On 8 Dec 2020, at 22:47, Brian Campbell
mailto:bcampb...@pingidentity.com>>
wrote:

Danial recently added some text to the working copy of the draft
with https://github.com/danielfett/draft-dpop/commit/f4b42058
 that I
think aims to better convey the "nutshell: XSS = Game over"
sentiment and maybe dissuade folks from looking to DPoP as a
cure-all for browser based applications. Admittedly a lot of the
initial impetus behind producing the draft in the first place was
born out of discussions around browser based apps. But it's
neither specific to browser based apps nor a panacea for them. I
hope the language in the document and how it's recently been
presented is reflective of that reality.

The more specific discussions/recommendations around in-browser
apps are valuable (if somewhat over my head) but might be more

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Brian Campbell]

Thanks Philippe, I very much concur with your line of reasoning and the
important considerations. The scenario I was thinking of is: browser based
client where XSS is used to exfiltrate the refresh token along with
pre-computed proofs that would allow for the RT to be exchanged for new
access tokens and also pre-computed proofs that would work with those
access tokens for resource access. With the pre-computed proofs that would
allow prolonged (as long as the RT is valid) access to protected resources
even when the victim is offline. Is that a concrete attack scenario? I
mean, kind of. It's pretty convoluted/complex. And while an access token
hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't
be usable) it's hard to say if the cost is worth the benefit.



On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> Yeah, browser-based apps are pure fun, aren’t they? :)
>
> The reason I covered a couple of (pessimistic) XSS scenarios is that the
> discussion started with an assumption that the attacker already
> successfully exploited an XSS vulnerability. I pointed out how, at that
> point, finetuning DPoP proof contents will have little to no effect to stop
> an attack. I believe it is important to make this very clear, to avoid
> people turning to DPoP as a security mechanism for browser-based
> applications.
>
>
> Specifically to your question on including the hash in the proof, I think
> these considerations are important:
>
> 1. Does the inclusion of the AT hash stop a concrete attack scenario?
> 2. Is the “cost” (implementation, getting it right, …) worth the benefits?
>
>
> Here’s my view on these considerations (*specifically for browser-based
> apps, not for other types of applications*):
>
> 1. The proof precomputation attack is already quite complex, and short
> access token lifetimes already reduce the window of attack. If the attacker
> can steal a future AT, they could also precompute new proofs then.
> 2. For browser-based apps, it seems that doing this complicates the
> implementation, without adding much benefit. Of course, libraries could
> handle this, which significantly reduces the cost.
>
>
> Note that these comments are specifically to complicating the spec and
> implementation. DPoP’s capabilities of using sender-constrained access
> tokens are still useful to counter various other scenarios (e.g.,
> middleboxes or APIs abusing access tokens). If other applications would
> significantly benefit from having the hash in the proof, I’m all for it.
>
> On a final note, I would be happy to help clear up the details on
> web-based threats and defenses if necessary.
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com/
>
>
> On 8 Dec 2020, at 22:47, Brian Campbell 
> wrote:
>
> Danial recently added some text to the working copy of the draft with
> https://github.com/danielfett/draft-dpop/commit/f4b42058 that I think
> aims to better convey the "nutshell: XSS = Game over" sentiment and maybe
> dissuade folks from looking to DPoP as a cure-all for browser based
> applications. Admittedly a lot of the initial impetus behind producing the
> draft in the first place was born out of discussions around browser based
> apps. But it's neither specific to browser based apps nor a panacea for
> them. I hope the language in the document and how it's recently been
> presented is reflective of that reality.
>
> The more specific discussions/recommendations around in-browser apps are
> valuable (if somewhat over my head) but might be more appropriate in the OAuth
> 2.0 for Browser-Based Apps
> 
> draft.
>
> With respect to the contents of the DPoP draft, I am still keen to try and
> flush out some consensus around the question posed in the start of this
> thread, which is effectively whether or not to include a hash of the access
> token in the proof.  Acknowledging that "XSS = Game over" does sort of
> evoke a tendency to not even bother with such incremental protections (what
> I've tried to humorously coin as "XSS Nihilism" with no success). And as
> such, I do think that leaving it how it is (no AT hash in the proof) is not
> unreasonable. But, as Filip previously articulated, including the AT hash
> in the proof would prevent potentially prolonged access to protected
> resources even when the victim is offline. And that seems maybe worthwhile
> to have in the protocol, given that it's not a huge change to the spec. But
> it's a trade-off either way and I'm personally on the fence about it.
>
> Including an RT hash in the proof seems more niche. Best I can tell, it
> would guard against prolonged offline access to protected resources when
> access tokens are bearer and the RT was DPoP-bound and also gets rotated.
> The trade-off there seems less worth it (I think an RT hash would be more
> awkward in the protocol too).
>
>
>
>
>

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

[Kevin Gaynor]

Whaybdo I keep getting these messages and how did you hack my email

Get Outlook for iOS

From: OAuth  on behalf of Warren Parad 

Sent: Wednesday, December 9, 2020 8:34:53 AM
To: Karsten Meyer zu Selhausen 
Cc: oauth 
Subject: Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in 
Authorization Response

Since there is a potentially valid TLS case, let's shelve the non-TLS case 
without the precondition. I agree a MITM attack on the authorization code is a 
legitimate case which would be mitigated by resolving the ISS parameter to 
determine the valid token endpoint. I would suggest to improve the language in 
the Introduction to specifically indicate this as a solution to the 
authorization code interception. (It wasn't clear to me before this 
conversation that it helped solved that problem)

So +1

On Wed, Dec 9, 2020, 11:40 Karsten Meyer zu Selhausen 
mailto:karsten.meyerzuselhau...@hackmanit.de>>
 wrote:

The attacker being able to manipulate the first request is an additional 
precondition for the mix-up attack variant we used as an example. The 
precondition is based on the attacker A2 defined in section 
3 of 
the security BCP.

There are other mix-up variants which work without this precondition. One 
variant is described in the security 
BCP,
 for example:

*Mix-Up Without Interception*: A variant of the above attack works
  even if the first request/response pair cannot be intercepted, for
  example, because TLS is used to protect these messages: Here, it
  is assumed that the user wants to start the grant using A-AS (and
  not H-AS, see Attacker A1).  After the client redirected the user
  to the authorization endpoint at A-AS, the attacker immediately
  redirects the user to H-AS (changing the client ID to "7ZGZldHQ").
  Note that a vigilant user might at this point detect that she
  intended to use A-AS instead of H-AS.


On 09.12.2020 10:47, Warren Parad wrote:
Okay, it wasn't clear that the user agent was required to be compromised for 
this to be a problem. Here's where it breaks down for me, if the attacker can 
manipulate the first request, why would they not be able to manipulate the AS 
where the Auth Response code is sent?  Unless we can guarantee there is an 
attack surface that would only affect the authorization request AS selection 
and not the auth response, the solution the draft lacks purpose for me.


[https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]

Warren Parad

Founder, CTO

Secure your user data and complete your authorization architecture. Implement 
Authress.


On Wed, Dec 9, 2020 at 8:55 AM Karsten Meyer zu Selhausen 
mailto:karsten.meyerzuselhau...@hackmanit.de>>
 wrote:

Hi Warren,

I think there is some misunderstanding on how mix-up attacks work. I will try 
to clear things up.

Have a look at the following mix-up attack example (slide 
4
 from the interim meeting):

[X]

I marked the important parts:

  *   In step 1 the client stores the attacker's AS (A-AS) as the selected AS.
  *   Step 5: The authorization response is issued by the honest (= not 
compromised) AS, not by the attacker's AS. The H-AS will use its own correct 
issuer identifier as the value for the AS parameter.
 *   In a mix-up attack the attacker cannot directly influence the value of 
the iss parameter in the authorization response as it is issued by the H-AS.
  *   Step 6: The client sends the token request to the token endpoint of the 
A-AS, because it stored the A-AS as the selected AS in step 1. This leaks the 
authorization code to the attacker who can use it in a code injection attack, 
for example.

With an iss parameter present in step 5 the client would be able to recognize 
that the code was issued by the H-AS, not by the A-AS. The client would be able 
to abort the authorization grant instead of leaking the code to the A-AS.

I hope this addresses your concerns.

Best regards,
Karsten

On 08.12.2020 20:15, Warren Parad wrote:
As an implementer on both sides of the issue I'm struggling to understand how 
this problem would occur. I'm finding issues with the proposed problems:

  1.  Honest AS is compromised, assuming this does happen details on why adding 
iss to the AS response would prevent attacks is necessary for me. In other 
words, how would an AS be compromised in a way that would be identifiable 
through the issuer value? (my ignorant assumption is that a compromised AS is 
compromised enough that an attacker would be able to 

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Vladimir Dzhuvinov]

Do we have deployments in the field and client-side developers giving
feedback / comments about the current DPoP, implementing it, and perhaps
those concerns about the access token?

Vladimir

On 08/12/2020 23:47, Brian Campbell wrote:
> Danial recently added some text to the working copy of the draft with
> https://github.com/danielfett/draft-dpop/commit/f4b42058 that I think
> aims to better convey the "nutshell: XSS = Game over" sentiment and
> maybe dissuade folks from looking to DPoP as a cure-all for browser
> based applications. Admittedly a lot of the initial impetus behind
> producing the draft in the first place was born out of discussions
> around browser based apps. But it's neither specific to browser based
> apps nor a panacea for them. I hope the language in the document and
> how it's recently been presented is reflective of that reality.
>
> The more specific discussions/recommendations around in-browser apps
> are valuable (if somewhat over my head) but might be more appropriate
> in the OAuth 2.0 for Browser-Based Apps
> 
> draft.
>
> With respect to the contents of the DPoP draft, I am still keen to try
> and flush out some consensus around the question posed in the start of
> this thread, which is effectively whether or not to include a hash of
> the access token in the proof.  Acknowledging that "XSS = Game over"
> does sort of evoke a tendency to not even bother with such incremental
> protections (what I've tried to humorously coin as "XSS Nihilism" with
> no success). And as such, I do think that leaving it how it is (no AT
> hash in the proof) is not unreasonable. But, as Filip previously
> articulated, including the AT hash in the proof would prevent
> potentially prolonged access to protected resources even when the
> victim is offline. And that seems maybe worthwhile to have in the
> protocol, given that it's not a huge change to the spec. But it's a
> trade-off either way and I'm personally on the fence about it.
>
> Including an RT hash in the proof seems more niche. Best I can tell,
> it would guard against prolonged offline access to protected resources
> when access tokens are bearer and the RT was DPoP-bound and also gets
> rotated. The trade-off there seems less worth it (I think an RT hash
> would be more awkward in the protocol too).
>
>
>
>
>
>
>
> On Fri, Dec 4, 2020 at 5:40 AM Philippe De Ryck
>  > wrote:
>
>
>> The suggestion to use a web worker to ensure that proofs cannot
>> be pre-computed is a good one I think. (You could also use a
>> sandboxed iframe for a separate sub/sibling-domain -
>> dpop.example.com ).
>
> An iframe with a different origin would also work (not really
> sandboxing, as that implies the use of the sandbox attribute to
> enforce behavioral restrictions). The downside of an iframe is the
> need to host additional HTML, vs a script file for the worker, but
> the effect is indeed the same.
>
>> For scenario 4, I think this only works if the attacker can
>> trick/spoof the AS into using their redirect_uri? Otherwise the
>> AC will go to the legitimate app which will reject it due to
>> mismatched state/PKCE. Or are you thinking of XSS on the
>> redirect_uri itself? I think probably a good practice is that the
>> target of a redirect_uri should be a very minimal and locked down
>> page to avoid this kind of possibility. (Again, using a separate
>> sub-domain to handle tokens and DPoP seems like a good idea).
>
> My original thought was to use a silent flow with Web Messaging.
> The scenario would go as follows:
>
> 1. Setup a Web Messaging listener to receive the incoming code
> 2. Create a hidden iframe with the DOM APIs
> 3. Create an authorization request such as
> 
> “//authorize?response_type=code_id=..._uri=https%3A%2F%example.com
> 
> =..._challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk_challenge_method=S256=none_mode=web_message/”
> 4. Load this URL in the iframe, and wait for the result
> 5. Retrieve code in the listener, and use PKCE (+ DPoP if needed)
> to exchange it for tokens
>
> This puts the attacker in full control over every aspect of the
> flow, so no need to manipulate any of the parameters.
>
>
> After your comment, I also believe an attacker can run the same
> scenario without the “/response_mode=web_message/”. This would go
> as follows:
>
> 1. Create a hidden iframe with the DOM APIs
> 2. Setup polling to read the URL (this will be possible for
> same-origin pages, not for cross-origin pages)
> 3. Create an authorization request such as
> 
> “//authorize?response_type=code_id=..._uri=https%3A%2F%example.com
> 
>