Step 1.
To check if it's used
safely, first follow the instances where it is used:
1. md5($page) --> safe, md5() can eat anything.
2. strpos($this->page,...) -> safe, strpos can eat anything too.
3. If we were paranoid, we would check how these string functions behave with huge string. As we're dealing with URLs, which have a limited lenght, it's probably safe. If we were
trully paranoid, we would check anyway

4. If at any point the value is assigned to another variable, follow that one as well.
Step 2.
To check if it's used
correctly, follow the instances again:
1. You use md5() to "compess" the URL in the cache filename. URLs are not regular strings though.
Code: Select all
index.php?a=b&c=d
index.php?c=d&a=b
These are different strings, but the same URL. This may lead to cache misses, and can be used to exhaust cache resources, even if you check the validity of the URL. An URL with N parameters can be written in N! (N-factorial) ways, which will md5() to different cache names, even though they are the same URL.
2. strpos(...) -- this logic is not working, and it has never worked as it is written. Now let's suppose it is working. URLs are not regular strings, remember? Substring matching is not the correct way to handle this logic.
blabla.php?a=b&c=d&dummy=foo.com/rss.php will happily match, even though it's not what you had in mind.
So the attacker also has a way to stop the caching mechanism. He may choose a "heavy" page, pad the URL with a dummy value, and then post it on slashdot, so that the failed caching will DOS the server.