Broncode netwerksite Facebook uitgelekt

Een weblog heeft de broncode van de in de VS populaire sociale netwerksite Facebook op internet gepubliceerd. De vraag is hoe de sourcecode heeft kunnen uitlekken.

Afgelopen zaterdag publiceerde weblog Facebook Secrets de broncode van de hoofdpagina van Facebook zonder verdere mededelingen. De netwerksite heeft bevestigd dat de publicatie inderdaad de bewuste broncode betreft.

Slechts enkele gebruikers zouden dankzij een verkeerd ingestelde server een fractie te zien hebben gekregen van de code die voor de weergave van Facebook-pagina's zorgt. Het was geen beveiligingslek en de gebruikersdata zou niet gecompromitteerd zijn, verzekert Brandee Barker van Facebook. De code zou ook geen inzicht geven in het functioneren van de site onder de motorkap.

Ondanks dat is de publicatie geen goed nieuws voor de netwerksite; als dit kan gebeuren kun je je afvragen hoe goed de gegevens van gebruikers beschermd zijn, aldus TechCrunch. De code zou volgens hem een potentiële aanvaller een goed startpunt geven. Facebook benadrukt dat webloggers met het publiceren van de code meerdere wetten overtreden en vraagt ze de tekst te verwijderen, desondanks heeft Facebook Secrets de posting laten staan.

Reacties (48)

[Verwijderd]

Ik heb zelf een community site met 80.000 leden en als ik hier de comments lees hebben wij een even ranzige code (volledig zelf geschreven).

Veel programmeurs denken te geek-minded waar iedere gewonnen bit prestatie's kan opleveren, echter is dat geek-minded denken niet altijd passend in het beleid / tijdsframe waar in je werkt.

Wat belangrijk is voor een community is vooral stabiliteit, usuability en money maken ... en zolang de huidige code werkt mag je tevreden zijn. Er staan weinig managers te springen om werkende code volledig te laten recoden. Pas wanneer je kan spreken over besparingen in de infrastructuur heeft een manager er misschien tijd voor om naar je te luisteren ...

[Dreamvoid]

En het is niet alleen geld: herschrijven van code breng vrijwel altijd weer nieuwe bugs mee, en voor je het weet is je nieuwe code nog onveiliger dan de oude.

[Insp]

hoezo herschrijven, waarom niet in keer goed (ik weet 100% lukt natuurlijk nooit),
hoe wil je anders werk overdraagbaar maken voor anderen?

[Erkens]

Veel van dit soort sites zijn begonnen als hobby/leer project. En dat is dan te zien aan de code. Na verloop van tijd zie je dat de code beter gestructureerd is, echter je blijft met oude troep zitten.

Maar aan de andere kant zijn er teveel developers die denken dat ze PHP "kunnen", terwijl ze er nauwelijks kaas van gegeten hebben.

[Verwijderd]

Helaas staat er niets interessants in de code. En is het nog eens ranzig geschreven ook.

[Verwijderd]

Wat is er allemaal zo ranzig aan dan ?

Geef eens wat voorbeelden uit de source en zet er ineens wat aanpassingen bij hoe jij het zou doen.

[elmuerte]

Tientallen includes achter elkaar, duid waarschijnlijk op een slecht ontwikkeld framework. Behalve dat zouden het requires moeten zijn omdat zonder de include de rest ook niet werkt of onstabiel word.

include_once $_SERVER['PHP_ROOT'].'/lib/statusupdates.php';

Misschien beter geweest om gewoon de include path goed te zetten. Of op z'n minst een constant te gebruiken.

param_get_slashed(array(
'feeduser' => $PARAM_INT, //debug: gets feed for user here
'err' => $PARAM_STRING, // returning from a failed entry on an[...]

Dat zou een constante moeten zijn en geen variabele. Nu is $PARAM_INT =& $PARAM_STRING mogelijk en opent de boel voor simpele SQL injection en what not over de gehele site. Verder is er ook geen enkel nut om dat variabel te houden.

En heel wat generieke code die bijna op elke pagina nodig zal zijn. Zoals userprofile reconstruction.

Vervolgens word er veel energie gestoken in template initialisatie die vervolgens nutteloos is vanwege een redirect.

En error afhandeling van input die compleet ergens anders verwerkt is (upload photo, network join, ...).

En volgens mij word er verschrikkelijk veel gebruik gemaakt van global variabelen.

Als PHP GOTO ondersteunde hadden ze die ook vast gebruikt.

[Reactie gewijzigd door elmuerte op 22 juli 2024 16:46]

[Verwijderd]

Die GOTO opmerking is compleet idioot. Er is helemaal niks mis mee, zolang je het goed gebruikt. Volgens jouw redenering moesten ze PHP maar verbieden omdat er zo veel slechte code in geschreven wordt ..

[Juup]

Bedoel je dat er met PHP of het GOTO niks mis is?

Het is toch alweer een jaartje of 40 dat GOTO als harmful wordt gezien:
http://en.wikipedia.org/wiki/Considered_harmful

[SWINX]

Die PHP_ROOT lijkt me zowiezo al weinig standaards..
Normaal zou je eerder vanuit je DOCUMENT_ROOT werken lijkt me?

[Soultaker]

Ik vind het anders behoorlijk netjes. Je moet ook wel bedenken dat die blogger de formattering behoorlijk verneukt heeft door alle leading whitespace weg te gooien, een niet-monospace font te gebruiken en na veel te weinig karakters te wrappen.

[progster]

Nah dit ziet er best onprofessioneel uit, dan moet je is naar een framework als joomla 1.5 kijken dat is nou mooie code!

[? ?]

// todo: password confirmation redirects here (from html/reset.php),
// do we want a confirmation message?

ja dat willen we misschien wel

[Verwijderd]

Mee eens, wat een ontzettend ranzige code.. Geen structuur te bekennen, gewoon een hoop procedureel gezeik na elkaar...

[SH4D3H]

Is het daarom misschien procedureel?
Dan komt alles na elkaar ...

En de structuur is er vast uit door de blog software ofzo.

[Verwijderd]

Facet, business deligate en business logic in 1 pagina, inderdaad pfffff...

[Verwijderd]

En toch maken ze per dag meer winst dan dat jij in een maand verdiend
Lekker boeiend dat het dan niet zo netjes geprogrammeerd is. Ik zou er mee kunnen leven

[aegis]

het is toch niet zo moeilijk om z'n pagina te krijgen als php niet goed functioneerd dan download je browser toch het php bestand omdat die het niet kan renderen?

[intoxicated]

Indeed
Is op GoT ook wel eens gebeurd kan ik me herinneren, alleen kreeg je dan een mooie Zend Encoded binary waar je alsnog niks mee kon

Opzich is dit natuurlijk wel dè reden om je echte scripts buiten public_html te zetten, dat zal op facebook dus ook wel gebeurd zijn

[Reactie gewijzigd door intoxicated op 22 juli 2024 16:46]

[Olaf van der Spek]

Ondanks dat is de publicatie geen goed nieuws voor de netwerksite; als dit kan gebeuren kun je je afvragen hoe goed de gegevens van gebruikers beschermd zijn, aldus TechCrunch.

Dit lijkt gewoon op een webserver waar PHP (alweer insecure-by-default) nog niet geinstalleerd is.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 16:46]

[BasieP]

je zegt nu dat PHP insecure is by default? of snap ik je verkeerd?

Aangezien PHP niet (goed) geinstalleerd was treft PHP hier imo compleet geen blaam.

Dit is puur een beheerders fout. Wanneer je asp hebt kunnen er net zo goed zulke domme fouten gemaakt worden.

[Olaf van der Spek]

je zegt nu dat PHP insecure is by default? of snap ik je verkeerd?

Ja.

Aangezien PHP niet (goed) geinstalleerd was treft PHP hier imo compleet geen blaam.

Het gaat toch om PHP code?
Die je standaard gewoon in de document root zet?
Waarom moet dat soort code in de normale document root?

[elmuerte]

Als je je webserver niet goed configureerd zal hij ook je perl/python/whetever scripts uit je /cgi-bin opsturen. Het heeft geen ruk te maken met PHP.
En er staat nergens dat je volledige PHP code in document root (of iig binnen een webtree) moet zetten (is volgens mij bij facebook ook niet zo geweest).

[Olaf van der Spek]

Als je je webserver niet goed configureerd zal hij ook je perl/python/whetever scripts uit je /cgi-bin opsturen. Het heeft geen ruk te maken met PHP.

cgi-bin is normaal geen sub-directory van htdocs en als cgi dus niet is geconfigueerd is cgi-bin ook niet bereikbaar.

En er staat nergens dat je volledige PHP code in document root (of iig binnen een webtree) moet zetten (is volgens mij bij facebook ook niet zo geweest).

Nee, maar het is wel de standaardmanier en PHP zelf doet er weinig aan dat te voorkomen.

Bull om te zeggen dat het aan PHP ligt. Als jij van een applicatie het wachtwoord leeg laat en iemand kan daardoor naar binnen is het nog geen fout van de applicatie.

Ik ben geneigd om te zeggen van wel. Apps zouden geen lege wachtwoorden moeten ondersteunen.

Je zet een file publiekelijk beschikbaar. Als jij dan nalaat in te stellen dat die file door een parser moet, is dat jouw domme fout. En er moet altijd iets in de docroot staan om dit dan te benaderen.

Nee hoor, kijk maar naar cgi-bin of fastcgi.

Als je er dan geen echte code in wilt, kun je altijd nog een "require LIB_DIR . '/index.php';" doen oid. Of is het dan nog steeds 'onveilig'?

Klopt, behalve dat PHP includes erg brak zijn en dat eigenlijk geen enkel script dit standaard ondersteund en PHP het zelf ook niet aanraadt.

[elmuerte]

cgi-bin is normaal geen sub-directory van htdocs en als cgi dus niet is geconfigueerd is cgi-bin ook niet bereikbaar.

Irrelevant, het is een alias naar een bepaalde directory. Als jij vergeet de directory opties goed te zetten voor executie van de scripts gaat het gewoon mis.
Of als je .pl geen shebang heeft of +x gaat het soms ook mis.

Voor de rest kan je Perl ook op dezelfde manier gebruiken als PHP meestal gebruikt worden, en ook vice-versa.

[Reactie gewijzigd door elmuerte op 22 juli 2024 16:46]

[Olaf van der Spek]

Irrelevant, het is een alias naar een bepaalde directory.

Natuurlijk is dat wel relevant. Die alias en de directory opties worden vaak geenabled met één commando. Bovendien zijn na een standaardalias of beide enabled of beide disabled, wat niet geldt voor PHP.

Voor de rest kan je Perl ook op dezelfde manier gebruiken als PHP meestal gebruikt worden, en ook vice-versa.

Heb ik iets gezegd over Perl?

[jurrie]

Bull om te zeggen dat het aan PHP ligt. Als jij van een applicatie het wachtwoord leeg laat en iemand kan daardoor naar binnen is het nog geen fout van de applicatie.

Je zet een file publiekelijk beschikbaar. Als jij dan nalaat in te stellen dat die file door een parser moet, is dat jouw domme fout. En er moet altijd iets in de docroot staan om dit dan te benaderen. Als je er dan geen echte code in wilt, kun je altijd nog een "require LIB_DIR . '/index.php';" doen oid. Of is het dan nog steeds 'onveilig'?

Net als altijd over windows wordt gezegd, het probleem ligt bij de gebruiker.

[Verwijderd]

Wat is dan niet insecure by default?

[Olaf van der Spek]

Bijvoorbeeld als PHP een andere document root zou gebruiken dan static files.

[Erkens]

Dat ligt dan aan je server, niet aan PHP. Ik kan prima mijn server zo configureren dat de PHP files nergens in de webroot staan. Net zoals je bijvoorbeeld zo kan configureren dat bijvoorbeeld je CGI, JSP of ASP files in je webroot staan leesbaar voor iedereen.

m.a.w. dit ligt niet aan PHP of Apache by default, maar aan een "incapabele" systeembeheerder

[Olaf van der Spek]

m.a.w. dit ligt niet aan PHP of Apache by default, maar aan een "incapabele" systeembeheerder

Oh nee? Hoe ziet de default Apache/PHP setup eruit dan?
Natuurlijk kan het allemaal anders, maar daar had ik het niet over.

[Erkens]

Een default Apache/PHP setup? Ik neem aan dat je bedoeld dat je Apache met mod_php bedoeld? Die is gewoon secure, .php files worden niet als plain text verstuurd Hoewel dat natuurlijk distro afhankelijk is. Als je bijvoorbeeld zelf vanaf source default installeerd dan zullen .php files natuurlijk niet door de php engine gaan aangezien je dit moet activeren in je config.

Maar ik denk dat jij alleen maar reageert om fijn te kunnen ranten op PHP. Echter PHP zelf heeft weinig te maken met het feit of het secure is of niet, helemaal als je er een extern product als Apache bij gebruikt. PHP is een interpreter, je gooit er een script in en na afloop komt er (doorgaands) html code uit. Zelfde verhaal met perl of jsp, en dat vergeet je eventjes

Zodra je uitgaat van een default setup denk ik dat je al gewoon fout bezig bent, je bent in zo'n geval iig niet een partij waar ik een site zou willen hosten.

[Olaf van der Spek]

Een default Apache/PHP setup? Ik neem aan dat je bedoeld dat je Apache met mod_php bedoeld?

Ja, helaas. Nog steeds is FCGI niet de aanbevolen oplossing.

Die is gewoon secure, .php files worden niet als plain text verstuurd

Inderdaad, maar met het single point of failure dat zodra PHP niet geinstalleerd is de files als plain text worden verstuurd.

Maar ik denk dat jij alleen maar reageert om fijn te kunnen ranten op PHP.

Ik hoop eigenlijk dat anderen ook inzien dat secure by default beter is, maar veel mensen lijken het liever allemaal op het bordje van de administrator te schuiven.

Echter PHP zelf heeft weinig te maken met het feit of het secure is of niet, helemaal als je er een extern product als Apache bij gebruikt.

mod_php is geen extern product van Apache. En Apache/PHP is nou ook weer geen vreemde exotische combinatie waar PHP geen rekening mee zou kunnen houden.

PHP is een interpreter, je gooit er een script in en na afloop komt er (doorgaands) html code uit. Zelfde verhaal met perl of jsp, en dat vergeet je eventjes

Zodra je uitgaat van een default setup denk ik dat je al gewoon fout bezig bent, je bent in zo'n geval iig niet een partij waar ik een site zou willen hosten.

Nee hoor, ik zeg nergens dat JSP of Perl (of ASP in dit geval) beter zijn op dit punt.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 16:46]

[Verwijderd]

Inderdaad, maar met het single point of failure dat zodra PHP niet geinstalleerd is de files als plain text worden verstuurd.

Single point of failure is bij mij nog wel secure by default, en zolang je niet op clusters of twin configs host heb je altijd een single point of failure. Op deze manier kan je natuurlijk altijd wel redeneren...

[i-chat]

dan ligt 't nog steeds aan de sys-admin, het is een development keuze op php zo dicht mogelijk bij de html code te houden, immer als je bij html een SSI opzet naar php en die vervolgens niet parsed ben je nog steeft fout, ook al is php dan S B D,


ik weet niet of dat is gekomen door dat windows, z'n beheer-structuur zo eenvoudig heeft gemaakt, of dat 't ergens anders kan, maar je kunt van app niet verwachten dat ze een user tegen zichzelf gaan beschermern, = in ieder geval niet in, server omgevingen waar mensen worden betaald om dinge goed te laten draaien,

[Olaf van der Spek]

maar je kunt van app niet verwachten dat ze een user tegen zichzelf gaan beschermern,

Waarom niet?
Het lijkt me zeer wenselijk om indien (goed) mogelijk een gebruiker tegen zichzelf te beschermen.

Zie bijvoorbeeld apt-get, die waarschuwt je ook als je base/required packages wil verwijderen.

[Reactie gewijzigd door Olaf van der Spek op 22 juli 2024 16:46]

[Sorcerer8472]

Tja, kan gebeuren als er ineens geen php/asp meer wordt geparsed... niet zo heel schokkend imo. Is wel deels af te vangen trouwens.

[kmf]

PHP die even uitgeschakeld stond. Hopelijk voor hun staan de config-bestanden in een directory buiten de root dan.

[Dima_2005]

include_once $_SERVER['PHP_ROOT'].'/html/init.php';

Euh, als deze zou zichtbaar zijn.... Daar staat de login voor de database

[iDrone]

Ik moet eerlijk zeggen dat ik niet veel van de "taal" afweet, dus of het een ranzige code is of niet kan ik niet over oordelen.

Waar ik wel over kan oordelen is de functionaliteit van Facebook (aangezien ik me daar geregistreerd heb), waar ik echt niets over te klagen heb. Het is supersnel en ziet er erg clean uit. Ik moet dus eerlijk zeggen dat het me weinig kan schelen hoe de "achtergrond" eruit ziet, als de voorgrond maar goed werkt.

Daarbij komt dat ik nimmer "gevoelige" info op internet zet, al lijkt de site nog zo veilig.

[Verwijderd]

[sarcasm]
Oh wat is het voor iedereen die een beetje van programmeren en php afweet toch makkelijk om meteen comentaar te geven op hoe slordig het allemaal geschreven is.

Laat me raden jullie(mensen met commentaar) werken allemaal als web programmeurs en hebben per kleine website minstens 15 programmeurs en een half jaar om alles op tijd af te krijgen. (hope you'll join the real world soon)
[/sarcasm]

In de echte wereld waar je geen 10.000.000 hits per dag krijgt (tenzij je websites als tweakers runt(en waarschijnlijk een groter budget kunt uittrekken) zijn er bepaalde deadlines die gehaald moeten worden en als programmeur werk je met iets dat je kent en makkelijk vind tot dat je iets beter tegen komt. Is dat laxheid? ik denk het niet het is de wereld van deadlines, bazen die niet begrijpen waarom je iets zou moeten veranderen (Dit werkt toch?) en meer van dat soort onzin.....

[tuXzero]

De code is een beetje rommelig maar dit komt waarschijnlijke omdat ze zo begonnen zijn en dan wel met PHP 4.x. Nu PHP5 uit is met allerlei frameworks (Zend Framework ) is security geen issue meer net als goede code. Maar toen met PHP4 was het MVC-model nog ver achter de horizon.