The Art of Account Take Over #1: Chaining XSS and non-HttpOnly Session Cookie

Welcome to my first article in “The Art of Account Takeover” series. Through this series, I’ll be sharing my journey and insights into various account compromise techniques that I’ve encountered during my security research. While many might think of account takeover as simple password bruteforce or credential stuffing, I’ve found that the most interesting cases often involve creative vulnerability chaining.

In this inaugural post, we’ll dive into one of my favorite techniques: combining Cross-Site Scripting with misconfigured session cookies. What makes this attack particularly interesting isn’t the individual vulnerabilities themselves — it’s how they interact. Through my testing experience, I’ve discovered that understanding these interactions often leads to the most impactful findings.

To understand our attack chain, imagine a house with two separate security issues: a window that doesn’t lock properly (the XSS vulnerability) and a key holder that’s visible through that window (the non-HttpOnly cookie). Either issue alone might not be critical — an unlocked window high up might be hard to reach, and a visible key holder isn’t a problem if all windows are secured. But together, they create a clear path for intrusion.

Our attack chain consists of three main components:
1. A web application that stores session information in cookies
2. The absence of the HttpOnly flag on these session cookies
3. A Cross-Site Scripting vulnerability anywhere in the application

These elements create a devastating chain reaction: the XSS vulnerability provides the entry point, the missing HttpOnly flag makes the session cookie accessible via JavaScript, and together they allow an attacker to steal active user sessions.

What is non-HttpOnly Cookie?

Session cookies serve as digital identification cards in web applications. When you log into a website, the server creates a unique session ID and sends it to your browser as a cookie. Your browser then presents this cookie with every subsequent request to prove your identity.

By default, cookies are accessible to JavaScript running on the webpage. Consider this typical cookie setting:

Without the HttpOnly flag, any JavaScript code can read this cookie using:

This becomes particularly dangerous when combined with JavaScript injection vulnerabilities. The HttpOnly flag was specifically designed to prevent this risk:

With this flag, attempting to access the cookie via JavaScript returns an empty string, creating a crucial security boundary that prevents session stealing even in the presence of XSS.

What is XSS

Cross-Site Scripting (XSS) represents a class of vulnerabilities where an attacker can inject malicious JavaScript code into a web page. This injected code executes in the context of the victim’s browser, with access to all the privileges of the legitimate website.

Consider a simple search function that displays results like this:

If userQuery contains JavaScript code instead of a normal search term

The application will unknowingly execute this malicious code in every visitor’s browser. This is particularly dangerous because the injected code runs with full access to the page’s resources, including any non-HttpOnly cookies.

For more advanced Tips and Trick for hunting XSS you can read my recent post : Effective XSS methodology : The true way to hunt XSS

This is visualization of the attack scenario to steal cookie of the victim :

This attack chain demonstrates several crucial lessons in web security:

1. Security controls must work together as a system. The HttpOnly flag exists specifically to prevent session stealing via XSS, but it must be properly implemented to be effective.

2. Input validation alone is not sufficient. A defense-in-depth approach, combining input validation, output encoding, and proper cookie configuration, provides much stronger security.

3. The impact of XSS vulnerabilities extends far beyond simple alert boxes. When combined with other security misconfigurations, XSS can lead to complete account compromise.

In our next article, we’ll explore another account takeover technique that demonstrating how seemingly separate security issues can combine to create critical vulnerabilities.

Be 1% Better Everyday, See ya !