On 4 May 2020, at 21:44, Daniel Fett <[email protected]> wrote:
>
> Am 04.05.20 um 21:27 schrieb Philippe De Ryck:
>>
>>>> (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.
> I shall stand corrected!
>>
>> 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.
> Compartmentalization within an origin is as old a problem as it is mostly
> unsolved, indeed. That is why I would not further differentiate in case the
> browser is online and the client's script is compromised, but instead assume
> that the attacker can then forge arbitrary requests using the token.
>
I agree on that assumption. The moment malicious script executes, it’s game
over, regardless of the specifics on whether a token can be extracted or not.
Even with isolation, an attacker would be able to trick the isolated context in
making requests as a confused deputy.
Philippe
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
