Forum Discussion

Mike_Maher's avatar
Mike_Maher
Icon for Nimbostratus rankNimbostratus
Feb 17, 2011

ASM Policy Blocking

So I am currently trying to determine what is best blocked at the ASM and what to allow to pass to the application security layer. So I realize that some of the blocks at ASM are subjective to what type of application you are protecting and what technologies are deployed within the application. Obviously I would not need turn on any XML checks if there is no XML in the application. So I guess what I am looking for is does anyone have any opinion on what checks should we enable no matter what. My thought were the following and wanted to see if anyone had anything to add or a process they use to handle this. By the way I am running 10.2.

 

 

All the RFC-Violations

 

CSRF Attack Detected

 

Illegal File Type

 

Illegal Method

 

Illegal URL

 

Illegal Meta-Character in the URL

 

Failed to convert character

 

Web Scraping Detected

 

ASM Cookie Hijacking

 

Modified ASM Cookie

 

Attack Signature Detected

 

  • 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