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.