Subscribe via RSS

Tag: Browser

On April 8th, 2009

Protecting Webpages

Never Trust Anything User Side - DUR!

I just read this article (Well-Intentioned Destruction) on The Daily WTF talking about a developer's experience where a clients whole system was being deleted randomly and without reason. After lots of hunting and digging around he discovered that a web crawler was accessing links to delete every article it crawled, thinking they were just more links.

They'd never run into this problem before, since they used header('Location: index.php'); to redirect visitors away from restricted pages if they're not logged in. But the location header does not deny access to the original page, it is simply an HTTP instruction to go to a different page instead. Since any system connecting over HTTP - especially crawlers - have the ability to choose to obey Location headers or not, the Location header cannot be trusted for any kind of security.

What did they need to do to resolve this bug? Well more than likely a deep code analysis with this new knowledge would be wise, but all they have to do to ensure secure data is not being served up is to add exit; after the header command - this stops the PHP script from executing and therefore outputting any secure data or running any secure commands.

It's interesting to note the different paradigm of thought different people go through, because the WTF blog suggests instead changing the delete command to a POST button, rather than a GET url, so that crawlers won't hit them anymore. That's true, but really disregards the problem entirely. button or link, without a command to stop all execution if the visitor is not authenticated, the security hole remains - modified, but just as big and gaping.

An Easy Fix:

if(!isset($_SESSION['usr_id']) || !isset($_SESSION['usr_name'])) { header('Location: index.php'); exit; }

Leave a Comment

Posted in: Browser, Security