Web Attacks

Directory map

• Introduction — web attack context, HTTP Verb Tampering, IDOR, XXE overview
• HTTP Verb Tampering — HTTP methods, insecure server config, insecure coding, auth bypass
• HTTP Verb Tampering — bypassing basic auth — identify restricted pages, OPTIONS enumeration, HEAD bypass
• HTTP Verb Tampering — bypassing security filters — method-scoped filters, switching methods, confirming command injection
• HTTP Verb Tampering — prevention — insecure config fixes (Apache, Tomcat, ASP.NET), insecure coding fixes
• Intro to IDOR — what it is, why common, impact (disclosure, modification, privilege escalation), attack pattern
• Identifying IDORs — URL params, AJAX calls, encoded/hashed references, comparing user roles
• IDOR mass enumeration — insecure parameters, static file IDOR, parameter-based IDOR, bulk download scripting
• Intro to XXE — XML structure, DTD, internal/external entities, the external entity file-read primitive
• IDOR — Bypassing Encoded References — MD5/Base64 schemes, function disclosure, reproducing hashes, mass enumeration script

Summary

Web attacks are the most common class of attacks against businesses, targeting external-facing applications, internal web apps, and API endpoints alike. This section covers three attack types found across many web applications. HTTP Verb Tampering exploits servers that accept unexpected HTTP methods, allowing attackers to bypass authorization mechanisms and security controls by sending requests with non-standard verbs. Insecure Direct Object References (IDOR) exploit weak or missing back-end access controls: when applications use predictable identifiers (sequential IDs, user numbers) to reference resources, an attacker can guess or calculate valid IDs to access other users’ data. XML External Entity (XXE) Injection targets applications using outdated XML parsers to process user-supplied XML — malicious payloads can read local files (configs, source code, credentials), enable whitebox testing, steal server credentials, and potentially achieve remote code execution.

HTTP Verb Tampering vulnerabilities stem from two sources. Insecure server configuration occurs when authentication rules are scoped to specific methods (e.g., <Limit GET POST>) leaving any other verb — such as HEAD — unauthenticated and freely accessible. Insecure coding occurs when input sanitization is applied to one HTTP method (e.g., $_GET) while the query uses a broader parameter source (e.g., $_REQUEST), allowing an attacker to switch to POST to bypass the filter entirely. The coding variant is more prevalent because it arises from common developer mistakes rather than misconfiguration.

Bypassing security filters is the more common variant: if a filter only inspects one method’s parameter source (e.g., $_POST), switching to a different method (e.g., GET) carries the payload through an unchecked channel while the underlying function (using $_REQUEST) still processes it. To confirm exploitation, use a two-file command injection payload (file1; touch file2;) — both files appearing proves command execution. A web app that appears fully filtered against injection may be completely exposed once the method is switched.

Bypassing basic authentication via verb tampering follows a short process: identify the restricted page/directory, intercept the request, try switching GET → POST (if also blocked, move on), send an OPTIONS request to enumerate accepted methods (curl -i -X OPTIONS http://TARGET/), then try HEAD. Because HEAD is accepted by default on most servers and is often excluded from <Limit> blocks, it bypasses the auth prompt while still executing the server-side action — the empty response body is expected behavior, not a failure. Verify success by checking application state rather than response content.

IDOR vulnerabilities arise when a web application exposes direct references to internal objects (file IDs, database records, API paths) without back-end access control validating that the requesting user is authorized. The reference itself is not the flaw — the missing authorization check is. Impact ranges from information disclosure (reading other users’ files/PII) to data modification/account takeover (write-capable references) to privilege escalation (calling admin-only API endpoints that the back-end fails to restrict to admin roles). IDOR is pervasive because access control is inherently hard to build, hard to automate testing for, and frequently skipped by developers who rely on front-end logic alone.

Identifying IDORs starts with spotting direct object references in URL parameters (?uid=1), API paths, cookies, or headers, then incrementing/fuzzing values to check for unauthorized access. Front-end JavaScript AJAX calls may reveal hidden endpoints and parameters (including admin functions disabled client-side but present in source). Encoded references (Base64) can be decoded, modified, and re-encoded; hashed references can often be reproduced by finding the algorithm in front-end source (e.g., CryptoJS.MD5(filename)) or identifying the hash type. Registering multiple accounts and comparing their HTTP requests reveals how identifiers are calculated and whether the back-end validates the caller’s session against the requested resource.

Mass enumeration automates IDOR exploitation at scale. Static file IDORs embed the user ID in predictable filenames (Invoice_1_09_2021.pdf); parameter-based IDORs pass the UID directly in a query string (?uid=1) — always check linked file URLs and page source since the UI may look identical across different UIDs. Extract document links with curl + regex (grep -oP "\/documents.*?.pdf"), then loop over UID ranges with a bash script using wget, or use Burp Intruder / ZAP Fuzzer for the same result.

Bypassing encoded references exploits the common mistake of performing hashing or encoding client-side. When a web application obscures object references using a scheme like MD5(Base64(uid)), the algorithm is visible to anyone who reads the front-end JavaScript source. Reproducing the scheme on the command line (echo -n 1 | base64 -w 0 | md5sum) confirms the algorithm, after which all object references become calculable and the protection is equivalent to none. A bash loop generates hashes for every target UID and curl -sOJ downloads the associated file in a single script. True security requires the hash to be computed server-side with a secret salt and a back-end authorization check — encoding or hashing alone is not access control.

XXE Injection targets web applications that parse user-supplied XML (SOAP APIs, web forms, file uploads) using XML parsers that allow external entity resolution. XML documents can define external entities via the SYSTEM keyword (<!ENTITY name SYSTEM "file:///etc/passwd">); when the server parses the document and substitutes entity references in its response, the contents of local files are returned to the attacker. The DTD mechanism (<!DOCTYPE>) is what makes this possible — it allows entities to be defined inline before the parser processes the document body. Understanding the core XML primitives (elements, attributes, entities, DTD declarations) is prerequisite to constructing XXE payloads.