Skip to content

web-vulnerabilities-methodology.md

Latest commit

 

History

History
287 lines (206 loc) · 19 KB

web-vulnerabilities-methodology.md

File metadata and controls

287 lines (206 loc) · 19 KB
Raw

Web Vulnerabilities Methodology

{{#include ../banners/hacktricks-training.md}}

In every Web Pentest, there are several hidden and obvious places that might be vulnerable. This post is meant to be a checklist to confirm that you have searched for vulnerabilities in all the possible places.

Proxies

Tip

Nowadays web applications usually uses some kind of intermediary proxies, those may be (ab)used to exploit vulnerabilities. These vulnerabilities need a vulnerable proxy to be in place, but they usually also need some extra vulnerability in the backend.

User input

Tip

Most of the web applications will allow users to input some data that will be processed later.
Depending on the structure of the data the server is expecting some vulnerabilities may or may not apply.

Reflected Values

If the introduced data may somehow be reflected in the response, the page might be vulnerable to several issues.

Some of the mentioned vulnerabilities require special conditions, others just require the content to be reflected. You can find some interesting polygloths to test quickly the vulnerabilities in:

{{#ref}} pocs-and-polygloths-cheatsheet/ {{#endref}}

Modern client-side code execution pivots

When a reflection bug lands in a modern SPA, spend a few extra minutes on the browser-managed primitives and native bridges the page already owns:

  • Service workers: inspect the active registration path, effective scope, and any Service-Worker-Allowed broadening. A low-impact HTML injection or DOM clobbering bug can become origin-wide persistence if the page registers a worker or feeds attacker-controlled values into importScripts().
  • WASM / Emscripten modules: fuzz length, offset, and type conversions crossing the JS ↔ WASM boundary. In practice, a memory bug in linear memory may let you overwrite trusted HTML templates or state objects and upgrade a constrained client-side bug into DOM XSS.
  • Generated clients: minified bundles frequently disclose GraphQL persisted-query hashes, gRPC-Web method paths, postMessage handlers, WebSocket event names, and hidden admin routes even when the UI never exposes them.

For deeper exploitation ideas, check Abusing Service Workers, WebAssembly linear memory corruption to DOM XSS, and Code Review Tooling.

File System Access API: browser-native file read/write abuse

Chromium-family browsers expose showOpenFilePicker(), showSaveFilePicker(), and showDirectoryPicker() to trusted pages in a secure context and after a user gesture. If a target web app, phishing lure, or malicious dependency can convince the user to approve a directory with readwrite access, the page can operate on the selected files without dropping a native payload.

Practical abuse patterns:

  • Enumerate the selected directory with for await (const [name, handle] of dirHandle.entries()) or values(), recurse into subdirectories, and filter by extension/MIME.
  • Read file contents with handle.getFile() and text(), arrayBuffer(), or stream(), then exfiltrate through fetch, XHR, or sendBeacon.
  • Overwrite files with createWritable() after a queryPermission() / requestPermission({mode: 'readwrite'}) flow. This is the primitive that enables browser-native ransomware or destructive tampering.
  • Check IndexedDB for serialized FileSystemFileHandle / FileSystemDirectoryHandle objects because legitimate apps often persist handles and later reuse them after queryPermission() / requestPermission() checks.
  • Review the UX around picker prompts: fake AI upscalers, editors, and media tools can plausibly ask for an input file first and an output folder second, making the write warning look legitimate.

Important boundaries:

  • This is not arbitrary disk access. Chromium blocks or constrains many sensitive locations, but user-chosen media folders can still be high-value targets. In recent public research, Pictures, Videos, and Android DCIM roots were practical lure targets.
  • A normal web page still cannot become native malware: global keylogging, arbitrary desktop screenshots, and OS persistence remain outside the browser sandbox unless another vulnerability is present. The real primitive is user-approved local file read/write.
  • Browser support is concentrated in Chromium. Chrome shipped the API on desktop in Chrome 86 and extended it to Android/WebView in Chrome 132; Firefox and Safari do not expose the same picker methods.

Search functionalities

If the functionality may be used to search some kind of data inside the backend, maybe you can (ab)use it to search arbitrary data.

Forms, WebSockets and PostMsgs

When a websocket posts a message or a form allowing users to perform actions vulnerabilities may arise.

Cross-site WebSocket hijacking & localhost abuse

WebSocket upgrades automatically forward cookies and do not block ws://127.0.0.1, so any web origin can drive desktop IPC endpoints that skip Origin validation. When you spot a launcher exposing a JSON-RPC-like API through a local agent:

  • Observe emitted frames to clone the type/name/args tuples required by each method.
  • Bruteforce the listening port directly from the browser (Chromium will handle ~16k failed upgrades) until a loopback socket answers with the protocol banner—Firefox tends to crash quickly under the same load.
  • Chain a create → privileged action pair: e.g., invoke a create* method that returns a GUID and immediately call the corresponding *Launch* method with attacker-controlled payloads.

If you can pass arbitrary JVM flags (such as AdditionalJavaArguments), force an error with -XX:MaxMetaspaceSize=<tiny> and attach -XX:OnOutOfMemoryError="<cmd>" to run OS commands without touching application logic. See WebSocket attacks for a walk-through.

HTTP Headers

Depending on the HTTP headers given by the web server some vulnerabilities might be present.

Bypasses

There are several specific functionalities where some workarounds might be useful to bypass them

Structured objects / Specific functionalities

Some functionalities will require the data to be structured in a very specific format (like a language serialized object or XML). Therefore, it's easier to identify if the application might be vulnerable as it needs to be processing that kind of data.
Some specific functionalities may be also vulnerable if a specific format of the input is used (like Email Header Injections).

Files

Functionalities that allow uploading files might be vulnerable to several issues.
Functionalities that generate files including user input might execute unexpected code.
Users that open files uploaded by users or automatically generated including user input might be compromised.

External Identity Management

Passkeys / WebAuthn handoffs

Passkeys are origin-bound, so the usual bug is not "steal the secret" but abuse the workflow around the ceremony:

  • Try registration/login confusion: start a WebAuthn ceremony in one account or browser, then complete it from another session and check whether the signed challenge is still bound to the correct user, RP, and browser state.
  • Treat QR, device-code, wallet, and cross-device approvals exactly like password-reset tokens: check replay, stale approvals, session swapping, and whether a completed ceremony authenticates a browser different from the one that initiated it.
  • If you already have XSS or strong clickjacking on the relying-party origin, test whether you can drive extension/browser UI to approve a legitimate passkey login for the victim without exposing the credential material.

See Account Takeover and Clickjacking for concrete attack patterns.

Other Helpful Vulnerabilities

These vulnerabilities might help to exploit other vulnerabilities.

Web Servers & Middleware

Misconfigurations in the edge stack often unlock more impactful bugs in the application layer.

Application Frameworks & Stacks

Framework-specific primitives frequently expose gadgets, dangerous defaults, or framework-owned endpoints.

Tip

Always download the front-end bundles and *.map files before assuming a route or action is unreachable. Modern builds often leak Next.js Server Actions, GraphQL persisted-query hashes, tRPC router names, gRPC-Web paths, feature flags, and role strings that are perfect for low-privilege replay and authorization testing.

Quick grep targets inside downloaded bundles:

rg -n 'sourceMappingURL|createServerReference|Next-Action|queryHash|persistedQuery|grpc-web|protobuf|new WebSocket\(|postMessage\(' ./static ./dist ./_next ./assets 2>/dev/null

Useful follow-up reading: Code Review Tooling and Next.js.

CMS, SaaS & Managed Platforms

High-surface products often ship with known exploits, weak plugins, or privileged admin endpoints.

APIs, Buckets & Integrations

Server-side helpers and third-party integrations can expose file parsing or storage-layer weaknesses.

Supply Chain & Identifier Abuse

Attacks that target build pipelines or predictable identifiers can become the initial foothold before exploiting traditional bugs.

Web3, Extensions & Tooling

Modern applications extend into browsers, wallets, and automation pipelines—keep these vectors in scope.

References

{{#include ../banners/hacktricks-training.md}}