"Ok I guess we doin' shells now:" Creating a Secure Web Server from Two Vulnerable Web Servers

Consensus-based defense

The speaker proposes building a secure web front end from two different vulnerable servers using Shell HTTP Response Factory logic: instead of detecting exploits after compromise, compare normalized HTTP responses from both backends on each request. If at least one stack is secure for a given flaw, mismatched output blocks the attack.

Normalization challenges

Responses must be made comparable by stripping or harmonizing server headers, cookies, JavaScript dictionary ordering, and similar differences before equality checks. The proxy needs no exploit-specific signatures or historical baseline—only live agreement between peers.

Historical examples

Code Red's IIS buffer overflow would diverge from a Linux peer. Heartbleed-style memory leaks would not match a properly responding sibling. A CrowdStrike-like host failure can trigger failover to cold spares while preserving consensus guarantees. XZ Utils' liblzma backdoor affected many Linux tools but not Windows lz32.dll, so heterogeneous pairs reduce supply-chain single-point risk.

Use cases

The approach suits legacy binaries, mixed-platform stacks, and deliberate risk diversification when one component is known vulnerable.