Of course we cannot always share details about our work with customers, but nevertheless it is nice to show our technical achievements and share some of our implemented solutions.
After an Atlassian Confuence (Wiki) application was moved behind Cloudflare, a couple of problems were hit.
First the "Cloudflare OWASP Core Ruleset" needed to be disabled (in Cloudflare's Dashboard under Security -> WAF) or Confluence was not usable at all. After this change Confluence seemed to be running smoothly with the "Cloudflare Managed Ruleset" enabled. Until we discovered another issue.
When editing a page in Confluence you can finish the "editing mode" with either "Update" or "Close".
After clicking the "Close" button (without any changes), Cloudflare's WAF ruleset didn't like this at all and blocked the request.
Besides showing a Cloudflare-internal Ray-ID and the client IP address, no further information is shown WHY the request was blocked.
To find this specific request, you need to be logged into the Cloudflare Dashboard and your site (domain) needs to be selected. In the left-hand navigation locate Security -> Overview. This will show logged firewall events, including blocked requests.
By scrolling down a bit, the activity log at the bottom of the page shows up. Each blocked request is logged in detail here.
Each event can be identified with its own unique ID (Ray-ID). Therefore we can search for a very specific event with the same Ray-ID we have received before: 71f3e1cc6bd001f8.
This log entry also shows the responsible WAF ruleset for the block: "Cloudflare Managed Ruleset". It also shows the rule inside the ruleset which triggered the block: "XSS - JavaScript Events". We can see that the rule was fired on the URI Path "/confluence/pages/doeditpage.action" on a POST request.
With this information we can build an exception rule to skip one or more WAF rules.
To create an exception rule, navigate to Security -> WAF and select the tab "Managed rules". Here you can see the Cloudflare managed rules and whether they are enabled or not. And you should see a button "Add exception":
A small form "Add exception" will show up.
The exception name is basically just a description of what you want to achieve by creating the exception. It should be understandable not just for you but to your team mates as well.
The exception condition (when incoming requests match...) is using one or more fields, based on the HTTP request. From the logged event above we know that the rule was fired on "/confluence/pages/doeditpage.action". We can therefore use the "URI Path" field and use this path as value.
The final step is to decide whether all or only specific rules should be skipped. To avoid opening too many potential holes, we only select the specific rule which caused the block: Rule ID a1a6c0e5c3c54eb9a495e9bc602dabe0 (XSS - JavaScript Events) in the Ruleset efb7b8c949ac4650a09736fc376e9aee (Cloudflare Managed Ruleset).
After a click on "Deploy", you can now see this new exception rule show up under managed rules:
The exception rule "Confluence allow edit close" was placed at the bottom. It should be moved to the top, before hitting other "Execute" rulesets:
Note: I'm actually not 100% certain if moving the exception to the top is necessary. In my case it took a couple of minutes until Cloudflare enabled the excepton rule. It could have also been a matter of waiting a few minutes.
A couple of minutes after deploying the exception rule, the Cloudflare block disappeared and could not be reproduced anymore.
As Atlassian applications (such as Confluence or Jira) are complex applications, allowing (and requiring sometimes) special characters (relaxed chars) in the HTTP requests, a WAF rule can easily be triggered. This is also the case with Cloudflare's WAF.
Whenever a WAF, any WAF, is enabled in front of a web-applications, no matter how complex or simple it may be, the logs should be analyzed in the hours and days after.