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
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 /
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:
- Do not encode or decode “reserved characters”.
- For any other character, percent encode (ie, if we have a literal byte value of 0xb9, represent that as %B9).
- Convert any percent encoded forms to upper case.
- 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.