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']))
Just Add Salt
I've always been annoyed by websites and systems that have requirements for what kind of password you can use. GoDaddy, for instance, requires its FTP passwords have an uppercase letter and a number or it will not accept your password; and UC Davis requires your password be at least 7 characters long (and strangely, no more than 8). At first glance, this seems like good security practices, preventing users from picking weak passwords. But the fact of the matter is, a properly build system should be just as secure if a user picks a terrible password like apple as if they picked something ridiculous like'@pPl3S4uCe'. This article is an in depth analysis of the several options developers have to safely store user's passwords, and why requiring hard passwords is not the way to go.
No, Not Like The Cookie Monster
After reading an article about stealing cookies via using user-built webpages in subdirectories (not subdomains) of a website, I immediately thought of the personal webpages Willamette allows you to set up at willamette.edu/~username/ as a student. A website which didn't take such risks into consideration would allow any user of the system with a personal page to capture all the cookie data the real website is using, most notably PHP Sessions. Sadly Willamette uses HTTP authentication instead of cookie or Session based authentication so (at present) I can't capture anything of value. The only cookies I've so far seen willamette.edu set are cookies for Google Analytics. So at the moment Willamette seems to triumph over this particular hack, but there are countless schools out there which allow users to create their own webpage under the school's domain name with PHP, so I thought I'd let you all have a go at snagging the cookies of hapless visitors to your school's website.
Usable Code, That You Can Trust
The internet is a great repository of data, between google and wikipedia and countless other sources, if you look hard enough, you can find just about anything you can possibly imagine. But that's the problem, having to look, often very hard, and never really knowing if what you've found is really quality stuff.
Case and point, today I was looking for a data input sanitizer because I want to improve the functionality of the blog with comments and a couple of other tricks, but of course first you need to sanitize your input. I could (and at this rate probably will) write my own sanitizing script, and I'm pretty sure I could make it fairly secure, but why do all that, and run the risk of having a security hole, if you can find something that does it for you online? So I try some google searches: 'php input sanitizer', 'php form protection' 'free php form protection', etc. After a little digging I find a few promising looking sites and scripts, though not much. Even what I do find that looks promising, I have no way of knowing if it's trustworthy or not, do I?