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?