[java] locatie inhoud sessie/session highjacking.

[Alarmnummer]

Waar wordt de inhoud van een session opgeslagen? Ik neem aan dat er gebruik gemaakt wordt van een object die de server nooit verlaat maar die word geidentificeerd aan de hand van een key die in de clientcookie wordt opgeslagen. Op die manier verlaat de kritieke info nooit de server en heeft de client niet de mogelijkheid om valse info naar de server te sturen. (En verder heb je niets te maken met alle serialisatie/deseralisatie problematiek)

Maar hoe zit het dan met session highjacking? Wie belet een client om een andere key terug te sturen (misschien een op de gok) en dan krijgt hij aan de server kant iemand anders zijn session toegewezen.

Hoe is dit afgehandeld? Het lijkt mij dat er ook een of andere unieke key, bv de client zijn ip, meegegeven moet worden door de client. De server kan dan checken of degene die de session heeft aangemaakt ook dezelfde is als degene die de session wil opvragen.

Ik heb eigelijk geen duidelijk antwoord gevonden op mijn vraag.. dus ik hoop dat er hier iemand is die me dit kan uitleggen.

[ Voor 6% gewijzigd door Alarmnummer op 01-12-2004 19:20 ]

[Verwijderd]

Sessie data wordt inderdaad op de server opgeslagen. Het stelen van een sessie id is voldoende om een sessie over te nemen. Je kan zoals je zelf al aangeeft een sessie id koppelen aan een
bepaald ip-adres. Wanneer ip-adres en sessie id niet matchen dan kan je ervoor kiezen om de gebruiker automatisch uit te loggen.
Het concept zit goed in je hoofd. Volgens mij zie je niets over het hoofd. Of zoek je een gedetailleerde uitleg over het te volgen protocol?

[Alarmnummer]

Verwijderd schreef op woensdag 01 december 2004 @ 19:23:
Het concept zit goed in je hoofd. Volgens mij zie je niets over het hoofd. Of zoek je een gedetailleerde uitleg over het te volgen protocol?

Hmm.. ik kan zelf wel een oplossing bedenken Maar ik had eigelijk gehoopt dat iedere applicatie server dit al voor mij doet, zodat ik mij kan concentreren op de zaken die werkelijk interessant zijn.

[Verwijderd]

Kijk, je wilt absoluut zeker weten dat degene met wie je denkt te maken te hebben, ook daadwerkelijk diegene is. IP adres binden aan sessie id is daar geschikt voor, maar niet iedereen heeft een static IP adres, waardoor het dus lastig wordt dit automatisch te regelen. Ik denk dat je zelf een abstractie layer moet schrijven die dit hele probleem voor je oplost achter de schermen, zodat je je daar later nooit meer zorgen om hoeft te maken.

[Alarmnummer]

Verwijderd schreef op woensdag 01 december 2004 @ 19:29:
Kijk, je wilt absoluut zeker weten dat degene met wie je denkt te maken te hebben, ook daadwerkelijk diegene is. IP adres binden aan sessie id is daar geschikt voor, maar niet iedereen heeft een static IP adres, waardoor het dus lastig wordt dit automatisch te regelen.

Ik mag toch wel hopen dat een IP adres van een client wel constant is zo lang hij online is. Of hoeft dit niet zo te zijn?

Ik denk dat je zelf een abstractie layer moet schrijven die dit hele probleem voor je oplost achter de schermen, zodat je je daar later nooit meer zorgen om hoeft te maken.

Hmmm tja.. ik had eigelijk gehoopt dat iedere zichzelf respecterende applicatieserver dit automatisch heeft gedaan.

[Verwijderd]

Je hebt best proxy servers waarbij je bij elke request een ander ip adres krijgt. Of waarbij meerdere gebruikers hetzelfde IP gebruiken. Niet voor niets moet je hier op GoT zelf aanvinken of je de sessie aan je IP wil binden.

[ACM]

Alarmnummer schreef op woensdag 01 december 2004 @ 19:31:
Ik mag toch wel hopen dat een IP adres van een client wel constant is zo lang hij online is. Of hoeft dit niet zo te zijn?

Neehoor, die garantie is er helemaal niet. De kans is vrij groot, maar zowel het resetten van de verbinding (verlopen dhcp-lease kan er al de oorzaak van zijn) als domweg het gebruik van een clusterd-proxy (van je isp ofzo) kan ervoor zorgen dat het ip-adres niet bij de volgende request hetzelfde is.
Om die reden is de ip-aan-sessie koppeling bij GoT ook inschakelbaar, maar niet verplicht.

Hmmm tja.. ik had eigelijk gehoopt dat iedere zichzelf respecterende applicatieserver dit automatisch heeft gedaan.

Zie hierboven waarom die zichzelf respecterende ontwikkelaars niet een stel potentiele klanten voor het hoofd willen stoten...

[Verwijderd]

Verwijderd schreef op woensdag 01 december 2004 @ 19:29:
Kijk, je wilt absoluut zeker weten dat degene met wie je denkt te maken te hebben, ook daadwerkelijk diegene is. IP adres binden aan sessie id is daar geschikt voor, maar niet iedereen heeft een static IP adres, waardoor het dus lastig wordt dit automatisch te regelen. Ik denk dat je zelf een abstractie layer moet schrijven die dit hele probleem voor je oplost achter de schermen, zodat je je daar later nooit meer zorgen om hoeft te maken.

Het IP adres is niet zo geschikt. Zo zijn er zat organisaties met een router waardoor iedereen die via die organisatie inlogt hetzelfde IP krijgt en aan de andere kant kan iemand met een dynamic IP adres plotseling van IP adres veranderen.

Wil je veiligheid, neem dan gewoon SSL. Is SSL overkill, dan is het koppelen van het IP adres het eigenlijk ook

[Creepy]

"gewoon SSL"? Dat zorgt er alleen maar voor dat de verbinding niet zomaar gesnift kan worden. Dat helpt je echt niet qua veiligheid wat betreft wachtwoorden en sessies tenzij je client side SSL certificaten gaat gebruiken wat bijv voor een forum helemaal niet werkbaar is.

SSL is wat dat betreft een schijnveiligheid. Het helpt je echt niet met wachtwoorden of met sessie hijacking want de "hacker" aan de andere kant kan natuurlijk ook met SSL een connectie maken en alsnog een sessie proberen te kapen.

[Verwijderd]

Creepy schreef op woensdag 01 december 2004 @ 20:42:
"gewoon SSL"? Dat zorgt er alleen maar voor dat de verbinding niet zomaar gesnift kan worden. Dat helpt je echt niet qua veiligheid wat betreft wachtwoorden en sessies tenzij je client side SSL certificaten gaat gebruiken wat bijv voor een forum helemaal niet werkbaar is.

SSL is wat dat betreft een schijnveiligheid. Het helpt je echt niet met wachtwoorden of met sessie hijacking want de "hacker" aan de andere kant kan natuurlijk ook met SSL een connectie maken en alsnog een sessie proberen te kapen.

Sessie hijacking heeft zin om verbindingen tot stand te brengen zonder dat je de username of het password weet. Door een random sessie te hijacken kun je binnenkomen op de credentials van een ander. SSL is echter "niet" te hijacken. Wel kun je natuurlijk alsnog achter het password proberen te komen maar dat is een ander probleem dan het hijacken van een sessie.

[ACM]

Creepy schreef op woensdag 01 december 2004 @ 20:42:
"gewoon SSL"? Dat zorgt er alleen maar voor dat de verbinding niet zomaar gesnift kan worden. Dat helpt je echt niet qua veiligheid wat betreft wachtwoorden en sessies tenzij je client side SSL certificaten gaat gebruiken wat bijv voor een forum helemaal niet werkbaar is.

SSL is wat dat betreft een schijnveiligheid. Het helpt je echt niet met wachtwoorden of met sessie hijacking want de "hacker" aan de andere kant kan natuurlijk ook met SSL een connectie maken en alsnog een sessie proberen te kapen.

SSL is een veiligheidslaag over netwerkverbindingen. Ook evt over HTTPS. Bij mijn weten is het wel wat meer dan domweg enkel en alleen een "encryptiewrapper" rond HTTPS. Het biedt ook de garantie dat je met dezelfde client aan het praten bent als even te voren, voor zover ik weet. Dat uiteraard om man-in-the-middle attacks te voorkomen.
Sterker nog... SSL ligt ook ten grondslag aan SSH en daarvan claim je toch ook niet dat je dan ineens onveilig bezig bent, omdat het slechts telnet met een ssl-laagje is?

Je moet uiteraard dan wel alles met SSL communiceren, niet alleen de log-in pagina en vervolgens alle andere requests maar heen en weer laten gaan over een normaal kanaal. Dan is het inderdaad grotendeels schijnveiligheid.

[Verwijderd]

Leuke anekdote over SSL.

Twee jaar geleden vond ik het nog cool en spannend (ja erg triest) om bij grote bedrijven naar binnen te sneaken. Het bedrijf custompublish had een prachtig cms ontwikkeld. Login met SSL niet te kraken volgens hun.
Ik heb ze een aantal dagen bezig gehouden, toen bleek dat ik de wachtwoorden van al hun klanten die inlogden kon achterhalen. Ze dachten veel te ingewikkeld en snapten niet hoe iemand hun veilige SSL verbinding kon kraken. Aan het eind van het verhaal heb ik het ze verteld hoe de vork in de steel zat en ze vonden het prachtig hoe simpel het eigenlijk was. (kon relatief eenvoudig template variabelen aanpassen en zo custom html injecteren en de inlog gegevens naar mijn server doorsturen en vervolgens de loginprocedure weer voortzetten).

Hieruit blijkt maar weer dat SSL niet dé oplossing is. Een systeem is zo sterk als de zwakte schakel... Zoals Creepy al aangaf is SSL wat dat betreft vaak schijnveiligheid

[justmental]

Omdat je een stateless verbinding hebt zul je iets nodig hebben wat je client identificeert om een 'ingelogd' status te behouden.
Dat is meestal een sessie-id in een cookie.
Zolang het sessie-id lang genoeg is valt het niet te brute forcen.

SSL heeft geen toegevoegde waarde hierbij omdat je een bij een sessie-hijack het sessie-id verkrijgt en daarmee een nieuwe verbinding start, waarbij de server niet kan zien dat jij niet de orginele user bent.
Een IP check kan wel helpen, maar die moet zoals genoemd wel optioneel zijn.

[Creepy]

ACM schreef op woensdag 01 december 2004 @ 23:31:
[...]

SSL is een veiligheidslaag over netwerkverbindingen. Ook evt over HTTPS. Bij mijn weten is het wel wat meer dan domweg enkel en alleen een "encryptiewrapper" rond HTTPS. Het biedt ook de garantie dat je met dezelfde client aan het praten bent als even te voren, voor zover ik weet. Dat uiteraard om man-in-the-middle attacks te voorkomen.

Nee, dat zeg ik net (die client side SSL certificates). Zonder dit is session hijacking echter nog wel mogelijk. Net als dat de server een certificate heeft kan de client er ook 1 hebben. De server zal deze dan wel weer moeten herkennen. Zo weet de server of de client ook echt de client is welke hij zegt dat ie is. Maar zonder dit certificate wordt dat wat moeilijker.

SSL is domweg een laag bovenop de socket communicatie. Of je daar nu http, telnet, ftp, irc, of whatever overheen gooit maakt niet zo heel veel uit . Maar zoals het 9 van de 10 keer gebruikt wordt is het juist die standaard encryptie laag + server side certificate zodat je weet dat je met dezelfde server een connectie hebt als de vorige keer.

[ACM]

Goed, als je een sessie-id hebt weten te pakken, DAN is idd alleen een client-side certificaat nog mogelijk (of een ip-check). Anderzijds zou je ook de SSL-sessie-id op kunnen slaan en die controleren bij de normale sessie-key. Als die verschillen...
En je bent wel een heel knappe jongen als het voor elkaar krijgt om die SSL-session-id te faken en de verbinding nog werkend te krijgen ook.

Uiteraard is dat niet bruikbaar voor long-lived sessies.

Maar wat veel belangrijker is: dmv SSL is het niet (zo goed) meer mogelijk om via http-data-analyse de sessie-id te stelen.
En dan moet je uiteraard nog uitkijken dat er niet domweg cross-site-attacks mogelijk zijn, waardoor die hele SSL-laag idd niet zinvol meer is. Ik geloof wel dat een browser dan standaard wat moeilijker doet voor submits naar externe sites en dergelijke. (iedereen ramt toch op 'ok', dus dat boeit dan helaas weer niet).

[Creepy]

Dat SSL session id faken is inderdaad een behoorlijk moeilijke klus

Maar het feit dat SSL ook een session id heeft weten maar relatief weinig mensen die gebruik maken van SSL om een site beter te beveiligen. Om je site echt beter te beveiligen is een beetje kennis van SSL / HTTPS ook wel een vereiste. Het alleen aanschakelen van HTTPS bied je standaard dus alleen maar de encryptie

Overigens zul je met load balancers e.d. weer moeten uitkijken want als je bij je tweede request doorgestuurd wordt naar ean andere server dan krijg je van de server een nieuwe SSL session id en begint de gehele handshake weer opnieuw.

[TukkerTweaker]

Creepy schreef op donderdag 02 december 2004 @ 09:55:
Overigens zul je met load balancers e.d. weer moeten uitkijken want als je bij je tweede request doorgestuurd wordt naar ean andere server dan krijg je van de server een nieuwe SSL session id en begint de gehele handshake weer opnieuw.

Geldt memory session replication niet voor SSL dan?

[Verwijderd]

Creepy schreef op donderdag 02 december 2004 @ 09:55:
Dat SSL session id faken is inderdaad een behoorlijk moeilijke klus

Maar het feit dat SSL ook een session id heeft weten maar relatief weinig mensen die gebruik maken van SSL om een site beter te beveiligen. Om je site echt beter te beveiligen is een beetje kennis van SSL / HTTPS ook wel een vereiste. Het alleen aanschakelen van HTTPS bied je standaard dus alleen maar de encryptie

Overigens zul je met load balancers e.d. weer moeten uitkijken want als je bij je tweede request doorgestuurd wordt naar ean andere server dan krijg je van de server een nieuwe SSL session id en begint de gehele handshake weer opnieuw.

Is SSL niet altijd stateful?

[HYS]

Verwijderd schreef op woensdag 01 december 2004 @ 19:35:
Je hebt best proxy servers waarbij je bij elke request een ander ip adres krijgt. Of waarbij meerdere gebruikers hetzelfde IP gebruiken. Niet voor niets moet je hier op GoT zelf aanvinken of je de sessie aan je IP wil binden.

Ik zit zelf ook achter een proxy en dit geeft idd soms problemen, ergens anders (waarschijnlijk ook op dit forum) dat dit vaak met register_globals voorkomt. Ik heb zelf mbv. .htaccess register_globals uitgeschakeld.

[Creepy]

Verwijderd schreef op donderdag 02 december 2004 @ 14:33:
[...]

Is SSL niet altijd stateful?

Standaard niet als je dankzij de loadbalancer tijdens je tweede request met een andere server aan het kleppen bent

Tuurlijk zijn hier wel maatregelen voor te nemen, maar zover gaat m'n kennis van loadbalancers i.c.m. SSL niet.