What's changed: Initial version
1.4Attack techniques (1): authentication and web applications
Covers password cracking (dictionary attacks, brute force, reverse brute force, rainbow tables, password-list attacks) and the representative web-application attacks XSS (reflected/stored/DOM-based), CSRF, clickjacking, SQL injection, OS command injection, directory traversal, and man-in-the-middle (MITM)/MITB, building the judgment to determine which attack a given vulnerability symptom enables and which countermeasure is effective.
For a security engineer conducting web-application assessments, identifying the attack technique from a vulnerability's "symptom" and prioritizing countermeasures is central to daily work. Even the same symptom—"unexpected behavior triggered by input"—calls for a completely different fix depending on whether the cause is injection into a SQL statement or into an OS command. This section covers attacks on authentication and web applications following the flow symptom -> attack technique -> countermeasure.
1.4.1Password cracking
- A dictionary attack tries dictionary words or commonly leaked password candidates in sequence. A brute-force attack tries every possible character combination, and it becomes harder to succeed as the password grows longer and more complex.
- A reverse brute-force attack fixes a single password and tries many user IDs against it in turn. It characteristically slips past ordinary account lockout, which locks a single ID after a set number of failed attempts.
- A rainbow table attack precomputes a table mapping password hashes to their plaintexts, then rapidly reverse-looks-up a stolen hash to its plaintext. Using a salt (adding a random value before hashing) defeats this, since it invalidates reuse of a precomputed table.
- A password-list (credential-stuffing) attack reuses ID/password pairs leaked from one service and tries them as-is against another service. Users who reuse passwords across services are the targets, so multi-factor authentication and awareness against reuse are the core countermeasures.
Do not confuse the reversed subject/object relationship: "brute force = try every password candidate against one ID," "reverse brute force = try one password against every ID." The pairing "rainbow-table countermeasure = salting," "password-list countermeasure = MFA and preventing reuse" is also most-tested.
1.4.2Web application attacks (XSS, CSRF, clickjacking)
- XSS (cross-site scripting) exploits inadequate input validation or output escaping in a web app to run a malicious script in another user's browser. Reflected XSS is immediate: a URL parameter or similar is echoed directly into the response. Stored XSS is persistent: the script is saved (e.g., in a bulletin-board post) and affects every visitor. DOM-based XSS occurs purely through client-side JavaScript processing, without the server being involved.
- CSRF (cross-site request forgery) tricks a logged-in user into submitting an unintended request (a fund transfer, a post, etc.) via another site. The core countermeasure is verifying request legitimacy with a token. Distinguish the difference in target: XSS is an attack that gets a script executed, whereas CSRF is an attack that gets an unintended request sent.
- Clickjacking overlays an invisible, legitimate site's button or similar element on top of decoy-site content, tricking the user into clicking it without realizing. The countermeasure is restricting iframe embedding from other sites via headers such as
X-Frame-Options.
1.4.3Injection attacks and man-in-the-middle attacks
- SQL injection exploits inadequate input validation to make an application execute an unintended SQL statement, directly enabling unauthorized viewing, tampering, or deletion of database contents. The core countermeasure is binding values via placeholders (prepared statements); escaping special characters alone can be insufficient.
- OS command injection exploits a vulnerability where input is executed as part of an OS shell command. Structurally similar to SQL injection, but it differs in that the target is the OS itself, not a database, and the damage can extend to complete takeover of the server.
- Directory traversal abuses relative-path notation such as
../to gain unauthorized access to files under directories that were never intended to be exposed (configuration files, password files, etc.). The countermeasure is normalizing the input path and validating that access outside the permitted scope is rejected. - A man-in-the-middle (MITM) attack has an attacker interpose between two communicating parties to eavesdrop on or tamper with the communication. MITB (man-in-the-browser) goes further, hijacking the user's own browser via malware and eavesdropping on or tampering with content after decryption, making it harder to detect than MITM.
Suppose a web-application security assessor at an EC site finds that entering ' OR '1'='1 into a search form causes every product to be displayed. This symptom indicates that the input is being incorporated directly into a SQL statement and interpreted as syntax, diagnosable as SQL injection. Because simple escaping of special characters alone risks missing cases, the assessor proposes, at the highest priority, fixing it via binding values with placeholders (prepared statements). In parallel, suppose the same site's bulletin-board feature is found to store a post containing a <script> tag as-is, which then executes in every visitor's browser. Since the symptom is persistent—stored on the server and affecting every visitor—this is diagnosed as stored XSS, and adding HTML escaping on output is proposed. Further, suppose it is found that merely visiting a decoy site while logged in causes an unintended fund-transfer request to be sent to the legitimate site. Since the symptom is not script execution but the request itself being sent without the user's intent, this is diagnosed as CSRF, and embedding and verifying a token in the request is proposed. If this were misdiagnosed as XSS and addressed with HTML escaping alone, CSRF's root cause (lack of request-legitimacy verification) would remain unresolved, and the fix would miss the mark. Accurately discerning the nature of the symptom—is a script being executed, is an unintended request being sent, or is a SQL statement being rewritten—is the starting point for choosing an effective countermeasure.
| Observed symptom | Diagnosed attack | Effective countermeasure |
|---|---|---|
| Input to a search form rewrites the SQL statement | SQL injection | Placeholders (prepared statements) |
| A bulletin-board post executes in every visitor's browser | Stored XSS | HTML escaping on output |
| Merely visiting a decoy site sends an unintended request | CSRF | Embedding and verifying a token in the request |
Trap: "The symptom where merely visiting a decoy site while logged in sends an unintended fund-transfer request is XSS" is wrong—it is CSRF, since it is not script execution but the request itself being sent without the user's intent. Also wrong: "escaping special characters alone is sufficient for SQL injection countermeasures"—since the risk of missed escaping remains, binding values via placeholders (prepared statements) is the more reliable countermeasure.
1.4.4Section summary
- Distinguish brute force (all passwords against one ID) from reverse brute force (one password against all IDs). The countermeasure for rainbow tables is salting
- Distinguish XSS (gets a script executed) from CSRF (gets an unintended request sent) by their difference in target
- The countermeasure for SQL injection is placeholders; OS command injection targets the OS itself; MITB is more severe than MITM in that it eavesdrops on content even after decryption
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. It is found that entering `' OR '1'='1` into a web app's search form displays every product, including ones that should not be shown. Which pairing of diagnosis and top-priority countermeasure is most appropriate for this symptom?
Q2. It is confirmed that a logged-in user, merely by visiting a decoy site, has an unintended fund-transfer request sent to the legitimate site. No execution of a malicious script is observed. Which diagnosis is most appropriate for this symptom?
Q3. A service wants to defend against an attack that rapidly recovers plaintext from a stolen password hash using a precomputed table mapping hashes to plaintexts. Which countermeasure is most effective?

