Tag

php Archives - AWS Managed Services by Anchor

A dev’s guide to safely escaping and encoding URLs

By | Technical | One Comment

A lot of the support work that we do here at Anchor involves looking at websites. You could say that we’ve seen a few websites in our time. Something we come across pretty frequently is inadequate protection when it comes to handling user-submitted form data and URLs. This might not seem like a big deal, but it has some pretty big security implications, mostly relating to cross-site scripting. These problems can enable malicious activity like leaking of private data. The short version is that user-supplied data can never be trusted, and you need to carefully escape and format the data to make it safe for the intended use, such as printing it on a webpage. A very simple example Let’s say you run a site that accepts news tips from…

Read More

The “chmod 777” trap: How and why to avoid it

By | Technical | No Comments

It can be a frustrating experience trying to get your web application to work. When the world seems to be working against you, and you get “permission denied” at every turn, it can be very tempting to break out the “chmod 777” — and give everyone on your server permission to write to your files. In case you’re not familiar with chmod, it’s a tool to specify access control on your files. The “7” refers to full read, write and execution privileges. The three sevens means that it applies to yourself, to other people in your group, and to everyone else on the server. While this approach does solve your immediate problem, it isn’t without its own drawbacks. They’re subtle drawbacks; you don’t notice them straight away, but given the…

Read More

Announcement of PHP security vulnerability (CVE-2012-1823)

By | Company News, Technical | No Comments

One of our sysadmins picked up the disclosure of this PHP vulnerability last week. It’s kind of important, so we thought we’d share it with you. Eindbazen PHP-CGI advisory (CVE-2012-1823) It’s interesting because a default mod_php installation isn’t vulnerable, but a fairly common deployment technique using php-cgi is (because it’s sane and not a gaping security hole the size of a hallway). Details are still up in the air. There’s a couple of official updates for PHP, but it’s been shown that they do not fix the problem. As a result, people have come up with a few mitigation techniques that will dodge this bullet until it’s properly fixed. To clarify our position, Anchor uses php-cgi and immediately took steps to mitigate the threat. We’ve written about our use of…

Read More

PHP on shared hosting – doing it better

By | Technical | No Comments

Large scale shared hosting with an out-of-the-box install of apache and PHP is a recipe for security-disaster; this is not news. The solution is to run each website’s code separately so they can’t affect each other. This is pretty common nowadays but it wasn’t always the case with many providers. Anchor’s been doing this for what must be about ten years now. That’s way longer than I’ve been employed here, but what with our tech-director-and-co-founder being busy stuntjumping his scooter over rows of parked cars, it’s fallen to me to write this one up. We use apache’s mod_suexec to run PHP scripts as though they’re CGI scripts, and it works great. There’s lots of guides out there about how to do this for yourself, but for us one of the…

Read More

Interesting failure modes, episode 2501

By | Technical | No Comments

I got woken up by a SMS for low diskspace the other night on one of our customer’s servers. Okay, so that’s a lie, I never sleep, but the SMS is real. Oh great, they’re making whoopie on their mailing lists again and making some stupidly huge logfile. Little did I know just how huge that file was. How about 735gb huge, in the space of 12hrs? This customer is already a bit of an oddball, what with 1.4TiB of usable space in their server. “Oh that’s nothing”, you say. Sure, I’ve got a few TiB of kitten pictures on my machine at home, just like you, but to put things in perspective: 300GiB of space would be “big” for most Anchor customers. SCSI disks cost about $1.70/Gb, compared to…

Read More

goto considered harmful – oh, wait, it’s just PHP

By | Technical | No Comments

Hot on the heels of PHP 5.3’s snazzy new namespaces, here comes goto. I kid you not, see for yourself: http://au2.php.net/goto Even Java, which we have little fondness for here, does not give you goto. This has to be one of the worst misfeatures yet in 5.3 (as opposed to the native MySQL driver, which only causes customers to ask for stupid things, like installing pre-alpha code on their production webserver). In case it weren’t clear enough, they go so far as to use an XKCD strip that highlights how bad an idea this is. I suspect this is some kind of sick joke…

Read More

Developers, you can stop your crap authentication schemes now. Please.

By | Technical | No Comments

I really like cryptography and security. I was lucky enough to take it as a subject at UNSW before I graduated. I found this earlier this evening; it’s a little old (~18 months), but that doesn’t make it any less relevant, so it’s a good read. There’s the odd inaccuracy here and there, but it’s solid stuff, and relevant to anyone writing webapp code to handle authentication. http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ The article focuses heavily on one particular authentication methodology, because it’s something a lot of people do. After you read it, you’ll understand that it’s something a lot of people do poorly. It assumes a reasonable degree of knowledge about what you’re doing (ay, there’s the rub), but the best lesson to be learnt there is that you shouldn’t be writing that…

Read More

Winning the war on PHP memory leakage

By | Technical | No Comments

One of our dedicated server customers recently had a problem with the machine keeling over and dying for a few days in a row, for no apparent reason. This necessitated a remote reboot of the server to get it running again (we cut the power to both power supplies for a few seconds). The immediate suspicion was faulty hardware, but this should rarely be the case as we put our hardware through a thorough “burn in” period before it’s ever deployed. In addition to this, it was happening pretty regularly in the middle of the day. After spotting this pattern, a quick look at our trending graphs showed us the problem very clearly. The machine was steadily using all available physical memory. Once this ran out, the system starts pushing…

Read More