Comment by augusto-moura

The reason it's doomed to failure is because WAFs operate before your application, and don't have any clue what the data is.

Here is a WAF matching line: https://github.com/coreruleset/coreruleset/blob/943a6216edea...

Here's where that file is loaded: https://github.com/coreruleset/coreruleset/blob/943a6216edea...

It's loaded with '"@pmFromFile lfi-os-files.data"' which means "case-insensitive match of values from a file".

So yeah, the reason it can't resolve paths properly is because WAFs are just regex and substring matching trying to paper over security issues in an application which can only be solved correctly at the application level.

> How would that be hard? Getting the absolute path of a string is in almost all languages stdlibs[1]. You can just grep for any string containing slashes and try resolve them and voilá

Be very, very careful about this, because if you aren't, this can actually result in platform-dependent behavior or actual filesystem access. They are bytes containing funny slashes and dots, so process them as such.

Edit: s/text/bytes/

It’s not hard, but I think that’s more computation than a CDN should be doing on the edge. If your CDN layer is doing path resolution on all strings with slashes, that’s already some heavy lifting for a proxy layer.