Web Exploitation

Intro

This is a guide on how to solve web exploitation challenges in CTFs.

I’m writing this because I’m on a flight to Hangzhou with nothing else to do. OSINT challenge: can you find what flight I’m on?

Web application vulnerabilities can be categorized into some of these categories:

• Injection (SQLi, XXE, XPATH injection, command injection etc…)
• Cross Site Scripting (XSS)
• PHP Vulnerabilities
• Session Abuse
• Server Side Template Injection (SSTI)
• Server Side Request Forgery (SSRF)

You can learn to exploit these vulnerabilities here. Instead of explaining these vulnerabilities, I’ll dive into my thought process when approaching web exploitation challenges.

The vulnerabilities in web exploitation challenges are generally easy to understand. What’s usually difficult is piecing together the logical flaws in programs such that you can exploit these vulnerabilities.

Unusual Practices

Source code is usually provided in challenges. Read through the source code and understand what the application does.

You might spot code / algorithms that seem redundant, or that you yourself would write differently.

For example, this Javascript code copies properties from one object to another.

static merge(target, source) {
    for (let key in source) {
        if (source[key] && typeof source[key] === 'object') {
            target[key] = target[key] || {};
            this.merge(target[key], source[key]);
        } else {
            target[key] = source[key];
        }
    }
    return target;
}

This is an “unusual practice” as there are definitely easier methods to copy properties from one object to another, for instance by using the spread operator: target = {...target, ...source}. So why use such a complicated process to copy properties over?

The suspicious code is actually vulnerable to prototype pollution. Using an unorthodox way to copy properties to another object actually introduces a prototype pollution vulnerability which we can go ahead and exploit.

LLMs

Throw the source code into your favorite LLM and ask if there are any vulnerabilities that it can spot.

This is a quick and easy way to solve most easy web exploitation challenges.

While it’s unreasonable to expect LLMs to be able to solve harder challenges for you, they can point out unusual practices in the code which can give you more ideas for how to exploit the application.

Using Your Brain

I feel like a large part of solving web exploitation challenges is simply using your brain to understand what the code does wrongly. Contrary to other categories like reverse engineering or pwn, where you actually need extensive knowledge of the subject to find vulnerabilities and implement exploits, web exploitation just requires a lot of thinking.

That’s not to say that you don’t need to have knowledge of the different vulnerabilities out there and how to exploit them. However, a lot of this stuff can be learned on the spot when solving. All it takes is thinking out of the box, and a willingness to try.

Practicing is the best way to learn web exploitation. Jump into practice websites like PicoCTF or Dreamhack.io and get accustomed to the different types of challenges. Play weekend CTFs on CTFtime to gain more competition experience. You will learn way more from this than from, for example, listening to an hour-long lecture on SQL injection.

When in doubt, just use your brain harder. Or prompt your LLM harder.