Of course it's vulnerable!
A recent college grad is taking credit for the disclosure of Facebook's proprietary source code in an episode that demonstrates just how porous Web 2.0 technology can be. His warning, which also included a rebuke for bad manners at Facebook, came as a second batch of purported Facebook code surfaced online, raising new …
To clear everything up. I received a call from Rudy (the original guy from Facebook who emailed about my posting). He was a nice and cordial guy. I basically told him that I wanted to make everything clear about the code that was posted. He promptly thanked me for following up on their request for taking down the code. Rudy told me they're aware that I have no affiliation with the person reposting Facebook code on another website which is hosted by Google. I also told Rudy that this wasn't the first time that I had received a php error code from Facebook's website. The conversation was short and it ended as I expected it to.
Did he explain as to why the glitch occurred? Or what they're doing to prevent the problem again?
Surely you couldn't have been the only person to have had that problem... perhaps the only competent person to have noticed and done something about it... but surely not the only.
It was a misconfigured server apparently. He didn't tell me this but that's what they said in previous statements.
I'm fairly new to this LAMP stuff, but from what I can see it looks as if they may have just accidentally set a few directories to non-executable in their apache.conf, or even forgot to remove some comments after making the server live -- or the IIS if they use Windows (I don't use facebook so wouldn't know).
As for exposing vulnerabilities because the code is there for all to see -- erm, aren't the vast majority of web servers running on open-source platforms anyway? I realise this is "proprietary" code and not group-created but, still, I can't see how it could be that much of a problem?
The fact open-source programs release their source code, is often credited as a reason for their security. As everyone has access to the code anyone can find and suggest fixes to vunerabilities, and it also keeps the thought that your code must be secure even when attacked by someone who has read it in your mind.
Facebook's code isn't supposed to be seen by people, that makes it quite likely that it hasn't been coded to resist attacks by people who have the code. Obviously this doesn't have to be true, and hopefully Facebook ensure their programmers code is secure.
Facebook spewed a load of PHP code at me the other day aswell. A friend had a days worth of posts/profile changes go missing and another friend was able to see someone else's private messages... maybe the pub is a safer place to provide friends with every details of your life?!
Cameron, this has been caused either by a server without PHP installed or a server with a misconfigured PHP. Almost certainly, the server didn't know to parse what it was serving as PHP before... serving it.
Nothing to do with executable bits or any of that nonesense.
..or, at a pinch they may not have PHP installed at all.;~)
I only wondered about changing Apache settings as I can make a server spew PHP code instead of pages quite nicely using <Directory>...</Directory> directives in apache.conf.
Though, whichever, my main point about that was that not being able to execute PHP is probably more secure than allowing it to execute.
Seriously, this should be fairly straightforward stuff. You update the server software, change the server config, or alter the site code, you test it, fix any problems, repeat until not broken.
Not being able to get that right hardly speaks volumes for their overall competence and doesn't fill me with confidence that they have a secure web application.
This isn't just Facebook though, I've had a couple of occasions where a site will puke out its PHP code. Extra points for sourcecode where the database access credentials are exposed?
Cameron and Rob are right about what is causing it.
I'd also bet there was a config file that contained the user / pass for the database as well. If you can request the file directly and the PHP install breaks you could get the database username and password.
There are products availble that obfuscate the PHP source code such as ioncube. If they prized their source code they'd be using it already.
Given enough time, any idiot could develop it with a copy of Sams Teach Yourself PHP & MySQL in 24 hours.
If they prized there security, they would have had a standard hardening and build procedure in place before putting a server into production... the whole thing just looks really sloppy to me.
I've said it before, and I'll say it again. If this is Web 2.0, I'll wait for 2.1.
Most of the code is written by guys (almost exclusively guys, it seems) who have never had to write real code for the real world. Testing seems to be a case of "why, check this out and tell me what you think". No walk throughs, probably no design analysis, very little specing. Nothing you'd find at a serious software company. Not that there are very many of them left.
If you're going to post on Facebook or MySpace, you might as well post the following information: home phone, mobile phone, home address, car license number, credit card number, DOB, mother's maiden name, SSN (or equivalent for your region of the world) and nude pictures. I recommend, however, that you Photoshop the pictures first to enhance those physical features that typically need enhancing. Or go to one of the fakes sites and get one of those guys to do it.
Facebook also appear to lack proper separation between their production and testing/development servers. Bad code will be the least of their worries.
Compiled code such as servlets and C++ cgi scripts vs Perl and PHP
Question is if todays developers used compiled code would this have happened ?
I use perl from time to time and have used servlets I think developers should think twice about perl and php since for a start its defintily slower.
fscked by SHA-1 collision? Not so fast, says Linus Torvalds