Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Back in the day, websites were truly static, with only HTML and CSS being returned. Over time, responsive web design became a thing with AJAX/XHR requests being made in the background to get the information for the page. The Single Page Application (SPA) is extremely common to see now-a-days and that uses this pattern.

SPAs are snappy and react quickly. However, collecting data from the server takes time after all of the parsing things to be done. The frameworks for this are quite heavy as well. So, something new has gained popularity: HTML Over the Wire (FROW).

FROW is an architecture that attempts to combine to pre-rendering of HTML and the quickness of SPAs. It tries to render the HTML for the initial page on the backend but contains the ability to alter the page in an SPA-style fashion for dynamic portions. Hotwire Turbo, Unpoly, HTMLX and many other libraries take this approach.

Clicking links is kind of weird with this architecture. Should it reload the page like an old webpage or act like an SPA? Most of the libraries fire off a fetch() in the background then update the UI without reloading the page. This overwrites the default functionality of just making a GET request.

In order to support this, the FROW libraries add custom HTML attributes in order to allow for changing and editing of the fetch() request being made. For instance, you can change the method being used, the headers and more. The functionality is only intercepted from the browser if the origin of the path is the same as an internal meta tag.

To top this off, CSRF tokens are added into a header of the request automatically for most of these FROW apps. So, here's the idea: can we trick the application to send a user CSRF tokens on the request by poisoning the allowed domains?

On Turbo Drive, the turbo-root is can be set in a meta tag. According to the author, they've seen cases where it's possible for control this location as an attacker. Since the application thinks this is a trusted link, it will send the CSRF token alongside it.

On HTMX, the same thing can happen. If the link of the request can be set and the csrf token is supposed to be in the body, then it will blindly send it. Overall, an interesting post on the integration of technology causing weird issues. I'm not sure how exploitable this really is, since many things have to come together though.