ASM Policy Blocking

Hi Mike,

 

 

I agree that there isn't a perfect default set of checks to perform for any app. Here are some thoughts though on a baseline:

 

 

I'd skip:

 

 

Mandatory HTTP header is missing - only useful if the application requires a particular HTTP header but doesn't check to see that it's present. I've never seen such a requirement in an enterprise level app.

 

Failed to convert character - Not generally an issue in typical ISO-8859-1 / UTF8 web apps.

 

 

I'd add:

 

 

Illegal HTTP status in response - block 5xx responses from getting back to the client (and for cosmetic reasons, if the app does not have a custom 404 page, block 404s as well)

 

Illegal meta character in parameter name - consider blocking < or > (xss and other scripting attacks), ' (SQL injection), % (percent/URL encoding), &; (at least one of these three characters to prevent use in combination for unicode encoding),

 

Illegal meta character in header - see above

 

Illegal meta character in parameter value - see above

 

 

The metacharacter checks are the ones that take the longest to tune. But once you do, you end up with a very secure policy. The policy builder can help automate this process.

 

 

Aaron

Hoolio,

 

 

This is outside the scope of this thread, but where would I find information or documentation on "skipping" ASM evaluation of traffic where a "failed to convert character" error exists?

 

 

I am currently having an issue where I get a "failure to convert Character" message in the buffer or for a parameter.

 

 

Hi Festus,

 

 

I'm not sure that's possible. Can you start a new thread and provide more detail on what the issue is? ie, do you know what in the request is triggering the 'failed to convert character' violation? Is that check in blocking mode? Do you need it to be in blocking?

 

 

Thanks, Aaron

Aaron,

 

Thanks for the reply, I was actually planning on adding the Illegal HTTP Status in Response, I appreciate the advice on the adds and skips. From a parameter perspective one thing I did not mention is we some framework level checking that locks down parameter names, values, and lengths so are talking about handling all the parameter checks in those configurations. That is something else that is still up for debate. If we don't handle those checks in the framework we will be doing them on the ASM.

 

I'd be leery of depending solely on application side validation. It's great if the application does validation, particularly in the framework. But there is always a chance of misconfiguration or errant use of the framework within the application. If the app owners swear up and down they're doing proper validation, I'd still do a pen test to check it before disabling those checks in ASM.

 

 

Aaron

Yes I actually completely agree with you, I would prefer to keep it in my hands and do it as the ASM, unfortunately as I am sure you know Security is not always the people that get to make decisions about Security :). If we do hand it off, we do plan on testing the controls a few times a year and repercussions if we find anyone violating the standard. Not perfect I know but nothing ever is.

 

 

Mike