[PHP>=4.2] Sessie variabelen vervalsen

[Verwijderd]

Hallo,

Ik vroeg mij af of het mogelijk is om vanuit een webbrowser (als gebruiker dus) PHP sessie-variabelen te manipuleren. Zoals bij velen is mijn authenticatie afhankelijk van de waarden van bepaalde sessie-variabelen (username en password). Indien iemand deze weet te veranderen is dat natuurlijk niet zo mooi...

Alvast dank voor antwoord,

t

[justmental]

kan niet

[Sendy]

Sessie variabelen kan je niet zomaar wijzigen. Wat je wel kan doen is proberen andere variabelen te wijzigen (bijvoorbeeld POST- of GET variabelen) en zo het gedrag van de server te veranderen. Als de php slecht geschreven is zou dat misschien kunnen. Als je de source hebt is zoiets veel makkelijker.

Ik zou zeggen: probeer eens iets, misschien wordt je een echte cracker

[CyberSnooP]

De abosulte waarde van je sessie-variabelen ligt vast in een file op de server. Slechts een verwijzing naar die file met een uniek id (sessie-id) is datgeen wat de user daar vanaf weet.

Het gokken van andermans sessie-id is meestal ontzettend lastig en daarmee wordt het kapen van sessies praktisch onmogelijk. Als je zin hebt kun je natuurlijk nog een extra sleutel toevoegen in je sessie en als cookie, maar dat is in het algemeen overbodig.

Als je echter scripts hebt waarin je de waarde van een session-variabele rechtstreeks af laat hangen van gebruikers-invoer zoals GET en POST variabelen dan wordt het een ander verhaal. Echter altijd geldt het controleren van de gebruikersinvoer vooraf moet gaan aan het gebruik ervan.

[Verwijderd]

ik heb al wat zitten rondspelen met het vervalsen van sessie variabelen, maar is me nog niet gelukt... goed om te weten echter, maakt het geheel wat waterdichter
aangezien ik op elke memberpage een sql-query uitvoer die zowel de username sessie-variabele als de password-variabele nodig heeft zou het nog geen probleem zijn als iemand bv. de username sessie-variabele zou weten te vervalsen: de query zou alsnog geen resultaat opleveren en daardoor een loginpagina teruggeven. dit terzijde
overigens indrukwekkend hoe snel er gereageerd wordt...!

[Verwijderd]

zie dat mijn andere post is afgesloten, maar m.i. een ander aspect van php-sessies, dus een andere thread waard, maar goed. wat ik me eveneens afvroeg was of het toevoegen van PIDs absoluut noodzakelijk is om een sessie te handhaven. uit ervaring weet ik dat de PID achterwege laten geen probleem oplevert, maar misschien zie ik wat veiligheidsaspecten over het hoofd waar ik me niet van bewust ben...

t

[MikeN]

Je kan alleen een sessie kapen, dus een complete sessie overnemen. Je moet hiervoor wel exact het juiste session ID raden, en als je ook nog een beveilliging op Useragent/IP inbouwt is dit erg lastig te doen.

[CyberSnooP]

Verwijderd schreef op 08 December 2002 @ 20:56:
ik heb al wat zitten rondspelen met het vervalsen van sessie variabelen, maar is me nog niet gelukt... goed om te weten echter, maakt het geheel wat waterdichter
aangezien ik op elke memberpage een sql-query uitvoer die zowel de username sessie-variabele als de password-variabele nodig heeft.

Weet je, met de kennis dat die gegevens altijd veilig zijn, wel zeker dat je beide gegevens nodig hebt en die query persee iedere keer moet uitvoeren?

Ookal heeft je site het misschien niet nodig, het is altijd verstandig over performance na te denken.. dus ook hier: Hoe minder queries hoe beter.

overigens indrukwekkend hoe snel er gereageerd wordt...!

Ook verrassend dat nog niemand je welkom geheten heeft en je gewezen heeft op het bestaan van een alghele FAQ waarin staat dat begroetingen onder een post niet echt op prijs gesteld worden (al zullen we niet boos worden)

[Verwijderd]

mijn excuses voor de begroeting dan... blijkbaar worden beleefdheden niet op prijs gesteld? vreemd... maar goed, je wijst terecht op performance. de reden dat ik de authenticatie elke keer doe is in wezen gebaseerd op onzekerheid over de veiligheid van sessies plus legacy (werkte in een héél ver verleden met niet-versleutelde cookies...). zal er eens over na denken, alhoewel performance niet erg hoog op de prioriteitenlijst staat (systeem voor intern gebruik).

[CyberSnooP]

Verwijderd schreef op 08 december 2002 @ 21:10:
mijn excuses voor de begroeting dan... blijkbaar worden beleefdheden niet op prijs gesteld?

offtopic:
Eigenlijk moet ik hier niet op ingaan, ik weet 't... maar toch:
Hoe liever je bent hoe beter Dus opzich is er met beleefdheid helemaal niks mis. Maar als je wilt dat wij zoveel mogelijk vragen kunnen beantwoorden is het net zo makkelijk om die begroeting weg te laten, de FAQ verteld je dan ook:

Wij tweakers doen elkaar permanent de groeten. Het is dus niet nodig om steeds ruimteverspillende "greetz [user]" of iets dergelijks onder je posts te plakken. Als je per se zoiets wilt kun je daar je signature voor gebruiken.

[Verwijderd]

[aangaande afsluiting van nieuw topic]
wat ik wel had kunnen doen is een subject kunnen ingeven, maar had al op post gedrukt...
dit is duidelijk een ander onderwerp dat over een specifiek probleem met sessies gaat. dit staat los van het andere onderwerp dat over sessies in zijn algemeenheid gaat. ik neem aan dat inhoud topics van elkaar onderscheidt, niet opportunisme?

[originele post]
Nou ja, als ik toch al vanalles aan het posten ben over PHP-sessies kan deze er misschien ook wel bij, een klein probleem met mijn login-script.
Om er zeker van te zijn dat ik niet per ongeluk een rondslingerende sessie gebruik wil ik een session_destroy() doen voordat ik een nieuwe sessie aanmaak. Ik krijg echter elke keer "Constant sid already defined" na het session_register() commando.
Mijn eerste drie regels zien er zo uit:

session_start();
session_unset(); // Deactivate the session variables
session_destroy(); // Delete sessionfiles on server => causes troubles... (why?)

Iemand een idee?

t

[stekkel]

Is het niet zo dat je in principe access hebt tot de directory waar de sessies zijn opgeslagen. (php file based session system)

Uiteraard kan dat alleen als je instaat bent om een script op de betreffende server te draaien.

Dit betekend dus dat het mogelijk is om alle openstaande sessie bestanden te bekijken en indien hier username en password instaan dan is je beveiliging gereduceerd tot bijna 0.

passwords moet je dan ook NOOIT unencrypted in de sessie opslaan.

[ Voor 12% gewijzigd door stekkel op 09-12-2002 15:07 ]