9.4.5 upgrade and HTTP Protocol Compliance

A client can legitimately send a POST request with a Content-Length header value of 0. This is not against any HTTP RFC. ASM can block this as an added validation "feature". Internet Explorer seems to do this while Firefox does not. From a quick search it looks like IE might send POST requests with a Content-Length of 0 for NTLM authentication and some corner cases.

 

 

I think the reason ASM can be configured to block this is that it could be used for HTTP response splitting attacks. You can find more info on this category of attacks online:

 

 

http://www.owasp.org/images/1/1a/OWASPAppSecEU2006_HTTPMessageSplittingSmugglingEtc.ppt

 

 

Aaron

Great informative response - thanks!

 

 

Just a quick follow up question if I may.

 

 

Would you know if the ASM attack signatures would detect splitting attacks as Wikipedia indicates the associated application vulnerability can be used for XSS attacks?

I wouldn't want to say definitively yes or no, but I expect ASM should prevent these types of attacks using charset restrictions. If the attack depends on carriage return line feed characters in the URI or headers, these should be blocked by default character sets. The attack signatures might provide additional protection, but the charsets are what I'd count on for this scenario.

 

 

If you want a definitive answer, you (or a pen tester) could try a few of the response splitting attacks with ASM in transparent mode. See if you can exploit the app and then check the ASM forensics to see if the attacks were marked as illegal.

 

 

If you have the means to do it, it's always ideal to have the app pen tested through ASM before putting a new app and policy in production.

 

 

Aaron

I've checked out our character set settings.

 

 

Whilst we have the carriage return and line feed characters disallowed at a global level we have a wildcard parameter of * which has both of them set as allowed, plus also a couple of other parameters such as a comments field, which has them allowed.

 

 

For information, the * wildcard had to be put in due to the number of dynamic parameters that are created by our web application.

 

 

Don't know if you can answer this or not but if we were to turn off the HTTP protocol compliance feature in order to rely on the character set restrictions (and the attack signatures) is the * wildcard parameter opening us up to HTTP Response Split attacks?

 

I think the main concern for HTTP response splitting is if the application uses any user-supplied content in response headers. It would be ideal if you could disable the CR and LF characters for all four global character sets and only allow it where required for specific parameters. If that's not an option, you could leave CR and LF enabled for the global parameter. But then you're potentially opening yourself up to an attack if the application is vulnerable.

 

 

Either way, if you have legitimate client requests where they set the Content-Length to 0, you would need to disable that check.

 

 

Aaron

Cheers for that.

 

 

Looks like a question for our application developers then !