Categories
Internet, Unix en security

Database keys hergebruiken of toch niet?

Soms zie je een leuke webapplicatie en het blijkt ook nog redelijk te werken, maar dan komt de vraag is het veilig of is er ruimte voor verbetering? Veel mensen kijken bv naar injecties om zo achter informatie uit een database te komen, maar soms wordt het gewoon aangeboden. Zo ook bij deze webapplicatie welke we fubar noemen aangezien ik de patch nog moet insturen.

Fubar wil gebruikers redelijk anoniem bepaalde data laten raadplegen en het linken naar bv de favicon van die website zou dan ook niet verstandig zijn. Los van het feit dat het onnodig problemen kan geven bij de aanbieder van die data door de favicon te moeten verversen, maar ook voor de gebruiker als de webserver met die favicon soms niet beschikbaar is of geen content wenst te downloaden buiten het domein van zijn HTTPS-connectie. Dit natuurlijk een nobel streven en al snel zien we cache directory vullen met bestandjes zoals hieronder bijvoorbeeld:

-rw-r--r-- 1 www-data www-data   306 2011-04-26 02:28 20.ico
-rw-r--r-- 1 www-data www-data  3638 2011-04-26 02:28 34.ico
-rw-r--r-- 1 www-data www-data  3638 2011-04-26 02:28 56.ico
-rw-r--r-- 1 www-data www-data   460 2011-04-26 02:28 4.ico
-rw-r--r-- 1 www-data www-data   318 2011-04-26 02:29 13.ico

En hier valt gelijk wat op eigenlijk. Waarom oplopende nummers? Een snelle check in de database en met een webbrowser bevestigen wat het vermoede was. Maar is het verstandig om deze constructie te gebruiken? Want eigen vertelt nu welk website op welke tupel in de database is opgeslagen. Raden naar valide keys hoeft dus niet meer, want ze staan online. Om zeker te zijn toch maar even in de code gedoken en ja daar komen we oa het volgende tegen:

return ICONS_URL . "/$id.ico";

Met een iets uitgebreidere patch dan alleen hieronder wordt de database key niet meer gebruikt, maar de URL van de website welke dan door een MD5-functie wordt gehaald.

return ICONS_URL . "/".md5($url).".ico";

Als we daarna weer in de cache directory kijken zien we netjes bestanden verschijnen welke niet meer te herleiden zijn naar een database key:

-rw-r--r-- 1 www-data www-data  2011 2011-05-10 18:11 642e92efb79421734881b53e1e1b18b6.ico
-rw-r--r-- 1 www-data www-data   561 2011-05-10 18:12 ac627ab1ccbdb62ec96e702f07f6425b.ico
-rw-r--r-- 1 www-data www-data   650 2011-05-10 18:12 735b90b4568125ed6c3f678819b6e058.ico
-rw-r--r-- 1 www-data www-data  3638 2011-05-10 18:12 e4da3b7fbbce2345d7772b0674a318d5.ico
-rw-r--r-- 1 www-data www-data   444 2011-05-10 18:12 9a1158154dfa42caddbd0694a4e9bdc8.ico

Het risico wat hier om de hoek komt is dat de hash ook verandert als de locatie van favicon van de website verandert. Je zou dit dus dan kunnen gaan gebruiken om foutieve image bestanden te cache waar je op een gegeven moment geen erg in hebt. Dit is ook een reden waarom de huidige patch nog niet de deur uit is, want wijzigingen in de URL moeten ook betekenen dat het oude bestand wordt opgeruimd.

De vraag die nu komt is welke database gegevens worden er nog meer gelekt en bij welke applicaties? Dit doet me ook een beetje denken aan de HashKnownHosts optie in OpenSSH welke alle nodes in het bestand known_host ook hashed. Hiermee komt eigenlijk ook de vraag of cachedata wel een zinvolle naam moet hebben.

Categories
Life and society

Zomertijd 2009

Voorjaar: Omschakeling van wintertijd naar zomertijd
Omschakeling van wintertijd naar zomertijd

Het halfjaarlijkse tijdcircus heeft dit weekend weer plaats gevonden en einde oktober gaan we weer een uur terug. De komende tijd moet de interne tijdklok weer worden gesynchroniseerd en ik kan al niet wachten. Hopelijk komt men er spoedig achter dat het misschien een goed idee is om dit tijdscircus gewoon zijn nek om te draaien en gewoon dezelfde tijd aanhouden voor elk deel van het jaar. Het zal ook besparen op code aanpassingen en het uitrollen van patches.

Wel toepasselijk dat evenementen zoals de nacht van de nacht en Earth Hour op deze dagen worden gehouden. Gelukkig heb ik vrijdagavond al kunnen oefenen met een extra uur aan duisternis door weer een stroomstoring (lang leve privatisering) en ik kon de kaarsen en olielampen weer aansteken. Wel fijn dat Eneco vrijwillig meewerkt met regelmatige testen om te kijken of mijn fallbackprocedures nog correct zijn.