ACTION REQUIRED: URL Normalization has NOT been enabled on your Cloudflare zone(s)

OK that breakdown makes more sense, I do have URLS like this:

*example.com//login.php

That are blocked in my Firewall, so removing the double slash for a single one is easy…

BUT…

I dont have this mysterious “Rules” tab at all, it simply says Page Rules and has no “Settings” link (see pic)

Does this change when you have removed all the offending Rules in question, or is this an email sent to me (a Pro user) but was only intended for Business and higher users?

Very confusing

Sorry but its a bit more complex than that. but basically there are different ways to write the same url and normalization rewrites it to that ONE specific url making it normal.

So for everbody a
TLDR: All urls can now be normalized meaning that some of your page rules might be worthless because they never will be hit. Make sure you use normalized urls in your page rules or they will simply be ignored.

I have received that email as well. And, I have Normalize incoming URLs setting turned to on. I also have a rule under “Firewall Rules” as

URI Full    contains     //www.example.com/abcd.html

I have read the email, and the KB article and while I understand that CF is asking me to verify that Normalization is enabled, I am unable to figure out what exactly is that I need to do with the above rule? Should I just remove the two slashes and replace them them https:// ? If I do so, will I have to create another rule with http:// (no SSL) version too?

this is exactly how i have been interpreting this. And its working for me too =)

I’m not a Pro user. I’m guessing that they’re still rolling this out. And I’m sure this Settings tab is something that will remain, since you need to be able to toggle these two options on or off.

The “two slashes” reference is referring to two slashes in the URI path, not the protocol. i.e. http://example.com/foo//bar.htmlhttp://example.com/foo/bar.html

Yea it’s really confusing

I dont have the Settings link to enable Normalization or see if it in enabled or not

Hopefully someone who has worked on this project can chime in at some point

Yeah that’s strange :smiley:

When I switch domains while already on that settings page, the lower section of the page flashes a 404 for a second until the settings load for the next domain. I’m positive they are still rolling this out or still working on it on the back end or something.

Does that I mean I can keep my existing rule as is and do not need to change any thing in response to this email?
Existing rule:

URI Full    contains     //www.example.com/abcd.html

Thank you for your help!

Did you create two separate rules then? One with http:// and one with https:// thus replacing the // with those? Thanks.

That’s what it means!

Even after reading now the kb article im not sure how exactly the FW Rules have to be adapted.

IN the eMail: any rules that are looking for ‘//’ or ‘../’ in URL paths.

My Block Rules in Question:

1. (http.request.uri.path contains "/.htaccess")

2. (http.request.uri contains "..%2F")

3. (http.request.uri contains "../")

4. (http.request.uri contains "/wpad.")

Rule1: IMHO nothing to change as the rule start with /. ?

Rule2: Do I have to remove here the 2 dots just and leave %2F ?

Rule3: IMHO this Rule has to be removed complete ?

Rule 4. IMHO nothing to do ?

Thx

The // and …/ are just examples, there is a plethora of normalization examples - we can only add so much before the emails become too long to read :slight_smile:

Regarding your examples, the simplest ones to explain are ‘…/’ which is a common path traversal attack. With Normalization enabled this will be normalised to ‘/’ instead, meaning the firewall rule will no longer match (as it wont ever see ‘…/’ again).

Common examples of “Path-resolution normalization” are:
* becomes */
// becomes / (Not part of the RFCs)
Leading ./ or …/ becomes /
Trailing /. becomes /
/./ becomes /
/…/ becomes /
Resolve path

The other example is looking for ‘"…%2F"’ within the URI Path. This is called percent-encoding. With normalization enabled this will be normalized to ‘/’, again meaning the firewall rule wont trigger.

An overview of how we implement Percent-encoding normalization are:

  1. Do not encode or decode “reserved characters”.
  2. For any other character, percent encode (ie, if we have a literal byte value of 0xb9, represent that as %B9).
  3. Convert any percent encoded forms to upper case.
  4. Spaces (%20) remain unchanged.

The easiest way to explain normalization is the following; you have a firewall rule of: (http.request.uri contains “/login”). Without normalization, I can send in an HTTP request with the ‘l’ percent-encoded, i.e. ‘curl --path-as-is https://www.example.com/login’. This request will be allowed through your firewall and will make it to your origin server/application.

Now, if you enable URL Normalization ‘incoming’ only, then Cloudflare will see the request with the URI Path of ‘%6cogin’ and normalize it to ‘/login’ before the request is seen by any other Cloudflare products. This means that Firewall Rules now see’s ‘/login’ and blocks it correctly.
Valid requests such as ‘https://www.example.com/legit-request’ will be normalized to ‘https://www.example.com/legit-request’, analysed by your rules, and if unblocked then it will be sent through to origin - but with the origin URI path of ‘/legit%2Drequest’. This is done to avoid breaking any origin-side applications such as API’s that rely on encoded requests.

If you decided to enable normalization ‘to origin’ also, then requests to https://www.example.com/legit-request will be normalized for processing by all Cloudflare products but will also be sent to the origin server with the URI Path ‘/legit%2Drequest’ also.

The intention of normalization is to prevent malicious actors manipulating HTTP requests to get around security settings by normalizing all requests to a standard format which then allows you as the user to predictability write rule filters.

2 Likes

This literally just confuses me more

It would be simpler (for CF users) to include the Rules that are stopping Normalization from working than a blanket email like we did receive.

I still dont know which exact Rules are a problem, or if they are still a problem.

Is there not a tool to run to check which Rules are an issue?

Further to this when I look at the Normalization settings Page (which I now can actually see at last) it says it IS actually ON for the domain I had an email about saying it was OFF.

The issue is everyones rules are different. The email recipients were generated based upon a filter of ‘does this zone contain a firewall rule which looks at the URI path, and if so, is there a special character in that filter?’.
There are two approaches you can take, per the KB.

  1. Edit your Firewall Rules to change ‘http.request.uri’ to ‘raw.http.request.uri’. This means that the firewall rule will still see the raw, un-normalized values even when URL Normalization is enabled.
  2. Update your Firewall Rules, i.e. you dont need '(http.request.uri contains “…%2F”) and (http.request.uri contains “…/”) anymore as they will be both normalized to ‘/’.

I apologise for the confusion, but unfortunately this is a feature that is really difficult to make user friendly given the nature of it :slight_smile:

1 Like

I’ve removed the only Firewall Rule I think is an issue

It says in the Settings page that Normalization is ON (by default it seems)

I guess that is all I can do (given there is no way to double check all is as it should be)?

The UI is concerning, can you DM me your zone name and I’ll investigate?

Um how do I DM? :rofl: