4 ms·

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

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á Resolving wildcards is trickier but definitely possible if you have a list of forbidden files [1]: https://nodejs.org/api/path.html#pathresolvepaths https://nodejs.org/api/path.html#pathresolvepaths Edit: changed link because C's realpath has a slightly different behavior

_1tem 1y ago
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.
watusername 1y ago
> 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/
TheDong 1y ago
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/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/lfi-os-files.data#L331 https://github.com/coreruleset/coreruleset/blob/943a6216edea... Here's where that file is loaded: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf#L99 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.

_1tem 1y ago

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.

watusername 1y ago

> 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/

TheDong 1y ago

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/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/lfi-os-files.data#L331 https://github.com/coreruleset/coreruleset/blob/943a6216edea... Here's where that file is loaded: https://github.com/coreruleset/coreruleset/blob/943a6216edea83e4656f6f8b19311ec504f58a3e/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf#L99 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.