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
Internet, Unix en security

Wat, waar en hoelang dingen te cachen

Door te cachen kan veel worden versnelt, maar tot welke prijs? Elke applicatie lijkt tegenwoordig zijn eigen cache-oplossing te hebben voor bv favicons, data binnen gehaald via HTTP, avatars, icons, maar ook sessies. En dit is natuurlijk allemaal leuk en aardig, maar als je regelmatig een backup wilt maken dan begint dit langzaam een probleem te worden. Een kleine scan in mijn homedirectory levert al z’n 1,6GB aan data op wat te bestempelen is als vluchtig.

$ du -sk .thumbnails .cache .gnome2/epiphany/favicon_cache .liferea_1.6/cache .evolution/cache .evolution/mail/{imap,nntp} .mozilla/*/*/Cache .nautilus/metafiles .purple/icons .config/gnome-session .config/session-state | sort -nr
983740 .cache
573764 .thumbnails
38088 .evolution/mail/nntp
30296 .evolution/mail/imap
3324 .gnome2/epiphany/favicon_cache
3284 .mozilla/firefox/h18d1d1h.default/Cache
1268 .nautilus/metafiles
428 .purple/icons
368 .evolution/cache
188 .liferea_1.6/cache
108 .config/gnome-session
100 .config/session-state

Nu zal het veel nut hebben, maar heeft het echt zin om thumbnails te bewaren van bestanden die al lang zijn gearchiveerd in /dev/null. En is het zinvol dat verschillende applicaties een eigen cache vullen om zo snel mogelijk een favicon op het scherm te toveren. Gelukkig volgen steeds meer applicaties de guidelines van Freedesktop.org om cache bestanden op te slaan in $HOME/.cache zodat ze makkelijk te excluden zijn voor oa backup en timemachine-achtige applicaties.

De vraag blijft dan eigenlijk over hoe lang een item in een cache moet blijven staan. Als het oorsponkelijk object niet meer bestaat? Als het al 30 dagen niet meer is geraadpleegd? Als de expiretime van bv het originele object is verlopen? Of laten we dit afhangen van de hoeveelheid vrije schrijfruimte of van de ondegelegen storage zoals een harddisk vs solid state disk. Een andere beslissing kan zijn dan lokaal cachen goedkoper is dan van ver ophalen. Bij dit laatste vraag ik me af of een HTTP HEAD-request echt veel extra kost.