Forum Discussion

Dave_Pisarek_25's avatar
Dave_Pisarek_25
Icon for Nimbostratus rankNimbostratus
Nov 02, 2017

SQL Injection signature set on policy - odd behavior

I have noticed an odd behavior for a policy I created in 12.1.2 ASM. The policy was created manually through the deployment wizard with the following settings

 

utf-8 no template selected, no case sensativity, no https/wss - http/wss, no addition attack signature sets selected, staging disabled, no response checking, parameters, urls and file types set to never (wildcard only)

 

This policy is then updated to remove the generic signature set and add SQL Injection signature set. We only want to check and mitigate sql injection type requests.

 

The policy is then set to blocking with all violation disabled (no learn, alarm or block checked) except for the sql injection signature set which is set to alarm and block only. Again only checking for sql injection type attacks.

 

When a test request is sent like so - or 1=1 union select a couple SQl signatures are triggered but no response page is presented. Instead the ASM treats the request as a referer and all jpgs, js and other image files are then blocked. The page displayed is just text:

 

 

 

 

If I use a manually created policy with all default settings and no change any settings, the index.php page is blocked and no additional resources like jpgs, js etc are blocked. The response page is displayed. I then edit the same policy and make it so only SQL Injection is enabled and the behavior of being a referer happens again.

 

You should easily be able to recreate. Any idea why the policy acts in this manner when configured as such?

 

8 Replies

  • Hi,

     

    I'm not sure, Are you enable ASM response page under blocking setting?

     

  • Yes the default response page is enabled. Please try and recreate this situation as it will help you try and help research this issue.

     

  • Hi,

     

    You mention to "select a couple SQl signatures are triggered but no response page is presented". Please check more thing:

     

    • Related SQL attack signature already enable flag "Alarm" and "Block".
    • Are you already apply the policy?
    • Current status of policy is "Transparent" or "Blocking".
    • Go to the event log that relate with you attack request. Please recheck, What is violation that trigger in the event log?
  • It looks to me like the primary request is not detected and blocked.

     

    The page renders HTML, but all subsequent linked requests for CSS and Images include the referrer - which does trigger the signatures and is blocked.

     

    Turn on logging for all requests - you should see what is happening with the first request.

     

  • Nut,

     

    All signatures are set to yes for Alarm and Block Policy is applied to VS Blocking Multiple SQL Union (Parameter) signatures are triggered.

     

    S,

     

    Good call with the all requests. I set the policy to log all requests and saw the index.php log with attack signatures showing in staging??

     

     

    Staging is disabled on this policy and when I look at the specific signatures they are not in staging:

     

     

    If I look at where the GET in a referer the signatures are not in staging. Of course these are the (Header) type signature versus (Parameter) but why would one be in staging versus the other?

     

     

    Again all that is enabled is the SQL Injection Signature set and none of them show in staging. Policy building is manual.

     

  • Check the signature settings for the wildcard parameter. There may be some implied staging setting there for non-specified parameters. Then create a specific parameter and test again.

     

  • This is now resolved. Thanks S as the staging was still on the wildcard and when disabled the issue went away. This explains the difference in the parameter sig and the header sig..