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

[Jim Manico <[e-mail]>]

Brian,

I just focus on web security and understand the risk of XSS well. It 
seems to me that many of the designers of OAuth 2 do not have a web 
security background and keep trying to address XSS with add-ons without 
success.

- Jim

On 12/11/20 2:01 PM, Brian Campbell wrote:
> I think that puts Jim in the XSS Nihilism camp :)
>
> Implicit type flows are being deprecated/discouraged. But keeping 
> tokens out of browsers doesn't seem likely. There is some menton of 
> CSP in 
> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7 
> <https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-9.7> 
>
>
> On Wed, Dec 9, 2020 at 4:10 PM Jim Manico <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>>     <[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/
>>         <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
>>>         <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./
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth  <https://www.ietf.org/mailman/listinfo/oauth>
>
>     -- 
>     Jim Manico
>     Manicode Security
>     https://www.manicode.com  <https://www.manicode.com>
>
>
> /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./ 

-- 
Jim Manico
Manicode Security
https://www.manicode.com