`evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})`
Our client told us that all of the sudden they could not update a specific piece of data that had a certain word in it (it's a Japanese address, in Kanji). We checked through the load balancer logs and we found that this waf rule: owasp-crs-v030301-id942100-sqli was the one that was called from our network security policy.
We then set the policy waf rules to:
`evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1, 'opt_out_rule_ids': ['owasp-crs-v030301-id942100-sqli']})`
And it passed without any issue. We made sure that the change was reflected by also changing our priority level on this particular policy, and the log confirmed that by showing us the new priority level on all passing POST/GET requests.
The description for 942100-sqli is: SQL Injection Attack Detected via libinjection.
I was curious, why did it first let it pass and successfully insert the data but then caught it as a SQL injection when our client tried to update it? (there was about a month in time difference between inserting and trying to update).
I can assume that maybe GCP updated somethings on their end, influencing the sqli rule, but another weird part of it is that it works all the time on our staging cloud run. It has the same settings as our prod (including the initial sqli rules mentioned above). In staging, we can insert / update the same data with the same kanji without any issues.
Although it seems to have been solved by opting out of that specific rule, I wanted to ask why this was? Why did it start to catch it all of the sudden and why doesn't it work / catch the same things on staging? What is libinjection?
(cloud armor link: https://cloud.google.com/armor/docs/waf-rules)
No comments yet.
