Crafted URL special character request on site should not result in the request being cached they should bypass caching

[lukecav]

Site requests using any special patterns should not result in the request being cached by Cache Enabler.

Some of the example patterns which can cause recursive issues are as follows. Double pipes Parentheses Double backslash

[colindclare]

Examples of directory names we found that were cached by cache enabler, that led to the recursion in _clean_dir() in inc/cache_enabler_disk.class.php:

${@print(md5(31337))}\ response.write(9069995*9215255) health-behavior\'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),0)||\'

Crafted URLs were generated by a vulnerability scanning application, and stored by Cache Enabler, and led to infinite recursion and eventual segmentation fault in the above mentioned file.

[coreykn]

You're right, there are patterns in the file path that should cause the cache to be bypassed. I think using a regular expression to see if certain patterns exist in $_SERVER['REQUEST_URI'] would be the best approach to resolve this.

This will be easy to implement and the regular expression can be added to over time if more patterns are found. I'll start working on a solution for this.

[coreykn]

When first considering this issue I was thinking the HTTP status codes of the page requests would be successful. Now when thinking about this again I'm actually unsure of what scenario a successful status would be returned on a page request with special characters. This led me to notice that the Cache Enabler plugin is caching any HTTP status, even 4xx and 5xx in some cases. I've fixed this in PR #100.

Is this issue actually just related to Cache Enabler caching any HTTP status and in some case these patterns or do you have page requests with special characters that return successful status codes?

[lukecav]

Looks like PR https://github.com/keycdn/cache-enabler/pull/100 should fix the issue.