Sikkerhed ved sessions.

Hejsa.

Hvad er den sikreste måde at opbevare login-oplysninger i sessions på, når man er logget ind på et websted?

Jeg tænker umiddelbart bruger-id + tilfældigt genereret kode, genereret ved login, som tjekkes ved hver anmodning af en beskyttet side, og ikke andet end disse to.

Hvad er jeres mening?

Se http://stackoverflow.com/questions/2307946/how-to-...

#1

Jeg er ikke sikker på at jeg forstår spørgsmålet.

En browser session får tildelt et session id som opbevares enten i en session cookie eller er en del af URL. Det session id skal være kryptografisk stærkt random (på dansk: ikke muligt at gætte). Ved alle gængse web teknologier genereres de af serveren.

Du kan enten brug app managed eller container managed security. Ved app managed security gemmer din app login info i session objekt. Ved container managed security sørger container for at mappe mellem session og user info.

Man kan ikke tilgå andre sessioners session objekt, så der er ikke nogen grund til at gøre noget specielt ved det.

Sikkerhed på nettet:

Ordbogen.com:
Gemmer IP og UA.

newz.dk:
Giv din cookie til en ven, og han har fuld adgang (kan endda skifte dit kodeord). De plejede at gemme IP, men det blev fjernet, da det nye login blev introduceret.

#4

Her taler du så om en permanent cookie for at undgå login.

Nå ja, jeg kom aldrig rigtig frem med pointen: Man skal kunne se, hvis en cookie (som jo indeholder session id) skifter ejermand.

Ups ja, det her var vist en brainfart. Fik byttet rundt op cookies og sessions. :-P

Cookies er nemme at modificere, men ikke session variable, som ligger server-side.

Der kan jo så ske session leaking, osv. men der tager jeg allerede nogle forholdsregler for at dæmme lidt op for risikoen for det.

Tak for hjælpen guys.

Spiderboy (1) skrev:

Jeg tænker umiddelbart bruger-id + tilfældigt genereret kode, genereret ved login, som tjekkes ved hver anmodning af en beskyttet side, og ikke andet end disse to.

Det er ikke helt nok.

Hvis du gør det som du har beskrevet vil der være to ting som nok ikke kommer til at virke. Derudover vil der være et sikkerhedshul.

Lad os starte med sikkerhedshullet. Der er en klasse af huller som hedder XSRF huller. Den nemmeste måde at beskytte sig imod dem på er ved at generere en tilfældig værdi per session. Hver gang du sender en form til brugeren laver du et skjult felt med denne værdi i. Hver gang du modtager en form fra brugeren checker du at det skjulte felt indeholder den rigtige værdi.

Uden dette skjulte felt kan andre sites lave forms der angiver en URL på dit site som action og derved udsætte brugere for misbrug hvis de har flere tabs åbne.

Den hemmelige værdi i dette felt kan passende konstrueres som 42 tilfældige tegn valgt blandt cifre samt store og små bogstaver.

De ting som ikke vil virke er flere samtidige logins. Der er to vidt forskellige features relateret til flere samtidige logins som værd at tænke på. Det der skal til for at implementere dem er dog ret forskelligt.

Situation nummer et. En bruger ønsker at logge ind fra flere browsere samtidigt. Hvis du genererer en tilfældig værdi ved login og gemmer den i en cookie, da vil serveren også skulle gemme samme værdi. Men hvis brugeren logger ind fra flere browsere samtidigt er du nødt til at gemme mere end en værdi per bruger for at det virker.

Du kan vælge at lade serveren gemme alle de forskellige værdier. Men så er serverens ressourceforbrug afhængig af hvor mange samtidige logins brugerne har. Mange sites "løser" dette problem ved at lave korte timeouts hvorefter de sletter sessionsdata. Det er ikke særlig brugervenligt.

Det er bedre at gemme tilstrækkeligt med oplysninger i cookies. I stedet for at gemme en tilfældig værdi i en cookie kan du gemme en værdi der beskriver brugerens login og beskytte værdien med en HMAC således at brugeren ikke kan ændre den.

Værdien skal som minimum fortælle hvilken bruger der er logget ind. Det kan passende kombineres med enten login tidspunkt eller timeout for sessionen.

På den måde får du aldrig brug for at lave timeout for at spare ressourcer på serveren. Timeout vil dermed kun være af sikkerhedshensyn, således at et glemt login ikke vil være gyldigt for evigt.

Når brugeren kan logge ind fra flere browsere på samme tid vil det også være smart med en remote logout feature. Det kan gøres på følgende måde.

På serveren gemmer du et timestamp for hvornår hver enkelt bruger sidst har aktiveret remote logout. Den HMAC beskyttede cookie kan så indeholde et login tidspunkt. Når remote logout aktiveres opdateres login tidspunktet på den browser der aktiverede funktionen. Hver gang du checker en cookie kan du se om login tidspunkt er før seneste remote logout. Hvis der har været et remote logout efter tidspunktet i den cookie der blev modtaget er den ikke længere gyldig.

Så er der spørgsmålet omkring det skjulte form felt jeg nævnte tidligere. Det kan sagtens gemmes i samme HMAC beskyttede cookie. Så skal serveren blot verificere at HMAC er gyldig, time stamp er gyldig, og form og HMAC begge indeholder samme hemmelige værdi.

Den anden fuldstændigt anderledes multilogin feature som er værd at overveje er at nogle gange er det praktisk at kunne logge ind som to brugere fra samme browser. Hvis du gør det er du nødt til at placere en oplysning i URLen som kan afgøre hvilket login en side er knyttet til.

En feature som denne er der ikke mange sites der har, men den eksisterer f.eks. i gmail. Dog kan man se at i gmail betyder den feature at bookmarks til specifikke emails ikke længere virker pålideligt fordi rækkefølgen på logins ikke nødvendigvis er den samme hver gang man bruger linket.

Man kunne vælge at sætte brugernavnet i URLen, hvilket ville få bookmarks til at virke, men ville lække oplysninger om brugernavn når man browsede ud fra sitet til andre sites.

Hvis du vil implementere en feature som denne er du nødt til at have flere samtidige session cookies. Det kunne du f.eks. gøre ved at lægge brugernavnet i cookienavnet.

Det største problem ved denne type features er at det hele bliver lidt kompliceret og derfor betyder en risiko for sikkerhedshuller. Og det kan da heller ikke udelukkes at jeg har glemt en vigtig detalje i ovenstående beskrivelse.

Et library med en gennemført implementation af alle ovenstående features ville være en smart ting. Men jeg ved ikke om det findes.