views:

158

answers:

5

Hi, im trying to handle this possible exploit and wondering what is the best way to do it? should i use apache's common-validator and create a list of known allowed symbols and use that?

+1  A: 

From the wikipedia article:

The generic solution is to URL-encode strings before inclusion into HTTP headers such as Location or Set-Cookie.

Typical examples of sanitization include casting to integer, or aggressive regular expression replacement. It is worth noting that although this is not a PHP specific problem, the PHP interpreter contains protection against this attack since version 4.4.2 and 5.1.2.

Edit

im tied into using jsp's with java actions!

There don't appear to be any JSP-based protections for this attack vector - many descriptions on the web assume asp or php, but this link describes a fairly platform-neutral way to approach the problem (jsp used as an incidental example in it).

Basically your first step is to indentify the potentially hazardous characters (CRs, LFs, etc) and then to remove them. I'm afraid this about as robust a solution as you can hope for!

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.

ConroyP
A: 

Use PHP? ;)

According to Wikipedia and the PHP CHANGELOG, PHP's had protection against it in PHP4 since 4.4.2 and PHP5 since 5.1.2.


Only skimmed it -- but, this might help. His examples are written in JSP.

Jonathan Lonowski
A: 

ok, well casting to an int is not much use when reading strings, also using regex in every action which recieves input from browser could be messy, im looking for a more robust solution

combi001
A: 

im tied into using jsp's with java actions!

combi001
A: 

that's fair enough thanks

combi001