>> (https://beefproject.com <https://beefproject.com/>) rather than >> exfiltrating tokens/proofs. > As a sidenote: BeEF is not really XSS but requires a full browser compromise. >
No, it’s not. The hook for BeEF is a single JS file, containing a wide variety of attack payloads that can be launched from the command and control center. You can combine BeEF with Metasploit to leverage an XSS to exploit browser vulnerabilities and break out. FYI, the name for the attack where the attacker proxies calls through the user’s browser is known as Session Riding. Just keep in mind that once an attacker has an XSS foothold, it is extremely hard to prevent abuse. The only barrier that cannot be broken (in a secure browser) is the Same Origin Policy. Keeping tokens and metadata in a separate environment (e.g., iframe, worker, …) is effective to keep them out of reach. However, once the app “extracts” data from such a context, the same problem arises. By rewriting JS functions, the attacker can extract tokens from deep within an SDK, as I discuss here: https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html <https://pragmaticwebsecurity.com/articles/oauthoidc/localstorage-xss.html> Kind regards Philippe > Thanks for the feedback! > > -Daniel > > > >> You can protect against exfiltration attacks by e.g. token binding the DPoP >> proofs and/or access token, or storing the access token in a HttpOnly cookie >> (gasp!). You can protect against exfiltrating post-dated DPoP proofs by >> storing the private key in a separate origin loaded in an iframe that you >> use postMessage to ask for proof tokens so the attacker is not in control of >> those claims. Nothing really protects against an attacker proxying requests >> through your browser, so this is purely post-compromise recovery rather than >> an actual defence against XSS. >> >> — Neil >> >>> On 4 May 2020, at 18:24, Daniel Fett <f...@danielfett.de >>> <mailto:f...@danielfett.de>> wrote: >>> >>> Hi all, >>> >>> as mentioned in the WG interim meeting, there are several ideas floating >>> around of what DPoP actually does. >>> >>> In an attempt to clarify this, if have unfolded the use cases that I see >>> and written them down in the form of attacks that DPoP defends against: >>> https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html >>> <https://danielfett.github.io/notes/oauth/DPoP%20Attacker%20Model.html> >>> Can you come up with other attacks? Are the attacks shown relevant? >>> >>> Cheers, >>> Daniel >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
