[PHP] Vreemde text in de sessie

[EnsconcE]

Al een tijdje draai ik een website die een sessie per gebruiker registreerd. Deze gebruik ik voor het registreren van elke bezoeker, apart van de unieke bezoeker. Nou staat er het volgende in mijn database waar normaliter het sessie id staat:

code:

temperature
Content-Transfer-En

code:

[e-mail]

code:

[e-mail]

code:

an
Content-Type: multipart/alte

Waar domein staat, is het domein van de website gebruikt. Regulier ziet een sessie id in mijn database er als volgt uit:

code:

b0db4cdefda50dc476d7765223163983

om de sessie in de dbase te krijgen doe ik eerst session_start() en vervolgens declareer ik een variabele door middel van session_id().

Diegene in mijn database heeft ook als eerst een reguliere sessie gekregen, maar daarna heeft hij of zij de sessie aangepast. Nou ben ik er al achter dat het ip adres van een spammer is en is er gelukkig geen spam in het gastenboek of email terecht gekomen. De website is zo gemaakt dat er niet makkelijk gespammed kan worden(confirm voor het gastenboek).

Mijn vragen zijn:
weet iemand misschien hoe diegene dat voor elkaar gekregen heeft? en kan het kwaad?

[TeeDee]

Misschien een vorm van MIME / Headers injection.

[MaTriCX]

Ik heb soortgelijke data in mijn tabellen staan, die worden geregistreerd bij het invullen van een contactformulier.
Ik ga er vanuit dat het een soort bot of harvester. Mijns inziens kan het geen kwaad maar moet eerlijk zeggen dat ik ook wel benieuwd ben.

@Bo-oz:
Nee ik dacht ook van niet, maar wie weet door het doorgeven van vreemde client-data (door middel van headers), kan het zijn dat de server deze fout afhandeld. Maar dan zit de fout inderdaad aan de serverkant.
Mijn probleem is inderdaad de MIME-injection, die verholpen kan worden door de \n en \r te filteren uit elk inputfield in een formulier.

[ Voor 41% gewijzigd door MaTriCX op 21-11-2006 13:54 ]

[Verwijderd]

@Matricx --> Lijkt me niet dat die bots sessievariabelen in de database moet kunnen wijzigen... er zal toch wel ergens een beveiligingslek zitten. Als ze immers deze kunnen aanpassen, lijkt het me dat het aanpassen van andere tabellen ook mogelijk is.

[EnsconcE]

MaTriCX schreef op dinsdag 21 november 2006 @ 13:45:
Ik heb soortgelijke data in mijn tabellen staan, die worden geregistreerd bij het invullen van een contactformulier.
Ik ga er vanuit dat het een soort bot of harvester. Mijns inziens kan het geen kwaad maar moet eerlijk zeggen dat ik ook wel benieuwd ben.

Ik vermoed dat het wel kwaad kan als

code:

temperature
Content-Transfer-En

en

code:

an
Content-Type: multipart/alte

op de verkeerde plekken terechtkomen. Ik bedoel, stel dat deze text wel volledig in de sessie staat, maar neit in de dbase(dat is de enige die het afkapt op 32 karakters). En het wordt uitgevoerd door je code, je roept de sessie variabele aan, dan kan het 1 en ander misgaan lijkt me.

Dit brengt me direct op het idee om de sessie variabele altijd af te kappen op 32 karakters.

@Bo-oz
Vermoedelijk worden de sessie variabelen aangepast en niet de dbase. Mijn dbase registreert de sessie.

[ Voor 6% gewijzigd door EnsconcE op 21-11-2006 13:50 ]

[Grijze Vos]

Euhm, session_id() gebruik je om het id van de sessie te setten voordat je deze start, niet om session variabelen te setten.

[Janoz]

@Bo-oz: Sessie variabelen zijn inderdaad niet te veranderen. De sessieId is echter hetgeen bij de client opgeslagen staat. Wanneer de gebruiker hier zelf iets voor meestuurt (zelf een cookie meestuurd of een get parameter met SESSIONID) dan neemt php die id over. Door brakke headers, gegenereerde cookies en meegegeven get parameters is elke mogelijke sessionId te zetten (daarop is ook session hijacking gebaseerd) en als php die sessie neit kent maakt hij er 1 met dat sessionId.

[EnsconcE]

Grijze Vos schreef op dinsdag 21 november 2006 @ 15:30:
Euhm, session_id() gebruik je om het id van de sessie te setten voordat je deze start, niet om session variabelen te setten.

Dit is wat ik bedoel:

PHP:

session_start(); 

$sessieID = session_id();

@Janoz
Begrijp ik het dan ook goed dat alles wat met session_register() geregistreerd wordt terug te vinden is bij de client?

Mijn $sessieID wordt alleen gebruikt voor de database, dan lijkt het me dat het geen kwaad kan omdat de variabele gedeclareerd wordt en vervolgens wordt alleen de declaratie vergeleken en evt opgeslagen. Wanneer kan het gebruik van brakke headers wel kwaad?

[Raynman]

EnsconcE schreef op dinsdag 21 november 2006 @ 17:25:
Begrijp ik het dan ook goed dat alles wat met session_register() geregistreerd wordt terug te vinden is bij de client?

Nee, dat is het hele idee van sessies: inhoud opslaan op de server, alleen het ID zo meegeven (achter links plakken, in cookie zetten) dat je de client bij een volgende request weer kunt herkennen.
session_register() is trouwens nogal ouderwets, je kunt gewoon elementen aan $_SESSION toevoegen.

Mijn $sessieID wordt alleen gebruikt voor de database, dan lijkt het me dat het geen kwaad kan omdat de variabele gedeclareerd wordt en vervolgens wordt alleen de declaratie vergeleken en evt opgeslagen. Wanneer kan het gebruik van brakke headers wel kwaad?

Bij een mailform bijvoorbeeld (reeds genoemde MIME-injection).

[B-Man]

EnsconcE schreef op dinsdag 21 november 2006 @ 17:25:
Mijn $sessieID wordt alleen gebruikt voor de database, dan lijkt het me dat het geen kwaad kan omdat de variabele gedeclareerd wordt en vervolgens wordt alleen de declaratie vergeleken en evt opgeslagen. Wanneer kan het gebruik van brakke headers wel kwaad?

Dit zijn headers/data die spammers gebruiken voor mailform injection. Ze proberen hiermee op allerhande manieren spam te verzenden via scripts op andermans server. Kijk hier eens voor meer info daarover.

Ik heb overigens nog niet eerder gezien dat ze hiervoor de session header / ID proberen te misbruiken.

[EnsconcE]

B-Man schreef op dinsdag 21 november 2006 @ 17:39:
[...]

Dit zijn headers/data die spammers gebruiken voor mailform injection. Ze proberen hiermee op allerhande manieren spam te verzenden via scripts op andermans server. Kijk hier eens voor meer info daarover.

Ik heb overigens nog niet eerder gezien dat ze hiervoor de session header / ID proberen te misbruiken.

Ok die begrijp ik, maar nou het sessie verhaal. Hoe wil zo'n spammer nu een mime type declareren in de sessie, om vervolgens de mail aan te roepen. Als ik naar mijn situatie kijk dan heeft hij geprobeerd een header te zetten in de sessie, maar die moet alsnog wel gemailed worden. Of had hij gehoopt dat dat met een email meegestuurd werd?

Raynman schreef op dinsdag 21 november 2006 @ 17:36:
[...]
Nee, dat is het hele idee van sessies: inhoud opslaan op de server, alleen het ID zo meegeven (achter links plakken, in cookie zetten) dat je de client bij een volgende request weer kunt herkennen.
session_register() is trouwens nogal ouderwets, je kunt gewoon elementen aan $_SESSION toevoegen.


[...]
Bij een mailform bijvoorbeeld (reeds genoemde MIME-injection).

session_register() gebruik ik niet, het was even ter voobeeld. session_id() daarentegen wel en dat heeft te maken met het direct weer ophalen van het id. Als je namelijk $_SESSION gebruikt dan krijg je die niet direct terug met IE en daardoor registreer je minder bezoekers(ik geloof dat het met IE te maken had, maar het vindt zijn oorsprong in het niet terug krijgen van die id).

Wat ik overigens nog steeds niet begrijp, hoe kan iemand mijn session_id() overrulen? die wordt namelijk elke refresh aangeroepen. Of kijkt session_start() alleen of er een PHPSESSION cookie aanwezig is en boeit de inhoud in dat opzicht niet?

[ Voor 40% gewijzigd door EnsconcE op 21-11-2006 19:34 ]