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

[Vladimir Dzhuvinov <[e-mail]>]

Thank you Justin for this honest account of your experience with DPoP.

To at_hash or not is maybe not solved yet, but at least it's clear
there's little enthusiasm about the OIDC style at_hash :)

Vladimir

On 15/12/2020 18:40, Justin Richer wrote:
> I went and implemented this proposal of including a token hash in both
> an AS (java) and client (javascript) on a system that was already
> using DPoP and OpenID Connect. What I did there was just use the
> existing code we had on the AS-side to calculate the “at_hash” in the
> ID Token from OIDC, which I also used to verify on the token-accepting
> portions. I had to implement the function on the client side, but that
> was only a couple lines using a crypto library to do the heavy hash lift.
>
> The most annoying part is dealing with the hash variability in the
> OIDC method. As Brian points out, this isn’t particularly robust, and
> it depends on the wrapper being JOSE. That’s not a huge deal because
> DPoP uses JOSE for its wrapper, but it’s still extra code to deal with
> — to the point where I just hardcoded the hash algorithm in my test so
> that I didn’t have to put together the switch case over the algorithm. 
>
> So in at least my own experience, the addition is minimal on both
> client and server, and whatever we would decide for the hash algorithm
> would be simple enough to manage. I have a slight preference for just
> picking something like SHA256 and calling it a day (and defining other
> hashes in the future when SHA256 is broken), but that’s not a hill I
> care to die on.
>
>  — Justin
>
>> On Dec 14, 2020, at 4:27 PM, Brian Campbell
>> <bcampbell=[e-mail]
>> <mailto:bcampbell=[e-mail]>> wrote:
>>
>>
>>
>> On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     If the current DPoP has code complexity "X", the relative
>>     additional complexity to include access token hashes doesn't seem
>>     like very much. An app choosing DPoP means accepting the code
>>     complexity that comes with dealing with keys, composing the
>>     signing inputs for the proofs, signing, the necessary changes to
>>     the token and RS requests. On the other hand, for some people
>>     that additional access token hash may become the straw that
>>     breaks the camel's back, causing them to quit their jobs
>>     developing web apps and never look back :)
>>
>> Yeah, the relative additional complexity to include an access token
>> hash maybe isn't too much but it's also not not nothing. It's a
>> different kind of operation than the other things you listed (yes, I
>> know there's a hash as part of the signing but it's abstracted away
>> from the developer in most cases) and something that can be quite
>> difficult to troubleshoot when different parties arrive at different
>> hash values. Hence my lack of conviction on this one way or the other. 
>>  
>>
>>
>>     Have you thought about letting deployments decide about the
>>     access token hash? To say look, there is also the option to bind
>>     an access token to the DPoP proof, the security benefits can be
>>     such an such, and this is how it can be done.
>>
>>     What I don't like about that proposal: 
>>
>>       * It will complicate the spec
>>
>>       * The current spec doesn't require implementers / deployments
>>         to make any decisions, apart from adopt / not DPoP (okay,
>>         also choose a JWS alg) - which is actually a great feature to
>>         have
>>
>>
>> I also don't like it for basically the same reasons. I've definitely
>> aimed to keep it simple from that perspective of not having a lot of
>> optionality or switches. It is a nice feature to have, when possible. 
>>
>>  
>>
>>     Vladimir
>>
>>
>>     On 12/12/2020 01:58, Brian Campbell wrote:
>>>     Any type of client could use DPoP and (presumably) benefit from
>>>     sender-constrained access tokens. So yeah, adding complexity
>>>     specifically for browser-based applications (that only mitigates
>>>     one variation of the attacks possible with XSS anyway)  has
>>>     'cost' impact to those clients as well. And should be considered
>>>     in the cost/benefit. Including the AT hash isn't terribly
>>>     complicated but it's not trivial either. I'm honestly still
>>>     unsure but am leaning towards it not being worth adding. 
>>>
>>>     On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck
>>>     <[e-mail]
>>>     <mailto:[e-mail]>> wrote:
>>>
>>>         The scenario you describe here is realistic in browser-based
>>>         apps with XSS vulnerabilities, but it is pretty complex.
>>>         Since there are worse problems when XSS happens, it’s hard
>>>         to say whether DPoP should mitigate this. 
>>>
>>>         I’m wondering what other types of clients would benefit from
>>>         using DPoP for access tokens? Mobile apps? Clients using a
>>>         Client Credentials grant?
>>>
>>>         How are they impacted by any change made specifically for
>>>         browser-based applications?
>>>
>>>         Philippe
>>>
>>>
>>>>         On 9 Dec 2020, at 23:57, Brian Campbell
>>>>         <[e-mail]
>>>>         <mailto:[e-mail]>> 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
>>>>         <[e-mail]
>>>>         <mailto:[e-mail]>> 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
>>>>>             <[e-mail]
>>>>>             <mailto:[e-mail]>> 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
>>>>>             <https://datatracker.ietf.org/doc/draft-ietf-oauth-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
>>>>>             <[e-mail]
>>>>>             <mailto:[e-mail]>> 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
>>>>>>                 <http://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&client_id=...&redirect_uri=https%3A%2F%example.com
>>>>>                 <http://example.com/>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256&prompt=none&response_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&client_id=...&redirect_uri=https%3A%2F%example.com
>>>>>                 <http://example.com/>&state=...&code_challenge=7-ffnU1EzHtMfxOAdlkp_WixnAM_z9tMh3JxgjazXAk&code_challenge_method=S256/”
>>>>>                 4. Load this URL in the iframe, and keep polling
>>>>>                 5. Detect the redirect back to the application
>>>>>                 with the code in the URL, retrieve code, and use
>>>>>                 PKCE (+ DPoP if needed) to exchange it for tokens
>>>>>
>>>>>                 In step 5, the application is likely to also try
>>>>>                 to exchange the code. This will fail due to a
>>>>>                 mismatching PKCE verifier. While noisy, I don’t
>>>>>                 think it affects the scenario. 
>>>>>
>>>>>
>>>>>>                 IMO, the online attack scenario (i.e., proxying
>>>>>>                 malicious requests through the victim’s browser)
>>>>>>                 is quite appealing to an attacker, despite the
>>>>>>                 apparent inconvenience:
>>>>>>
>>>>>>                  - the victim’s browser may be inside a corporate
>>>>>>                 firewall or VPN, allowing the attacker to
>>>>>>                 effectively bypass these restrictions
>>>>>>                  - the attacker’s traffic is mixed in with the
>>>>>>                 user’s own requests, making them harder to
>>>>>>                 distinguish or to block
>>>>>>
>>>>>>                 Overall, DPoP can only protect against XSS to the
>>>>>>                 same level as HttpOnly cookies. This is not
>>>>>>                 nothing, but it means it only prevents relatively
>>>>>>                 naive attacks. Given the association of public
>>>>>>                 key signatures with strong authentication, people
>>>>>>                 may have overinflated expectations if DPoP is
>>>>>>                 pitched as an XSS defence.
>>>>>
>>>>>                 Yes, in the cookie world this is known as “Session
>>>>>                 Riding”. Having the worker for token isolation
>>>>>                 would make it possible to enforce a coarse-grained
>>>>>                 policy on outgoing requests to prevent total abuse
>>>>>                 of the AT.
>>>>>
>>>>>                 My main concern here is the effort of doing DPoP
>>>>>                 in a browser versus the limited gains. It may also
>>>>>                 give a false sense of security. 
>>>>>
>>>>>
>>>>>
>>>>>                 With all this said, I believe that the AS can lock
>>>>>                 down its configuration to reduce these attack
>>>>>                 vectors. A few initial ideas:
>>>>>
>>>>>                 1. Disable silent flows for SPAs using RT rotation
>>>>>                 2. Use the sec-fetch headers to detect and reject
>>>>>                 non-silent iframe-based flows
>>>>>
>>>>>                 For example,  an OAuth 2.0 flow in an iframe in
>>>>>                 Brave/Chrome carries these headers:
>>>>>                 /
>>>>>                 sec-fetch-dest: iframe
>>>>>                 sec-fetch-mode: navigate
>>>>>                 sec-fetch-site: cross-site
>>>>>                 sec-fetch-user: ?1
>>>>>                 /
>>>>>
>>>>>
>>>>>                 Philippe
>>>>>
>>>>>
>>>>>             /CONFIDENTIALITY NOTICE: This email may contain
>>>>>             confidential and privileged material for the sole use
>>>>>             of the intended recipient(s). Any review, use,
>>>>>             distribution or disclosure by others is strictly
>>>>>             prohibited.  If you have received this communication
>>>>>             in error, please notify the sender immediately by
>>>>>             e-mail and delete the message and any file attachments
>>>>>             from your computer. Thank you./
>>>>
>>>>
>>>>         /CONFIDENTIALITY NOTICE: This email may contain
>>>>         confidential and privileged material for the sole use of
>>>>         the intended recipient(s). Any review, use, distribution or
>>>>         disclosure by others is strictly prohibited.  If you have
>>>>         received this communication in error, please notify the
>>>>         sender immediately by e-mail and delete the message and any
>>>>         file attachments from your computer. Thank you./
>>>
>>>
>>>
>>>
>>>
>>>     /CONFIDENTIALITY NOTICE: This email may contain confidential and
>>>     privileged material for the sole use of the intended
>>>     recipient(s). Any review, use, distribution or disclosure by
>>>     others is strictly prohibited.  If you have received this
>>>     communication in error, please notify the sender immediately by
>>>     e-mail and delete the message and any file attachments from your
>>>     computer. Thank you./ 
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     -- 
>>     Vladimir Dzhuvinov
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> /CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s).
>> Any review, use, distribution or disclosure by others is strictly
>> prohibited.  If you have received this communication in error, please
>> notify the sender immediately by e-mail and delete the message and
>> any file attachments from your computer. Thank
>> you./_______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth