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)
Helaas staat er niets interessants in de code. En is het nog eens ranzig geschreven ook.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.
Geef eens wat voorbeelden uit de source en zet er ineens wat aanpassingen bij hoe jij het zou doen.
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.
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.
Misschien beter geweest om gewoon de include path goed te zetten. Of op z'n minst een constant te gebruiken.include_once $_SERVER['PHP_ROOT'].'/lib/statusupdates.php';
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.param_get_slashed(array(
'feeduser' => $PARAM_INT, //debug: gets feed for user here
'err' => $PARAM_STRING, // returning from a failed entry on an[...]
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 maandag 13 augustus 2007 15:01]
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 .. 
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
Het is toch alweer een jaartje of 40 dat GOTO als harmful wordt gezien:
http://en.wikipedia.org/wiki/Considered_harmful
Die PHP_ROOT lijkt me zowiezo al weinig standaards..
Normaal zou je eerder vanuit je DOCUMENT_ROOT werken lijkt me?
Normaal zou je eerder vanuit je DOCUMENT_ROOT werken lijkt me?
Facet, business deligate en business logic in 1 pagina, inderdaad pfffff...
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
Lekker boeiend dat het dan niet zo netjes geprogrammeerd is. Ik zou er mee kunnen leven
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.
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
// do we want a confirmation message?
ja dat willen we misschien wel
Mee eens, wat een ontzettend ranzige code.. Geen structuur te bekennen, gewoon een hoop procedureel gezeik na elkaar...
Is het daarom misschien procedureel?
Dan komt alles na elkaar ...
En de structuur is er vast uit door de blog software ofzo.
Dan komt alles na elkaar ...
En de structuur is er vast uit door de blog software ofzo.
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?
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
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 maandag 13 augustus 2007 14:12]
Dit lijkt gewoon op een webserver waar PHP (alweer insecure-by-default) nog niet geinstalleerd is.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.
[Reactie gewijzigd door Olaf van der Spek op maandag 13 augustus 2007 14:13]
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.
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.
Ja.je zegt nu dat PHP insecure is by default? of snap ik je verkeerd?
Het gaat toch om PHP code?Aangezien PHP niet (goed) geinstalleerd was treft PHP hier imo compleet geen blaam.
Die je standaard gewoon in de document root zet?
Waarom moet dat soort code in de normale document root?
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.
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.
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).
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).
cgi-bin is normaal geen sub-directory van htdocs en als cgi dus niet is geconfigueerd is cgi-bin ook niet bereikbaar.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.
Nee, maar het is wel de standaardmanier en PHP zelf doet er weinig aan dat te voorkomen.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).
Ik ben geneigd om te zeggen van wel. Apps zouden geen lege wachtwoorden moeten ondersteunen.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.
Nee hoor, kijk maar naar cgi-bin of fastcgi.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.
Klopt, behalve dat PHP includes erg brak zijn en dat eigenlijk geen enkel script dit standaard ondersteund en PHP het zelf ook niet aanraadt.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'?
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.cgi-bin is normaal geen sub-directory van htdocs en als cgi dus niet is geconfigueerd is cgi-bin ook niet bereikbaar.
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 maandag 13 augustus 2007 15:37]
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.Irrelevant, het is een alias naar een bepaalde directory.
Heb ik iets gezegd over Perl?Voor de rest kan je Perl ook op dezelfde manier gebruiken als PHP meestal gebruikt worden, en ook vice-versa.
Wat is dan niet insecure by default?
Bijvoorbeeld als PHP een andere document root zou gebruiken dan static files.
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,
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,
Waarom niet?maar je kunt van app niet verwachten dat ze een user tegen zichzelf gaan beschermern,
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 maandag 13 augustus 2007 19:45]
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
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?m.a.w. dit ligt niet aan PHP of Apache by default, maar aan een "incapabele" systeembeheerder
Natuurlijk kan het allemaal anders, maar daar had ik het niet over.
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.
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.
Ja, helaas. Nog steeds is FCGI niet de aanbevolen oplossing.Een default Apache/PHP setup? Ik neem aan dat je bedoeld dat je Apache met mod_php bedoeld?
Inderdaad, maar met het single point of failure dat zodra PHP niet geinstalleerd is de files als plain text worden verstuurd.Die is gewoon secure, .php files worden niet als plain text verstuurd
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.Maar ik denk dat jij alleen maar reageert om fijn te kunnen ranten op PHP.
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.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.
Nee hoor, ik zeg nergens dat JSP of Perl (of ASP in dit geval) beter zijn op dit punt.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.
[Reactie gewijzigd door Olaf van der Spek op dinsdag 14 augustus 2007 08:12]
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...Inderdaad, maar met het single point of failure dat zodra PHP niet geinstalleerd is de files als plain text worden verstuurd.
Tja, kan gebeuren als er ineens geen php/asp meer wordt geparsed... niet zo heel schokkend imo. Is wel deels af te vangen trouwens.
PHP die even uitgeschakeld stond. Hopelijk voor hun staan de config-bestanden in een directory buiten de root dan.
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 ...
(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 ...
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.
hoezo herschrijven, waarom niet in keer goed (ik weet 100% lukt natuurlijk nooit),
hoe wil je anders werk overdraagbaar maken voor anderen?
hoe wil je anders werk overdraagbaar maken voor anderen?
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.
Maar aan de andere kant zijn er teveel developers die denken dat ze PHP "kunnen", terwijl ze er nauwelijks kaas van gegeten hebben.
include_once $_SERVER['PHP_ROOT'].'/html/init.php';
Euh, als deze zou zichtbaar zijn.... Daar staat de login voor de database
Euh, als deze zou zichtbaar zijn.... Daar staat de login voor de database
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.
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.
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
