HTB CWEE key terms

Manually requesting URLs, files, or API routes that are not linked in the interface, to find hidden endpoints, backups, or admin panels left accessible by the server.

Systematically enumerating paths, parameters, and virtual hosts using wordlists and response analysis (status code, size, timing) to map an application's real attack surface beyond visible links.

Sending requests with different Host header values against one IP address to discover additional applications served by the same web server or reverse proxy.

Identifying frameworks, server software, and library versions from headers, cookies, error pages, and static asset paths so that known vulnerabilities and default behaviors can be targeted.

A flaw where the server fails to verify that the authenticated user is permitted to perform an action or read a record, letting attackers act outside their intended privileges.

Insecure Direct Object Reference: an endpoint accepts a user-supplied identifier for a record and returns it without checking ownership, exposing other users' data.

Gaining access to resources belonging to another user of the same privilege level, typically by swapping identifiers or session tokens rather than elevating role.

Binding request parameters directly onto internal objects, so an attacker can set fields the developer never intended to expose, such as role or isAdmin.

An attack where the attacker forces a known session identifier on the victim and, because the server does not rotate the ID at login, reuses it to hijack the authenticated session.

Stealing or predicting a valid session token, then replaying it to impersonate the victim without knowing their credentials.

Flags such as HttpOnly, Secure, and SameSite that restrict script access, require TLS transport, and limit cross-site sending of cookies, reducing theft and CSRF exposure.

Injecting a crafted SELECT that appends attacker-chosen columns to the original query, so results from other tables are returned in the application's own response.

Injection where no query output is reflected, so the attacker infers data by asking true/false questions through response differences or deliberate time delays.

Malicious input is stored safely at first but later concatenated into a query by a different function, so the payload executes when the stored value is reused.

Supplying query operators such as $ne or $regex in place of a scalar value, so the document database evaluates attacker-controlled logic and may bypass authentication or leak records.

Breaking out of a value passed to a shell so that additional commands run with the web server's privileges, often via metacharacters like semicolons, pipes, or backticks.

Controlling a command-line argument rather than the shell itself, for example injecting flags into a program invoked by the application, without needing shell metacharacters.

User input is rendered as part of a server-side template, so template syntax is evaluated and can often be escalated to reading files or executing code.

Inserting LDAP filter metacharacters into a search filter so the query matches unintended entries, potentially bypassing login checks or enumerating directory objects.

Injecting into an XPath expression used to query XML data, altering the predicate so authentication logic returns a node it should not.

Script supplied by an attacker is persisted by the application and later rendered unescaped to other users, executing in their browser context.

Client-side JavaScript copies attacker-controlled data from a source such as location.hash into a dangerous sink like innerHTML, executing without any server-side reflection.

A response header restricting which script sources, inline code, and connections the browser will allow, limiting the impact of injected script when configured strictly.

Cross-Site Request Forgery: a third-party page causes the victim's browser to submit an authenticated state-changing request, exploiting cookies sent automatically with the request.

Merging attacker-controlled keys such as proto into a JavaScript object modifies the shared prototype, changing behavior of every object and sometimes leading to code execution.

Injecting HTML with id or name attributes so global variables or element references in page script resolve to attacker-controlled nodes, altering logic without executing script.

Server-Side Request Forgery: the attacker makes the server issue a request to a URL they choose, reaching internal services, metadata endpoints, or localhost-only interfaces.

An internal link-local address such as 169.254.169.254 that returns instance credentials or configuration; reachable through SSRF when no egress restrictions exist.

Supplying sequences like ../ in a filename or path parameter so the resolved path escapes the intended directory and reads or writes files elsewhere.

A parameter controlling which file the server includes or renders, allowing traversal to other files and, when combined with upload or log poisoning, code execution.

Accepting uploaded files without validating type, content, or storage location, so an executable script can be placed in a web-reachable path and requested.

The application rebuilds objects from untrusted serialized data, letting an attacker control object state and trigger gadget chains that execute code or alter logic.

Methods such as __wakeup, __destruct, and __toString that PHP calls implicitly during object lifecycle, providing the entry points exploited in deserialization gadget chains.

Abusing a server that trusts the token header's alg field, for example switching to HS256 and signing with the public key, or accepting none, to forge valid tokens.

Embedding an attacker-generated key in a token's jwk header so a misconfigured verifier uses that key to validate the signature the attacker just produced.

Checking issuer, audience, expiry, and key identifier claims server-side; skipping these lets tokens from other contexts or expired tokens be replayed.

Manipulating the redirect_uri parameter, via path tricks or open redirects, so an authorization code is delivered to an attacker-controlled destination.

Querying the schema for types, fields, and mutations; often left enabled in production, it reveals the full API surface for targeted abuse.

Sending many operations in one request to bypass rate limits, enabling high-speed brute force of credentials, tokens, or one-time codes.

A malicious page opens a WebSocket to the target using the victim's cookies, since the handshake is not covered by the same-origin policy, then reads messages.

A parameter that sends the browser to any supplied URL, useful for phishing and for leaking OAuth codes or tokens to attacker infrastructure.

After the first foothold, reusing harvested credentials, tokens, or trust relationships to reach additional hosts and services inside the network.

Routing further attack traffic through a compromised host so internal-only services become reachable from the tester's machine.

Establishing a durable foothold, such as a scheduled task, web shell, or added account, that survives restarts and credential changes.

A minimal, reproducible demonstration of one vulnerability with the exact requests and observed output, sufficient for a developer to confirm and fix it.

Specific, actionable fixes tied to the root cause, such as parameterized queries or server-side authorization checks, plus verification steps the team can run.

Scoring findings by exploitability and business impact, using a consistent method such as CVSS plus contextual factors, to prioritize what gets fixed first.

A short, non-technical opening section stating overall posture, the most serious themes, and recommended priorities for leadership who will not read the technical detail.