injection, and how to force caching. This (and more) is discussed in

[1], under the  practical consideration  sections.

Solution

Validate input. Remove CRs and LFs (and all other hazardous

characters) before embedding data into any HTTP response headers,

particularly when setting cookies and redirecting. It is possible to use

third party products to defend against CR/LF injection, and to test for

existence of such security holes before application deployment.

Further recommendations are:

   Make sure you use the most up to date application engine

Make sure that your application is accessed through a unique

IP address (i.e. that the same IP address is not used for another

application, as it is with virtual hosting).

References

[1] "Divide and Conquer   HTTP Response Splitting, Web Cache

Poisoning Attacks, and Related Topics" by Amit Klein,

http://www.sanctuminc.com/pdf/whitepaper_httpresponse.pdf

[2]  CRLF Injection  by Ulf Harnhammar (BugTraq posting),

http://www.securityfocus.com/archive/1/271515

1.2  Web Server/Application Fingerprinting

Web server/application fingerprinting is similar to its predecessor,

TCP/IP Fingerprinting (with today's favorite scanner   Nmap) except

that it is focused on the Application Layer of the OSI model instead of

the Transport Layer.  The theory behind web server/application

fingerprinting is to create an accurate profile of the target's software,

configurations and possibly even their network architecture/topology

by analyzing the following:

69

Copyright 2004, Web Application Security Consortium. All rights reserved.