[php] Dynamic sessionid

[RSD]

Ik opper een idee om een site te beveiligen aan de hand van dynamic session id's. Nu heb ik niet echt uitgelegd wat ik hiermee bedoel. Dat zal ik dus nu doen.

Als je eenmaal bent ingelogd. Kun je op verschillende sites komen. Bij elke klik die je naar een andere site doet, worden de variabelen en het sessionid meegegeven. Het sessionid verandert en de variabelen worden weer geregged. Nu kun je denken ja maar wat maakt dat nu uit. Als je eenmaal een sessionid van iemand weet kun je als nog inloggen. Maar dan denk ik, is het dan niet moeilijker om een sessionid te gaan gokken of een sessionid te kapen, omdat hij steeds verandert en je dus minder kans hebt. Mij lijkt het van wel namelijk, maar mijn redenatie kan natuurlijk fout zijn.

Graag zou ik hier wat reacties op willen. Tevens dacht ik dat dit misschien weer een extra stukje veiligheid zou kunnen zijn.

Tevens zou ik wel eens willen weten, hoe dat sessie kapen nu te werk gaat. Moeten ze dan in je server inbreken of kan het gewoon via inet commando's of dmv bepaalde scripts, of moeten ze echt rootaccess hebben. In het stukje van ACM las ik dat ze je poorten gaan afluisteren. Maar hoe doen ze dat dan, zijn daar programmatjes voor? Nu wil ik het niet zelf gaan doen, maar alleen kijken wat er tegen te doen valt en watvoor soort mensen er toe in staat zijn. Dus kan elke stomem sul het, of moet je kennis erg grot zijn op bepaalde gebieden.

Tevens nog een vraagje die ik niet in de manual terug kon vinden. Als je je session_id aanpast. Maakt PHP op de server dan een nieuwe sessie aan, of overschrijft hij de oude. Dus dat jde server het gewoon bij 1 reord houdt, of maakt hij voor elk nieuw sessie id een nieuw record aan.

[Dennis]

Wie zijn 'ons drietjes'

[Dennis]

RSD:
Bij elke klik die je naar een andere site doet, worden de variabelen en het sessionid meegegeven. Het sessionid verandert en de variabelen worden weer geregged.

Hmz, heb je toch mis. Alleen bij relatieve URL's.

Tevens nog een vraagje die ik niet in de manual terug kon vinden. Als je je session_id aanpast. Maakt PHP op de server dan een nieuwe sessie aan, of overschrijft hij de oude. Dus dat jde server het gewoon bij 1 reord houdt, of maakt hij voor elk nieuw sessie id een nieuw record aan.

Nieuwe.

[RSD]

Die 3 die vroegen om mn vorige topic te sluiten. Maar goed, ik hoop dat het zo wat beter is.

[Dennis]

RSD:
Die 3 die vroegen om mn vorige topic te sluiten.

Ow, dan hoor ik er ook bij

[justmental]

[dominee Gremdaat modus]
Een spraakwaterval, kent u die uitdrukking?
[/dominee Gremdaat modus]

Zou je dit verhaal een beetje kunnen structureren en wat enters gebruiken?
Het is buitengewoon moeilijk leesbaar.

[D2k]

Op zaterdag 25 mei 2002 14:11 schreef RSD het volgende:
Dit is toch een discussie forum of zie ik het nou verkeerd.

nou wat jij doet is hierzo alleen maar vragen stellen en niet meedoen aan discussie/problemen van anderen. daar heb je ook al een mailtje over gehad.

Het lijkt wel of jullie met zn drietjes een pact vormen.

ik heb een vermoeden wie je met die drie bedoeld. Je moet maar eens op hun namen klikken en dan op je eigen naam. Waag het dus niet nog eens zoiets tezeggen. GoT kan niet zonder dat soort users (dus die andere 2 niet mezelf)

En als je eenmaal hebt gezegd. Wat je aan het maken bent of waar het voor is. Dan kun je helemaal geen steun meer verwachten van jullie, omdat jullie dan waarschijnlijk denken.. oo oo commercieel en hier gratis advies krijgen..

edit:
Of gaat jullie denk vermogen niet verder dan de standaard oplosmethodes

<- kon het niet laten.. want voelde me nogal lullig dat dat topic weer zo snel werd gesloten!

bla bla bla. Je hebt echt nog niet door hoe het hier werkt. Niemand hier in de devschuur interesseert het wat je met een oplossing doet en iedereen wil hier echt wel een oplossing geven. Maar er wordt wel van je verwacht dat je initiatief toont en je inleest in een onderwerp

Ik opper een idee om een site te beveiligen aan de hand van dynamic session id's. Nu heb ik niet echt uitgelegd wat ik hiermee bedoel. Dat zal ik dus nu doen.

k

Als je eenmaal bent ingelogd. Kun je op verschillende sites komen. Bij elke klik die je naar een andere site doet, worden de variabelen en het sessionid meegegeven. Het sessionid verandert en de variabelen worden weer geregged. Nu kun je denken ja maar wat maakt dat nu uit. Als je eenmaal een sessionid van iemand weet kun je als nog inloggen. Maar dan denk ik, is het dan niet moeilijker om een sessionid te gaan gokken of een sessionid te kapen, omdat hij steeds verandert en je dus minder kans hebt. Mij lijkt het van wel namelijk, maar mijn redenatie kan natuurlijk fout zijn. Graag zou ik hier wat reacties op willen. Tevens dacht ik dat dit misschien weer een extra stukje veiligheid zou kunnen zijn. Tevens zou ik wel eens willen weten, hoe dat sessie kapen nu te werk gaat. Moeten ze dan in je server inbreken of kan het gewoon via inet commando's of dmv bepaalde scripts, of moeten ze echt rootaccess hebben. In het stukje van ACM las ik dat ze je poorten gaan afluisteren. Maar hoe doen ze dat dan, zijn daar programmatjes voor? Nu wil ik het niet zelf gaan doen, maar alleen kijken wat er tegen te doen valt en watvoor soort mensen er toe in staat zijn. Dus kan elke stomem sul het, of moet je kennis erg grot zijn op bepaalde gebieden.

[D2k]

en ff het verzoek ontopic te reageren vanaf nu

[RSD]

Ja dat is dus de bedoeling van de nieuwe beveiliging, dat hij het session_id verandert. Nu hou je gedurende je sessie hetzelfde sessie-id, bij de meeste scripts dan, maar als je het nu zo maakt dat hij constant verandert als je weer naar een andere beveiligde pagina gaat. Zou dit voordelen hebben? Volgens mij wel, want dje hebt constant een ander id, je springt asl het ware door alle id's heen. Maar als bij elke nieuwe sessie id, de server een nieuwe sessie aanmaakt en je oude sessie id bewaart blijft, krijg je opeens veel onnutigge sessies op je server die openstaan, dit is ook niet wat je wilt volgens mij. Als jij dan zegt dat als je je sessie id verandert er een compleet nieuwe sessie wordt aangemaakt dan. Of heb ik dat 'nieuwe' nu verkeerd begrepen?

[ff offtopic]
ik heb geklikt op hun profiel, weinig bijzonders, er staat alleen het aantal posts per dag.

Ik probeer ook nieuwe idee-en in te brengen, alleen werd dat meteen de mond gesnoerd. En veel van de topics die hier draaien, kan ik geen waarde aan toevoegen, omdat ze al beantwoord zijn en soms omdat ik bijv weinig van C/C++ weet etc.. kan alleen een beetje php/mysql/html/xml en heel klein beetje Javascript
[/ff offtopic]

[Glimi]

Sessie hijacking:

Hoe hijack je een sessie Heel simpel je kunt twee dingen doen. Of je jat iemand z'n cookie, of je neemt z'n sessie_id over, stopt die in een cookie en send hem naar de website. Beide komen op het zelfde neer eigenlijk

Hoe kom je z'n sessie_id te weten dan HTTP pakketjes (wat je browser verstuurt dus) zijn nogal niet versleutelt. Iedereen die er een opvangt kan dus letterlijk lezen wat jij allemaal verstuurt naar die website en wat hij terugstuurt.

Hoe vang je dat op dan Nu komen we bij de werking van netwerken. Een HTTP pakketje wordt verzonden naar de webserver, maar hoe gaat ie daar naar toe? Da's ook al niet zo moeilijk.

Het pakketje verlaat jouw netwerk, op weg naar je ISP. Vanaf daar wordt ie naar het netwerk gestuurt waar de webserver in hangt. Hoe weet men dan waar ze je pakketje moeten opvangen? Dat weten ze niet! Daarom wordt het sniffen vaak ook intern in je eigen netwerk gedaan. Denk hierbij ook aan grote bedrijfsnetwerken en niet je eigen pruts netwerkje met 3 PC's oid.

Hoe gaat dat sniffen in z'n werk dan Da's gewoon een simpel programma'tje. Normaal geeft je netwerkkaart alleen verkeer door wat voor z'n IP bestemt is. Echter met dit programma'tje laat ie z'n IP los en komt ie in Promious Mode (zoiets iig). Dan gaat ie al het verkeer wat ie opvangt doorgeven naar het OS.

Kortom het heeft geen zin IMHO. Als iemand jouw sessie_id overneemt, dan zal namelijk jij of HIJ een nieuwe krijgen als hij veranderd. In dat geval heb je dus 50% kans dat de klant opeens uit de applicatie gedonderd wordt. Daar houden klanten niet van!!
En al krijgt de klant wel het nieuwe sessie_id, dan heeft de sniffer binnen een seconde of 20 dat zo weer te pakken.

En voor sniffen geldt, net als puzzels van MB, iedereen kan het!!

Ow gossie! WTF kan ik er tegen doen dan! SSL is het enige wat ik kan bedenken iig Dat houdt in dat je al het verkeer wat je verstuurt naar een webserver versleutelt. Dit is dan niet zomaar te lezen voor een meeluisteraart.
Echter de webserver die SSL draait moet wel een geldig SSL certificaat hebben. Dwz, zijn ssl geheime code moet getekend zijn door een door IE vertrouwd bedrijf (dat is Verisign oid). En dat kost echt vies veel geld.
Is het gewoon een simpel webservertje van jezelf? Dan kun je gewoon met mod_ssl voor apache (www.modssl.org) ssl in je apache webserver proppen. Echter de client die naar je webserver gaat, krijgt wel een dikke waarschuwing te zien dat je certificaat niet ondertekend is

Over dat veranderen van het sessie_id op de server en of ie dan een nieuwe sessie aanmaakt, weet ik niet. Probeer het even zou ik zeggen???

edit:
Of wacht volgens mij is dat wel te beredeneren. HTTP is stateless. Men weet niet wat de persoon ervoor gedaan heeft. Het is gewoon: de client vraagt, de server beantwoord.
Stel je zend nu een nieuwe sessie_id, die de client opslaat in een cookie en er een request mee doet. De server ziet dat nieuwe id en gaat daar mee verder (nieuwe sessie). Hij kan zich niet meer herinderen dat JIJ de gene was met de oude sessie.

NB: Mag ik wel even opgeven dat ik het niet zo aardig van je vindt dat je mij als iemand betitelt die 'in een pact zit', of je zwart probeert te maken oid. Ik heb toen een dik stuk getypt dat het gewoon niet zo werkt, en dat je argumenten moet geven (zoals ze nu gekomen zijn) en nu ben ik opeens 'een van de boemannen?'. Dat motiveert me niet echt om je te gaan helpen ......

Maar als je wilt klagen kan dat btw in [forum=15]...

[Dennis]

RSD:
ik heb geklikt op hun profiel, weinig bijzonders, er staat alleen het aantal posts per dag.

D2k bedoelde op namen klikken

[RSD]

ok, mijn excuses, thnx voor je uitleg, maakt het allemaal een stuk duidelijker, alleen dat port sniffen enzo vind ik een beetje vaag, maar het komt er dus op neer dat iedereen je sessionid kan faken

[D2k]

Op zaterdag 25 mei 2002 16:48 schreef RSD het volgende:
ok, mijn excuses, thnx voor je uitleg, maakt het allemaal een stuk duidelijker, alleen dat port sniffen enzo vind ik een beetje vaag, maar het komt er dus op neer dat iedereen je sessionid kan faken

daarom moet je voor een combinatie van gegevens gaan
dus userid+sessionid+nog wat dingen
maakt het faken al een stuk moeilijker

[RSD]

Ja maar je userid sla je allemaal op in een cookie of in een session. Allebei te faken naar blijkt:( Daarom zat ik ook aan een dynamic session_id te denken. Als ze hem dan gefaked hebben is dat id al niet meer geldig als de user alweer een pagina verder is zeg maar. Als dat niet zo is, dan kan het dus nog wel. Maar alweer een stukje verder

[Dennis]

RSD:
Ja maar je userid sla je allemaal op in een cookie of in een session. Allebei te faken naar blijkt:(

Waar heeft iemand gezegd dat je informatie in een sessie kunt faken

[RSD]

nou als je iemands session_id (script afhankelijk) weet kun je daar toch mee inloggen, als je geen cookies gebruikt althans. En dat id verkrijg je door aan iemands poorten te snuffelen

[Annie]

Maar als de sessie dynamisch is en B (van boef ) neemt de sessie over van A dan kan A wel proberen een andere pagina te benaderen (om zo zijn sessie te wijzigen), maar intussen kan de sessie-id al gewijzigd zijn door B en zal A dus niet meer toegelaten worden.
...
Ofzoiets

[RSD]

ja dat kan ook, maar het kan ook zijn dat B een sessie id aan het faken is en inmiddels heeft A alweer een ander sessie id(is naar andere pagina) en zo loopt B achter de feiten aan. Maar wat jij kan dat kan dus ook bij gewone sessies. Zo halveer je de kans dat iemand die aan het faken is de goede heeft volgens mij. Want je hebt een kans op Goede id of foute id voor B while faking. En zonder dynamic session id is de kans 1 dat hij goede id heeft, want het id wat hij te pakken krijgt is de juiste. Of redeneer ik nu erg krom?

[Sjaaky]

En wat gebeurd er als de client toevallig een session id misloopt?
Bijvoorbeeld ik zit op jouw pagina, druk op <ctrl-n> om een nieuw browser venster te openen, maar druk direct op <esc> om het laden te stoppen. Toevallig heeft jouw server al een request gehad en bouwt dus een nieuwe session-id in elkaar. Maar mijn browser heeft die niet gehad omdat ik op <esc> drukte. Dan kan ik in het oude venster niet meer verder browser omdat mijn session verlopen is.
Om dit te voorkomen kan je de laatste 2 of meer id's bijhouden, maar dan heeft kan een hacker met die id's ook weer binnenkomen. Er zullen met dynamic session-id's best wel leuke dingen mogelijk zijn, maar volgens mij is dat het niet waard.

[Dennis]

Besides zal het een ramp zijn om te proggen.
Een normale goede inlogprocedure is al niet makkelijk, laat staan zoiets

[Verwijderd]

Lijkt me duidelijk dat dynamische sessies dus ook averechts kunnen werken.
Misschien weet ik nog een betere oplossing: Als je nou aan een sessie-id ook het IP-adres van de gebruiker koppelt, dan is het sowieso moeilijker om iemands sessie te misbruiken. Je zorgt er gewoon voor dat zodra het ip-adres niet meer klopt, dat de sessie verwijdert wordt.

[Dennis]

Wazowski:
Lijkt me duidelijk dat dynamische sessies dus ook averechts kunnen werken.
Misschien weet ik nog een betere oplossing: Als je nou aan een sessie-id ook het IP-adres van de gebruiker koppelt, dan is het sowieso moeilijker om iemands sessie te misbruiken. Je zorgt er gewoon voor dat zodra het ip-adres niet meer klopt, dat de sessie verwijdert wordt.

Dit is idd het beste ja. Alleen moet je wel een optie geven, anders is het voor mensen met een modem zo lullig.

[RSD]

Maaruh dat van die IP is wel een goed idee. Als ze dus inloggen sla je ip op in database+sessionid. Vervolgens check je elke keer of dat ip bij dat sessionid hoort. Is dit niet het geval dan heb je pech. Maar hoezo hebben mensen met modems er last van? Die hebben toch ook gewoon een ip en die kun je ook opslaan en na zoveel tijd delete je die weer bijvoorbeeld.

offtopic:
Hoe wordt je lid van de 3?

[Dennis]

RSD:
Maaruh dat van die IP is wel een goed idee. Als ze dus inloggen sla je ip op in database+sessionid. Vervolgens check je elke keer of dat ip bij dat sessionid hoort. Is dit niet het geval dan heb je pech. Maar hoezo hebben mensen met modems er last van? Die hebben toch ook gewoon een ip en die kun je ook opslaan en na zoveel tijd delete je die weer bijvoorbeeld.

Een modem heeft een variabel IP elke keer als je inbelt. Dus na een keer opnieuw inloggen moet je sowiezo opnieuw inbellen, want je IP is dan anders.

offtopic:
Hoe wordt je lid van de 3?

Niet, gisteren zei jij in dit topic dat ik vast bij 'die drie' hoor, dus ik, D2k en Glimi. Dus vandaar

[RSD]

Ja ok, maar dan heb je ook het probleem met proxy servers en dergelijke. Je kan toch als iemand inlogt zijn ip vast stellen. Vervolgens sla je dit IP op in de database samen met je sessionid. Als je nu naar een andere page gaat, check je elke keer of het ip adres klopt bij het sessionid. Zo niet dan heeft iemand je sessie gehijacked. Er wel van uitgaande dat ze elke keer als ze op de inlogpagina komen. Ze opnieuw moeten inloggen. Dus zonder cookies. Dus als ze een dag later komen, dat ze dan weer opnieuw moeten inloggen.

[Dennis]

Zonder cookies. Oké .

Ik vraag me trouwens wel af waarom je het IP op wilt slaan in de database terwijl dat ook prima in de sessie kan. Kun je dat uitleggen

[RSD]

ja het zou ook in de sessie kunnen, scheelt weer een tabel