Getting blocked on a PUT even though firewall rules are showing that request was allowed

[vlad3]

Hi there,
We just put a site behind cloudflare and are getting strange issues. Without changing any firewall rules we are able to access the site and all the GETs seem to work. When we try to ‘save’ something and do a PUT on a document we get a 403 from cloudflare. Inside of that 403 response is this page -

Please enable cookies.
One more step
Please complete the security check to access ml-box.iheartjane.com
  
Please stand by, while we are checking your browser...

Please turn JavaScript on and reload the page.
Why do I have to complete a CAPTCHA?
Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?
If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 660c40347cc103bc • Your IP: xx.xx.xx.xx • Performance & security by Cloudflare

This is happening on a PUT so that page does not show anything to the user, the site just breaks.

We added a firewall rule - (http.request.method eq “PUT” and http.host eq “ourhost.com”). According to logs we see that rule is hit and Allow is happening but in the web app we still get a 403 from Cloudflare.

Adding IP to a firewall does the same thing. We see in the logs that request was allowed but we get a 403.

I’ve set up Privacy Pass plugin and that didn’t change anything.

The only thing that seems to work is going to Tools and adding IP Access Rule for my IP. That is far from ideal and we would prefer to unblock PUTs on the site.

This does not seem like normal behavior. Why does this happen on a PUT and not on a GET? Why does firewall rule not work even though according to logs it does? Is there some other layer that is blocking us that I am not thinking of?

Any help would be appreciated. Thank you!

[Damian]

Hi there,

I think the first step is to understand what feature is causing the block - you can use the CF-RAY ID to look in your firewall rule events/analytics to understand what feature is blocking this - Understanding Cloudflare Firewall Analytics – Cloudflare Help Center

You can use the filters to see which feature is blocking it.

The most common issue that we see is that customer’s use ‘Allow’ Firewall rules instead of ‘Bypass’.

Allow Rules only allow the request to pass through other firewall rules that may block them, Bypass allows you to bypass other security features on Cloudflare (eg. WAF, limiting, Security Level) that could be causing this challenge. - https://developers.cloudflare.com/firewall/cf-firewall-rules/actions

[vlad3]

Thank you for your reply. I was able to dig deeper and got a better error. It looks like a false positive. This happens for multiple people in different countries.

Ray ID
6616dc8e0f6c2ae2
Method
PUT
HTTP Version
HTTP/2
Host
redacted
Path
/api/contents/test.ipynb
Query string
Empty query string
User agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36
IP address
redacted
ASN
redacted
Country
Canada
Service
WAF
Rule ID
OWASP Block (981176)
Rule message
Inbound Anomaly Score Exceeded
Rule group
OWASP Inbound Blocking
OWASP Score
128
Action taken
Challenge
Bot score
97
Bot source
Machine Learning
Export event JSON
Additional logs
28
960032 · Method is not allowed by policy	OWASP HTTP Policy	Log
960335 · Too many arguments in request	OWASP Request Limits	Log
960024 · Meta-Character Anomaly Detection Alert - Repetative Non-Word Characters	OWASP Generic Attacks	Log
950010 · LDAP Injection Attack	OWASP Generic Attacks	Log
981231 · SQL Comment Sequence Detected	OWASP SQL Injection Attacks	Log
981318 · SQL Injection Attack: Common Injection Testing Detected	OWASP SQL Injection Attacks	Log
981319 · SQL Injection Attack: SQL Operator Detected	OWASP SQL Injection Attacks	Log
981317 · SQL SELECT Statement Anomaly Detection Alert	OWASP SQL Injection Attacks	Log
950001 · SQL Injection Attack	OWASP SQL Injection Attacks	Log
959070 · SQL Injection Attack	OWASP SQL Injection Attacks	Log
959073 · SQL Injection Attack	OWASP SQL Injection Attacks	Log
981244 · Detects basic SQL authentication bypass attempts 1/3	OWASP SQL Injection Attacks	Log
981255 · Detects MSSQL code execution and information gathering attempts	OWASP SQL Injection Attacks	Log
981257 · Detects MySQL comment-/space-obfuscated injections and backtick termination	OWASP SQL Injection Attacks	Log
981245 · Detects basic SQL authentication bypass attempts 2/3	OWASP SQL Injection Attacks	Log
981242 · Detects classic SQL injection probings 1/2	OWASP SQL Injection Attacks	Log
981246 · Detects basic SQL authentication bypass attempts 3/3	OWASP SQL Injection Attacks	Log
981247B · Detects concatenated basic SQL injection and SQLLFI attempts	OWASP SQL Injection Attacks	Log
981243 · Detects classic SQL injection probings 2/2	OWASP SQL Injection Attacks	Log
973338 · XSS Filter - Category 3: Javascript URI Vector	OWASP XSS Attacks	Log
973300 · Possible XSS Attack Detected - HTML Tag Handler	OWASP XSS Attacks	Log
973302 · XSS Attack Detected	OWASP XSS Attacks	Log
973306 · XSS Attack Detected	OWASP XSS Attacks	Log
973335 · IE XSS Filters - Attack Detected	OWASP XSS Attacks	Log
973334 · IE XSS Filters - Attack Detected	OWASP XSS Attacks	Log
973333 · IE XSS Filters - Attack Detected	OWASP XSS Attacks	Log
973344 · IE XSS Filters - Attack Detected	OWASP XSS Attacks	Log
973332 · IE XSS Filters - Attack Detected	OWASP XSS Attacks	Log

Adding a WAF bypass rule on that url solved the problem but is there a better way of dealing with false positives?

Thank you!

[Damian]

It looks like you are being blocked by the OWASP WAF Rules. The OWASP WAF rules are an open source database of rules that block against SQLi and XSS attacks. The way it works is a request passes through the OWASP rules and is given a threat score based on how malicious that request is considered.

If you are seeing the OWASP triggering false positives, you can lower the sensitivity from High, Medium, Low or you can turn it Off under the ‘Managed Rules’ section of our dashboard in Package: OWASP ModSecurity Core Rule Set rulesets.

There is some improvements and a new version of the OWASP ruleset being made to customers as part of our new WAF that is slowly being released - so you may want to revisit this when the new WAF is enabled on your zone, which hopefully will reduce false postives - https://blog.cloudflare.com/new-cloudflare-waf/

Other than researching those different OWASP ID’s and trying to bring your application more in line with best practices to avoid them being detected by this is what you would need to do.