[ASM] : SQL-INJ "end-quote UNION" - How to allow this signature to specific url/uri/parameter only
Hi Team , can someone explain me the attack type - end-quote UNION and the solution to allow this signature to specific url/uri/parameter only. Attack Type : SQL-Injection Detected Keyword : ,\"Valore\":\"UNION-GLASS0x20S.R.L.\"},{\&quo Attack Signature : SQL-INJ "end-quote UNION" (Parameter) Context : Parameter (detected in Form Data) Parameter Level : Global Parameter Value : \"ArrayValori\":nullWAF Attack Signature Level
Hi, I have a specific URL defined in the ASM Allowed URLs ("/path01/page.aspx" for our example), which has "Check attack signatures" checked. In the Parameters we have only Wildcard with Ignore Value set. We found this melicious attempt request wasn't detected: /path01/page.aspx?a=%3Cscript%3Ealert%28%22XSS%22%29%3B%3C%2Fscript%3E&b=UNION+SELECT+ALL+FROM+information_schema+AND+%27+or+SLEEP%285%29+or+%27&c=..%2F..%2F..%2F..%2Fetc%2Fpasswd which decodes to this: /path01/page.aspx?a=<script>alert("XSS");</script>&b=UNION SELECT ALL FROM information_schema AND ' or SLEEP(5) or '&c=../../../../etc/passwd So I understand the melicious code is in the parameter context, so it's not checked due to the wildcard settings. But on the other hand, under the specific URL context, there are several "XSS (parameters)" signatures enabled. Doesn't that mean that under that specific URL it should check for XSS in parameters signatures? Thanks
Multiple ASM Attack Signature Sets Applied to a Policy
I have multiple attack signature sets applied to a policy. 1) When I look at the list of all the signatures applied to a specific policy, is there a way of telling which "attack signature set" an individual attack signature belongs to? 2) If an attack signature belongs to two signature sets which are applied to my policy, is it possible that a specific signature is in one state in attack signature set "A" and another state in attack signature set "B"? As an example if an attack signature is set to staging in set "A" and set to enforced in set "B", what happens? If that is possible, which setting takes precedence? 3) Is there an easy way to identify those attack signatures that are assigned to two or more signature sets within the policy? Is there a filter that can identify those?
Attack Signature Staging Audit / History
Hi Team, I have just started my attack signature journey being automatically pushed out via Big-IQ and loving the fact that I no longer have to deal with change windows etc! Currently my production system is just setup for auto updates and still require manually activation out of staging to be enabled. In my Nonprod environment, I have the same autoupdate of attack signatures for the last few months and have setup autostaging ( I think I have! ) by setting my staged time to 14 days. The question is, is there a log/history/event that I can view that shows when attack signatures move out of staging and where the heck do I find it ?
CM control of ASM attack signature updates - how to revert?
Env: LTM 11.5.2 I can't find any info on how to revert a whole ASM attack signature update file - only on how to disable specific signatures. Is there any configuration mgmt control that would let us "back out" a signatures update file? We are doing manual updates, and have HA pairs for all the LTMs affected - and I wondered if synching from the standby, which shouldn't yet have the update, to the standby would do it (i presume so). But ... we don't want to hold the pair in stasis for long enough to be sure there are no issues. I do understand about staging, and know that we have 7 days to identify and disable any specific signatures causing issues, btw. But if we're seeing a lot of false positives/negatives suddenly after an update, it would be helpful to be able to back out the whole update. Any way to do this? thx!ASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr
ASM Attack signatures on URL/parameter
Hi, I am trying to figure out violation logging when both URL and parameter is involved. Tested on 13.1.0.8 Request: Post to URL: /post1 Parameter in form (request body): parameter1 Policy in Transparent Parameters on URL level Encoded XSS string in parameter1 Depending on staging setting results are like that: URL staging: Disabled Parameter staging: Enabled Request reported in Event log: Status: Legal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected And second setting: URL staging: Enabled Parameter staging: Disabled Request reported in Event log: Status: Illegal Violation rating: 4 Violations detected: Illegal meta character in value, Attack signature detected Above suggest that violation detection is only performed on parameters. Still it is a bit misleading that for first staging setup violation is detected in exactly the same way as for second but request is reported as Legal. Now Attack signature settings changed (both URL and parameter with staging disabled) Check attack signatures on this URL: Disabled Check attack signatures on this parameter: Enabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value And second setting: Check attack signatures on this URL: Enabled Check attack signatures on this parameter: Disabled Request reported in Event log: Status: Illegal Violation detected: Illegal meta character in value From previous test it looked like only parameter signatures cause request to be reported as Illegal, but from above it seems that Attack signatures has to be checked on both URL and parameter to trigger Attack signature detected. Results are quite confusing here. I would expect results like that: No matter if staging is disabled both request should be listed as Illegal If only parameter Attack signatures are causing request to be Illegal then disabling Attack signatures on URL should still trigger Attack signatures violation. How Event Log entry for request with: Status: Legal Violation rating: 4 should be interpreted in compare to one where status is Illegal? Piotr
ASM Flagging JSON Payload Base 64 encoded data as a violation
Hello I have some policies that are accepting encrypted data which has then been encoded with Base64 and sent in a JSON document. However sometimes however this data gets rejected as an attack signature has been triggered. I would really like to leave Attack signature checking on the JSON profile but would like to find a way of filtering out just these signatures that get triggered without blocking legitimate traffic. Currently the URL is in Staging which is allowing them through but I should really enforce this at some point and at that time these violations will get blocked. Has anyone got any suggestions on how I could achieve this. I have been looking at iRules that would unblock a request if a certain criteria is met. James