Tags:
session
hijacking
sikkerhed
Har læst lidt om hvordan man forhindrer session hijacking. Mere specifikt 2 metoder.
Den ene er at regenerere session cookie efter hver (betydelig) request. Den anden er at bruge en såkaldt 'nonce'. Men jeg kan ikke helt forstå hvordan de skulle afhjælpe på problemet (forøge sikkerheden på nogen måde).
Hvis BadGuy har mulighed for at sniffe trafikken mellem GoodGuy og server kan han vel aflæse alt information mellem GoodGuy og serveren. Så første scenarie med regenerering:
1. GoodGuy har fået fat i en session id (sådan set ligemeget om det er cookie eller url).
2. BadGuy kan se samme response og har dermed også den session id og impersonate GoodGuy.
3. a: GoodGuy forbinder nu til serveren igen før BadGuy.
Serveren svarer med en ny session id til GoodGuy
BadGuy kan også se denne - Intet har ændret sig
3. b: BadGuy forbinder før GoodGuy.
Serveren svarer med en ny session id til BadGuy
BadGuy kan stadig forbinde, men GoodGuy har ikke den nye session id og bliver smidt ud til login (sandsynligvis)
Scenariet med en 'nonce' er sådan set det samme. I stedet for session id er det bare en nonce.
Er der noget jeg har overset? Hvordan forbedrer det på nogen måde sikkerheden?
4 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 10 karma
Hvis BadGuy sidder på en router mellem dig og målet, så er SSL (eller i hvert fald kryptering) den eneste løsning.
Men normalt er session hijacking noget du gør med cross site scripting eller lignende, og så kan du binde session og IP adresse sammen.
Så vil det kræve, at BadGuy kan spoofe din IP adresse, og det kan man ikke lave med TCP medmindre du sidder på samme IP adresse eller på et punkt mellem de to endpoints.
Som du siger, kan det muligvis ramme nogle mobile brugere, men det burde det ikke...jeg har selv kørt fra Nordjylland til København uden at miste min TCP forbindelse, og det ville jeg helt sikkert, hvis jeg havde skiftet IP undervejs.
Den metode, du nævner, forbedrer sådan set ikke sikkerheden, men det gør det muligt at opdage, at der er noget galt. Medmindre BadGuy sidder og kan sniffe dine data, for så kan han sikkert også modificere dem med et man in the middle angreb, og så kan han jo bare selv sende dit request videre med et gyldigt session id.
SSL er nok det bedste bud i dag.
Du kan f.eks. tilføje noget information om brugeren til din session. F.eks. gemme brugerens user-agent eller ip-adresse når man logger ind. Så kan du tjekke om den efterfølgende ændrer sig og så nægte adgang.
0
Tak for svaret.
Nogle webserver kan godt ændre lidt i hvad de sender som deres user-agent
i headeren. Det er heller ikke krævet at sende en header med User-Agent i HTTP protokollen. En ip kan ligeledes ændre sig per requests (tror det kan påvirke mobilbrugere meget?).
Men mit spørgsmål var ikke hvilke andre metoder man kunne bruge, men hvordan de 2 metoder jeg har nævnt kan give nogen reel forøgelse i sikkerhed overhovedet. Det var faktisk på grund af begrænsningen i at bruge User-Agent og IP at nogle anbefalede regenerate id og en nonce.
0