Web Exploitation

Web challenges present a live web application with one or more vulnerabilities. Your goal is to find and exploit the vulnerability to read the flag, gain admin access, or achieve Remote Code Execution.

Websites all around the world are programmed using various programming languages. While there are language-specific vulnerabilities developers should know, many issues are fundamental to how web apps handle input, sessions, and trust boundaries.

These vulnerabilities often show up in CTFs as web security challenges where the player must exploit a bug to gain higher privileges or read sensitive data.

SQL Injection

SQL Injection is a vulnerability where an application takes user input and fails to validate it before putting it into an SQL query.

<?php
    $username = $_GET['username']; // kchung
    $result = mysql_query("SELECT * FROM users WHERE username='$username'");
?>

Under normal operation, the username parameter is expected to be a valid username like kchung.

A malicious user can submit special input. For example, if the input is a single quote:

SELECT * FROM users WHERE username='''

The query becomes invalid and the app often throws an error.

Now consider this payload: ' OR 1=1

SELECT * FROM users WHERE username='' OR 1=1

1=1 is always true, so this becomes:

SELECT * FROM users WHERE username='' OR true

This can return every row in the table.

Attackers also use comment and termination characters like --, /*, and ;.

SELECT * FROM users WHERE username=''-- '

Here, -- comments out the trailing quote, making the injected SQL valid.

Preventing SQL Injection

Use prepared statements so query structure and user data are handled separately.

<?php
    $stmt = $pdo->prepare('SELECT * FROM users WHERE username = :username');
    $stmt->execute(['username' => $username]);
?>

You can also use an ORM.

<?php
    $user = User::where('username', $username)->first();
?>

Command Injection

Command Injection happens when user input is passed to a system shell command without proper escaping/validation.

import os

domain = user_input()  # ctf101.org
os.system('ping ' + domain)

If attacker input is ; ls:

import os

domain = user_input()  # ; ls
os.system('ping ' + domain)

The shell sees:

ping ; ls

So ls runs in addition to ping. This is the core concept behind command injection.

Directory Traversal

Directory Traversal happens when user input is used in file paths without proper sanitization or sandboxing.

<?php
    $page = $_GET['page']; // index.php
    include('/var/www/html/' . $page);
?>

If attacker input is ../../../../../../../../etc/passwd:

<?php
    $page = $_GET['page']; // ../../../../../../../../etc/passwd
    include('/var/www/html/' . $page);
?>

The resolved include path becomes:

include('/var/www/html/../../../../../../../../etc/passwd');

Which normalizes to /etc/passwd on Linux systems.

Example leaked output:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Cross-Site Request Forgery (CSRF)

CSRF is an attack against an authenticated user. The attacker tricks the victim's browser into sending state-changing requests (transfer money, change email, etc.) using the victim's active session.

If a bank uses a GET endpoint like:

http://securibank.com/transfer.do?acct=[RECEPIENT]&amount=[DOLLARS]

An attacker might embed:

<img src="http://securibank.com/transfer.do?acct=[RECEPIENT]&amount=[DOLLARS]" width="0" height="0" border="0">

When the victim loads the page, the browser sends the request with existing cookies.

Cross-Site Scripting (XSS)

XSS is when one user can inject JavaScript that runs in another user's browser.

JavaScript can:

• Modify the DOM
• Send HTTP requests
• Access cookies

This enables cookie theft, phishing overlays, account takeover, and more.

XSS categories:

• Reflected XSS
• Stored XSS
• DOM XSS

Reflected XSS

Payload comes from the request (usually URL params):

https://ctf101.org?data=<script>alert(1)</script>

If vulnerable, server reflects it into HTML:

<html>
  <body>
    <script>alert(1)</script>
  </body>
</html>

Stored XSS

Payload is stored by the site (comments, profile bio, chat), then served to other users.

DOM XSS

The browser-side JavaScript injects unsafe data into the DOM, even if server-side filtering is okay.

Server-Side Request Forgery (SSRF)

SSRF is when an attacker can force the server to make requests to attacker-chosen destinations.

Example: a screenshot service meant to fetch external pages can be abused to fetch internal URLs like http://localhost.

Because requests come from the server's network position, attackers may reach internal resources they cannot access directly.

Server-Side Template Injection (SSTI)

SSTI happens when user input is interpreted by a template engine as code.

Basic probe:

{{8*8}}

If evaluated, the template engine returns 64, confirming code execution in template context.

Advanced payloads can escalate depending on engine and sandboxing.

Pages in This Section

Getting Started

SQL Injection

Cross-Site Scripting (XSS)

Server-Side Attacks

Authentication

Miscellaneous

Web CTF Methodology

SQL injection:      ' and 1=1--
XSS:                <script>alert(1)</script>
SSTI:               {{7*7}}
Command injection:  ; sleep 5
Path traversal:     ../../etc/passwd

Tools Quick Reference

Attack Flow Overview

Last updated on Aug 1, 2025