Server-side Code Injection Attack

From Guidance Share
Jump to navigationJump to search

Description

The essence of HTTP Response Splitting is the attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response, in the normal case. The first response may be partially controlled by the attacker, but this is less important. What is material is that the attacker completely controls the form of the second response from the HTTP status line to the last byte of the HTTP response body. Once this is possible, the attacker realizes the attack by sending two requests through the target. The first one invokes two responses from the web server, and the second request would typically be to some "innocent" resource on the web server. However, the second request would be matched, by the target, to the second HTTP response, which is fully controlled by the attacker. The attacker, therefore, tricks the target into believing that a particular resource on the web server (designated by the second request) is the server's HTTP response (server content), while it is in fact some data, which is forged by the attacker through the web server - this is the second response. (http://www.webappsec.org/projects/threat/classes/http_response_splitting.shtml)


Vulnerabilities

  • HTTP Response headers populated with untrusted input


Countermeasures

  • Perform context-sensitive encoding of input before using it in in HTTP headers (e.g., IOSec)
  • Untrusted input should be validated against an inclusion list before use (e.g., RegEx pattern, primitive type casting, domain constraint, etc.)