client fingerprint
Wat kun je allemaal gebruiken om een "fingerprint" van een client te maken?
Ik dacht aan de languages, de encoding methods en de user agent. Zijn er nog meer mogelijkheden?
Maar jij gebruikt alleen de user-agent en niet de languages en encoding types?
Maar ik heb wel eens gelezen (en kon het helaas niet terugvinden) dat op het niveau van één site alleen al de header User-Agent zó uniek is dat deze zich leent voor een persoonlijke fingerprint van elke bezoeker. Hangt er statistisch natuurlijk ook van af of je jaarlijks 10.000 unieke bezoekers of 10 miljoen unieke bezoekers hebt.
Op internet zie ik namelijk scripts die via javascript en flash ook nog allerlei info van je computer halen. Bijv. welke lettertypes er allemaal op staan. En op die manier krijg je inderdaad een unieke fingerprint.
Wat ik zoek is eigenlijk iets "lichter". Ik heb nu dus een string gemaakt van de user-agent, de languages en encoding methods. Wat ik wil bereiken is dat wanneer tijdens een sessie deze string verandert, dat ik dan de sessie vernietig. Zodra deze gegevens namelijk veranderen tijdens een sessie, zou dat inhouden dat er van browser is gewisseld. En dat kan niet, dus op dat momnent gaat het vermoedelijk om een hack-poging.
Mijn enige vraag die ik nu nog heb is...
Wat is de beste manier om deze string te hashen, zodat ik hem gedurende een sessie kan controleren? Dus stel de string is (versimpeld):
$string = 'nl,en-gzip-mozilla';
Dan wil ik daar een hash van maken. Welk algoritme is daarvoor het meest geschikt? Omdat de controle bij iedere pagina-aanroep moet plaatsvinden moet het een heel snel algoritme zijn, want de client mag er niks van merken. Waar moet ik voor kiezen? Md5, sha1, sha256, sha512? Kan iemand daar advies over geven?
Je kunt beter een token uitwisselen dat bij elke response verandert en vervolgens bij elke volgende request moet worden geretourneerd. Retourneert de client het verkeerde token, dan vernietig je de sessie.
Kun je uitleggen wat je hiermee bedoelt? Het is overigens niet de enige vorm van security die ik wil inbouwen, maar zie het als een "extraatje".
Stel ik gebruikt IE10 en ben ingelogd. Vervolgens probeer jij mijn sessie te stelen. De hashes worden gecontroleerd. Aangezien jij Firefox gebruikt zijn de hashes ongelijk (als gevolg van een verschillende user-agent). Boem, de sessie wordt vernietigd.
Waarom zou dat niet werken? Een hacker weet van tevoren niet welke browser ik gebruik en welke languages. Zodra hij een sessie te pakken krijgt is het al te laat. De hashes matchen niet dus de sessie wordt vernietigd. Toch?
Die aanname is verkeerd. Een hacker kan op verschillende manieren de headers van jouw browser ontfutselen. Hij kan je bijvoorbeeld naar een webpagina lokken of je webmail met een plaatje laten openen; dat is al voldoende om de standaardheaders van Ozzies browser te ontfutselen.
Gewijzigd op 31/03/2014 13:05:56 door Ward van der Put
Laten we er vanuit gaan dat die hacker "op de gok" wat sessie-ids gaat proberen, en hij schiet een keer raak. Helaas, z'n browser matcht niet. Sessie wordt beëindigd.
Het voorbeeld wat jij noemt snap ik ook, maar de hacker moet dan al weten dat hij mijn headers nodig heeft. Als ie dat niet weet gaat ie al de mist in.
Het is dus puur een extra stukje veiligheid.
Rest mijn vraag... welke algoritme kan ik gebruiken voor het vergelijken van de strings? Ik lees her en der dat md5 en sha 1 wordt afgeraden tegenwoordig?
>> Rest mijn vraag... welke algoritme kan ik gebruiken voor het vergelijken van de strings?
Als je de clientheaders in de sessie opslaat, dus op de server, is helemaal geen hash nodig. Een snel algoritme zoals MD5 is voldoende als je toch een hash wilt opslaan.
>> Ik lees her en der dat md5 en sha 1 wordt afgeraden tegenwoordig?
Als je de hash deelt met de client wel, maar daarvan is bij het beveiligen van een sessie met de hash van een clientheader geen sprake. Je hebt zelfs helemaal geen hash nodig, zoals gezegd.
Je bedoelt dat je gewoon de niet-gehashte string zou kunnen opslaan?
Als dat is wat je bedoelt, dan heb je gelijk. Een hash is echter korter, dus minder ruimte om op te slaan en sneller om te vergelijken. Dus vandaar lijkt me dat wel handig. Maar oké... een simpel algoritme volstaat dus begrijp ik uit wat jij zegt :)
Wel kleiner, maar daarom niet per se sneller: je moet immers wel minstens twee keer de hashfunctie aanroepen en dat kost ook tijd.