Help, my 'Request is blocked' by Front Door
In the serie 'Advanced Azure Front Door configuration strategies for Sitecore Managed Cloud on Containers', this is part 3: Help, my 'Request is blocked' by Front Door. In case you missed the first two parts, I wrote about part 1: simplifying managing Azure Frond Door IP whitelisting and part 2: parsing the Azure Front Door logs.
Sitecore Managed Cloud comes in two flavors: webapps and containers. In my role as Senior Solution Architect at uxbee, I setup and configured the container variant for a customer. In this blog series I will share my configuration experiences on Azure Front Door in combination with Sitecore Managed Cloud. I named this series ‘Advanced Azure Front Door configuration strategies for Sitecore Managed Cloud on containers’. Part 3 continues where part 2, Parsing Azure Front Door logfiles left off.
After I parsed the Azure Front Door logfiles to a csv-file, I was able to load the results in Excel. This way I could easily sort and filter the blocked requests..
As mentioned in part 2 of this blog series, I noticed that requests were blocked after we integrated CookieBot. While analyzing the results I found out, that only when the customer was connected to their business network and when they agreed with all the ‘CookieBot’ cookie setting, the ‘CookieBot’ browser cookie contained some content that triggered a SQLI rule in Azure Front Door.
After consultation with the customer's security officer, we decided to leave it that way and to not take any further action on it. However, at this time I still hear of site visitors that encounter this issue when they are visiting one of the sites that has an integration with CookieBot.
Going a bit deeper into the rule, I noticed that CookieBot cookies were not the only cookies that have issues with Azure Front Door. The article, Azure Front Door WAF is blocking .AspNet.ApplicationCookie, on Stack Overflow describes the same kind of behavior. Therefore I decided to dive a bit deeper into these types of issues and how to solve them.
How to solve blocking request issues
As an example I will take a more common blocking problem: DefaultRuleSet-1.0-SQLI-942440. The short explanation is ‘SQL Comment Sequence Detected’. This rule has a link to the .AspNet.ApplicationCookie when developing in .NET. Sitecore is a .NET application and uses this cookie when you log into the Sitecore Client (CM backend). Front Door has only set the IPWhitelist for the Sitecore Client. So, normally there is no problem like Front Door blocking access to the website. BUT, keep in mind that, for example, you are working with a base URL like this *.uxbee.nl. and using the following URLs:
- cm-prd.uxbee.nl
- website1-prd.uxbee.nl
- website2-prd.uxbee.nl
you could be blocked from website1 and/or website2 because of the same domain (uxbee.nl). The authorization cookie will be saved in the uxbee.nl domain. It will also be accessible from the website1 and webite2. On those URLs, Front Door is checking a lot of rules. SQLI-942440 will also check if the sequence of the dash characters ‘—' exists in the cookie. In SQL this means that after those characters everything is ignored and could be a potential SQL injection hack. The sad thing is that the aspnet auth cookie contains this sequence of ‘—'.
This next scenario could be possible: the customer is logging into the backend of Sitecore (cm-prd.uxbee.nl), the auth cookie is set in the uxbee.nl domain. The customer is working with the experience editor without any problem. When the customer is finished working in Sitecore, he or she types in the URL website1.uxbee.nl and gets the request is blocked page from Front Door.
The solution for the customer is to clear all the cookies, the websites will be accessible again.
We had this scenario happen because we were migrating websites from an old Sitecore environment to a new Sitecore Managed Cloud environment. Until the websites where live on the new environment, they aired on a temporary URL. Just like I described above, to clear the cookies was not a big problem, so we didn’t change a thing in Front Door.
Nevertheless, I would like to make this blog complete by explaining the steps to take to solve this problem. First, I will take a look at the Front Door WAF settings for the CD instance.
In the picture you see the managed rule of the WAF for the CD. If you look at the red rectangle you see that there is an option to make some exclusions. Before creating the exclusions, always confirm the intended exclusion with the security officer!
Let's add an exclusion!
Adding an exclusion through the UI is not very difficult. In the Excel-sheet we saw the blocking rule was DefaultRuleSet-1.0-SQLI-942440. The ruleset will be DefaultRuleSet-1.0, the rule group is SQLI and the rule is 942440. In the match value select ‘Request cookie name’, operator must be set to ‘Equals’ and the selector must be the name of the cookie. In this example we use .AspNet.ApplicationCookie.
So, what does this mean? In short, for the cookie with the name .AspNet.ApplicationCookie., the rule check DefaultRuleSet-1.0-SQLI-942440 is not executed.
UI vs. IAC
As you know you may not change anything in Managed Cloud through the UI, as Managed Cloud infrastructure is based on Infrastructure As Code (IAC). Any changes that are applied through the UI, will/could be overwritten in a next IAC release. To apply the change correctly, you have to update the correct Terraform.
A Sitecore Managed Cloud project contains two repositories:
- Application
- Infrastructure
This change has to be applied to the Infrastructure repository. In this repository, you locate the folder ‘frontdoor’ and in that folder open the terraform file named main.tf. In this file you can search for the term ‘resource azurerm_frontdoor_firewall_policy’.
Out of the box, Sitecore Managed Cloud has two firewall policies; ‘this’ and ‘cm’, in part 4 of these series I will explain why I created a third one. In this blog I will concentrate on the firewall policy ‘this’.
In the resource declaration there is a subsection managed_rule and as you can see on the image below, the DefaultRuleSet version 1.0 is set there.
Within the managed_rule section you must add the exclusion(s). You can consult the Terraform documentation for more information on how to apply exclusions. Whitin the managed_rule section you must add an override section. That override section will contain the RuleGroupName and the RuleId. Next, within the override, you can add the exclusion.
Ensure that you make the changes in a feature branch. From this feature branch, you can create a pull request into the main branch. Merging the PR into the main branch and run the Front Door pipeline. Once the pipeline has been successfully executed you can open Azure interface to check the changes!
Final note from me
I have said it before, but I cannot emphasize this enough. Be careful with adding overrides and exclusions, always consult your security officer for a final check. Beware that you are punching holes into your firewall security.
