On 8 Dec 2020, at 22:47, Brian Campbell
<bcampb...@pingidentity.com
<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
<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
<phili...@pragmaticwebsecurity.com
<mailto:phili...@pragmaticwebsecurity.com>> 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./
