• Exploiting a "Useless" Cookie-Based XSS and Making it Useful

    If you would rather play a challenge than read a blog post, or play along as you go, you can find a re-implementation of the bug discussed in this post at https://www.xss.long.lat/.

    This is the writeup of the exploitation of a cookie-based XSS I found on a bug bounty program last summer which initially appeared to be:

    • unexploitable - the input for this XSS was in a cookie, and there is usually1 no way to set cookies for another user, meaning that there is usually no way to target another user with this issue; and
    • useless - even if I could find a way to target another user, the XSS affected a website that contained practically no interesting content and appeared as though it could even be abandoned2.
    1. depending on if you consider the presence XSS on another subdomain to be usual or not 

    2. in fact, this issue was resolved by the program removing the website 

    Read on →

  • Obtaining XSS Using Moodle Features and Minor Bugs

    Moodle allowed users to embed arbitrary HTML in their own dashboards, which are only visible to themselves, creating a situation which is equivalent to self-XSS. In this blog post I describe how it was possible to exploit this by setting a second session cookie with a restricted path, initially in combination with login CSRF, and then by using Moodle’s builtin impersonation functionality, to target other users. While much of the previous exploitation of self-XSS only allows the attacker to obtain read-only access to the DOM, this technique allows JavaScript to be run as the victim user, as with any regular XSS.

    Read on →