Pas op waar je je cookies plaatst
Cookies worden voor veel doeleinden gebruikt, maar voornamelijk voor het opzetten van een Session ID (SID). Door het SID kan een individuele gebruiker via zijn interactie met de website geidentificeerd worden. Voor een website die authenticatie vereist, wordt de SID aan de gebruiker gegeven als die geauthenticeerd is en wordt zo de authenticatie status beheerd. Als een aanvaller via sniffing of cross site scripting toegang kan krijgen tot de SID, dan kan hij de identiteit van de gebruiker overnemen, zo waarschuwt dit artikel (PDF) dat beschrijft waar cookies het best geplaatst kunnen worden.
Fortunately the solution to this issue is a straightforward
one. By simply specifying the cookie path argument
accurately, an application can take measures to protect
itself from flawed products that share the same hosting
environment.
een heel klein deeloplossinkje, en door geen echte
beveiligingsmaatregelen te beschrijven, wordt een
schijnveiligheid gecreeerd.
wat ik doe is elke sessie statisch koppelen met het ip van
de client, referer check (ook maar een deeloplossinkje dat
uitermate simpel te omzeilen is) een md5 hashes als
sessionid te gebruiken (zodat mensen ze niet zo makkelijk
kunnen raden). verder moet je het verkeer uiteraard over SSL
laten lopen, om sniffen van session ids tegen te gaan.
Dr.NO
wat ik doe is elke sessie statisch koppelen met het ip van
de client, referer check (ook maar een deeloplossinkje dat
uitermate simpel te omzeilen is) een md5 hashes als
sessionid te gebruiken (zodat mensen ze niet zo makkelijk
kunnen raden). verder moet je het verkeer uiteraard over SSL
laten lopen, om sniffen van session ids tegen te gaan.
Dit zijn allemaal serverside maatregelen die dus niet te
maken hebben met lokale diefstal van cookies, waar dit
artikel over gaat.
lokale diefstal van cookies wel tegengewerkt, want een
session id dat hard gebonden is aan een client IP is
lastiger te gebruiken vanaf een andere host dan een session
id die dat niet is.
Maar door de door dr No genoemde servermaatregelen wordt de
lokale diefstal van cookies wel tegengewerkt, want een
session id dat hard gebonden is aan een client IP is
lastiger te gebruiken vanaf een andere host dan een session
id die dat niet is.
Helaas ook niet echt een oplossing aangezien gebruikers in binnen een
netwerk vanwege een router of HTTP proxy hetzelfde ip adres delen.
scope van dat white papertje vallen, maar de scope is dan
ook uitermate klein.
Als je session-cookies mbt veiligheid wilt bespreken, moet
je dat echt een stuk vollediger doen dan die oprichter van
Corsaire.
dan kan ik niet op de VPRO-site komen... pech voor de
VPRO.... ;)
gebruikers in binnen een netwerk vanwege een router of HTTP
proxy hetzelfde ip adres delen.
HTTP_X_FORWARDED_FOR ook aangeven wat het echte IP van de
client is. maar idd, waterdicht is dat niet nee.
maar als er wat gebeurt, hoef je in eerste instantie niet
verder te kijken dan de mensen die jouw ip gebruiken.
ook handig is de Secure flag van het sid-cookie zetten (SSL
verplicht).
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
