6.2Key protocols and network applications

Many network application protocols were designed in the 1980s-90s under a "good faith" assumption, so the standard behavior of the protocol itself carries an inherent attack surface. DNS recursive queries can be fertile ground for cache poisoning, and cookie-based session management can be a target for session hijacking. This section builds the judgment to understand each protocol's mechanics and then determine where the attack surface lies and how to design to reduce the risk.

6.2.1HTTP and HTTPS

• HTTP is the Web's application-layer protocol, and being plaintext itself, it is defenseless against eavesdropping and tampering (a man-in-the-middle attack). HTTPS is HTTP encrypted with TLS, providing confidentiality (preventing eavesdropping), integrity (detecting tampering), and server authentication (confirming connection to the legitimate server).
• Even with HTTPS deployed, an implementation that skips certificate validation, or a configuration that still permits old TLS versions (SSLv3, TLS 1.0, etc.), leaves a residual man-in-the-middle risk. A design decision to permit only recommended cipher suites and protocol versions, in line with the SSL/TLS cryptographic configuration guidelines, is required.

6.2.2DNS (name resolution, recursive queries, caching)

• DNS is the name resolution mechanism mapping domain names to IP addresses. There is a recursive query, where a caching DNS server receiving a client's query walks through authoritative DNS servers in turn to resolve it, and an iterative query, where authoritative DNS servers each answer only within what they know.
• While caching the resolution result reduces the load of repeated queries, it also exposes the server to DNS cache poisoning, which injects a forged response into the cache. Countermeasures include randomizing the query ID and source port, and—the fundamental fix—deploying DNSSEC, which verifies the legitimacy of a response via digital signatures.
• SPF, DKIM, and DMARC, used for sender domain authentication in email, also rely on DNS TXT records, so the robustness of the DNS infrastructure itself (cache-poisoning countermeasures, restricting zone transfers) is a precondition for the reliability of this authentication.

6.2.3Mail protocols and proxies

• SMTP is the mail-sending protocol. Unauthenticated SMTP is fertile ground for abuse as a mail relay (third-party relay) or sender-domain spoofing, so it is countered with SMTP-AUTH (user authentication at send time) or OP25B (ISPs block direct sends to port 25 and route them via the submission port 587). POP3 and IMAP are mail-retrieval protocols; IMAP manages mail on the server and suits multi-device use.
• A forward proxy sits on the client side, making requests to the outside on the client's behalf. It is used for applying client-side security policy, such as URL filtering and access logging. A reverse proxy sits on the server side, receiving requests from outside and distributing them to servers behind it. It is used to consolidate WAF functionality, hide the real server's IP address, and load-balance.

6.2.4REST, cookies, and session IDs

• REST is a design principle that manipulates resources via HTTP methods (GET/POST/PUT/DELETE, etc.) and URLs. HTTP is inherently stateless (each request is independent), so maintaining a session such as login state requires a separate mechanism.
• Having the cookie hold a server-issued session ID lets subsequent requests automatically send the session ID to maintain login state. If the session ID is stolen, session hijacking (impersonating the legitimate user) becomes possible, so besides being a sufficiently long, hard-to-guess random value, the design must set the cookie's Secure attribute (send only over HTTPS), HttpOnly attribute (block JavaScript access, preventing theft via XSS), and SameSite attribute (a CSRF countermeasure).

Consider a system designer conducting a security review of a new service that includes login and email-notification features. First, for session management, the design has the server issue a session ID after login and store it in a cookie—but the review reveals that neither the Secure nor HttpOnly cookie attribute is set. In this state, a single XSS vulnerability anywhere on the site lets an attacker steal the session ID via document.cookie, enabling session hijacking. The fix is to add HttpOnly (block JavaScript reads) and Secure (send only over HTTPS, preventing eavesdropping in transit), and also set SameSite=Strict or Lax as a CSRF countermeasure. Next, for DNS design, the review finds the internal caching DNS server operates with a fixed query ID, creating a risk that DNS cache poisoning could resolve the service's domain to a forged IP address—so the reviewer recommends randomizing the query ID and source port, and adopting DNSSEC on the authoritative side if possible. Finally, for the email-notification feature, mail was being sent externally without SMTP authentication, risking abuse as a third-party relay, so SMTP-AUTH is made mandatory, and sender-domain authentication (SPF/DKIM/DMARC) is configured in DNS to raise the rejection rate of spoofed mail. Understanding each protocol's "standard behavior" and then closing off where that behavior creates an attack surface, one item at a time, is the practical work of a security review.

6.2.5Section summary

• DNS cache-poisoning countermeasures: randomize query ID/source port plus DNSSEC (authenticity only, not encryption)
• A cookie holding a session ID must set the Secure, HttpOnly, and SameSite attributes to prevent eavesdropping, XSS-based theft, and CSRF
• Forward proxies apply client-side policy; reverse proxies are used for server-side IP concealment, load balancing, and WAF consolidation