Why my URI is blocked by WAF Cloudflare Specials rule ID 100063


#1

Hello Community,

I am not understanding why the Cloudflare Specials WAF rule ID 100063 is blocking my URI?

POST URI = package/544?preview=false&deploy=false&update=false&target=red
SQLi attempt with: two keywords + a subexpression + a comment

The URI only contains variables not keywords and comments.

Thanks,
Everett


#2

Reading the Firewall Events log always throws me for a loop. There’s the Rules Triggered, and Rules Matched. And sometimes it is a jumbled mess. Was 100063 the only rule listed for Triggered and/or Matched?

If you open that Event in the log, you’ll see a Ray ID. You can open a Support Ticket and include that Ray ID and maybe they can explain why that request was blocked. I’d even go so far as to Export that event and include it in the Support Ticket.

Login to Cloudflare and then contact Cloudflare Support


#3

Is that really the POST URI? i.e. what you see in Firebug/DevTools?

If so, while legal (I think), it is not customary to pass variables both in the URL (as is normal in GET requests) and in the payload (as normal in POST/PUT). So if you DO really send variables in the URL, I would convert them to attributes of POST, either by setting them as (hidden?) inputs in a <form>, or, if this is an XHR request, then as params input, e.g. https://stackoverflow.com/a/12676773 or http://www.openjs.com/articles/ajax_xmlhttp_using_post.php

I would like to emphasize that I do not work for Cloudflare and that even if you do pass variables in the URI, I’m not claiming that this is the cause; It’s just a guess.


#4

Thanks @sdayman, it was only 100063 triggered. I have opened up a support case.


#5

Hello @shimi, The URL POST is correct, returning HTTP 403. The Firebug does say “Unexpected token < in JSON”?

The articles are very helpful, I will pass them on to the developers.
Thanks,
Everett


#6

This sounds reasonable if it expected a JSON and instead got an HTML error from Cloudflare’s edge. HTMLs have lots of “<” characters. Though it is expected only if your code is not done right; Your JS code has to check the HTTP return code from the XHR response, and only try to read/parse the response if it was a successful response. (200, 304… see https://en.wikipedia.org/wiki/List_of_HTTP_status_codes for more information); If there was an error returned from the server, it should catch it and convey to the user that there was an issue.