Archief - PHP: Sessions

0n3Liner · 11 jul 2005

Ik denk hier zo stil in mijn hoofd...
sessions...hoe beveilig ik deze tegen hijacking...

ik heb al rondgekeken naar oplossingen, maar het blijft hetzelfde, er zijn wel oplossingen, maar meestal zijn deze of niet 100% waterdicht of vormen ze een probleem voor meer dan 2% van de bezoekers. En ik heb liever problemen voor 0% van de bezoekers.

Het handigste zou natuurlijk zijn als er iemand hier met een kant en klare functie zou afkomen (hahahaha!) maar ik ben tevreden met een simpele hint of wat uitleg.

DarkBone · 11 jul 2005

Door het gebruik van SSL kunnen session ID's niet onderschept worden

0n3Liner · 11 jul 2005

jaja, en iets numbnut vriendelijk misschien?

killgore · 11 jul 2005

secure sockets layers, ofwel op de server zelf in te stellen, of als je wilt coden in php: openssl:

http://be.php.net/openssl

andere trucs: zoveel mogelijk clientdata opslaan (alles van hardware & software versions dat je kan opvragen bv., kan al zeer effectief zijn vs hijack).

edit: ik kan niet echt onmiddelijke oplossing geven vo sessions & ssl daar ek ssl zelf nog maar effe in php "ontdekt" heb

.

[DZM]TheOne · 11 jul 2005

heeft iemand dergelijke duidelijke info ontdekt voor asp?

0n3Liner · 11 jul 2005

killgore zei:
secure sockets layers, ofwel op de server zelf in te stellen, of als je wilt coden in php: openssl:

http://be.php.net/openssl

andere trucs: zoveel mogelijk clientdata opslaan (alles van hardware & software versions dat je kan opvragen bv., kan al zeer effectief zijn vs hijack).

edit: ik kan niet echt onmiddelijke oplossing geven vo sessions & ssl daar ek ssl zelf nog maar effe in php "ontdekt" heb .

ben ik eigenlijk nog niets mee, want dan moet ik al de gebruikers van mijn cms al verplichten tot installeren van die extensie

killgore · 11 jul 2005

0n3Liner zei:
ben ik eigenlijk nog niets mee, want dan moet ik al de gebruikers van mijn cms al verplichten tot installeren van die extensie

dan zou ik oude trucs gebruiken, zoals ik bv. vanboven al heb gepost:

-client info opslaan (ip, browser, eventuele hardware, ...)
-cookie-db id: je maakt buiten je sessie een cookie aan met een bepaald id in, ook in je sessie steek je een (ANDER) id (liefst ook tot. anders gegenereerd, gebruik je voor het 1 time, gebruik dan voor et ander microseconde of zo). in je db heb je table die de 2 id's linkt. komen de id's overeen: alles in orde

. Enige nadeel: user MOET cookies enabled hebben.

0n3Liner · 11 jul 2005

cookies mogen ze nu toch wel hebben aanstaan zeker

dJeez · 11 jul 2005

0n3Liner zei:
ben ik eigenlijk nog niets mee, want dan moet ik al de gebruikers van mijn cms al verplichten tot installeren van die extensie

SSL is niet apart te installeren, ELKE recente browser heeft SSL/TLS support ingebakken.

Het enige wat jij hoeft te doen is het SSL certificaat installeren op de server (jaarlijks te hernieuwen), en de bezoekers moeten dat certificaat enkel accepteren (ofwel eenmalig, ofwel steeds opnieuw). Een self-signed certificaat kan eventueel ook, maar dan moet de gebruiker dat toevoegen aan z'n root certificates om de popup te vermijden bij elk bezoek.

SSL op zich levert trouwens totaal geen oplossing voor session hijacking. En er bestaat geen 100% waterdicht systeem, je kan enkel het risico beperken (vb. via one-time password authentication of iets dergelijks).

killgore · 11 jul 2005

dJeez zei:
SSL is niet apart te installeren, ELKE recente browser heeft SSL/TLS support ingebakken.

Het enige wat jij hoeft te doen is het SSL certificaat installeren op de server (jaarlijks te hernieuwen), en de bezoekers moeten dat certificaat enkel accepteren (ofwel eenmalig, ofwel steeds opnieuw). Een self-signed certificaat kan eventueel ook, maar dan moet de gebruiker dat toevoegen aan z'n root certificates om de popup te vermijden bij elk bezoek.

SSL op zich levert trouwens totaal geen oplossing voor session hijacking. En er bestaat geen 100% waterdicht systeem, je kan enkel het risico beperken (vb. via one-time password authentication of iets dergelijks).

hij bedoelt de serverside openssl extension die bij php zit

. hij wilt blijkbaar een cms voor publiek doel maken

.

DarkBone · 11 jul 2005

dJeez zei:
SSL op zich levert trouwens totaal geen oplossing voor session hijacking. En er bestaat geen 100% waterdicht systeem, je kan enkel het risico beperken (vb. via one-time password authentication of iets dergelijks).

Kunt ge dat wa meer uitleggen? Ik had hier en daar gelezen dat dat net wel een oplossing was omdat alles dan geëncrypteerd wordt?

*edit*
Ok, ge kunt er niet mee tegengaan dat men URL's doorgeeft met de session id, maar TCP session hijacking wordt wel tegengegaan toch?
Of wordt de url nooit geëncrypteerd doorgegeven?

dJeez · 11 jul 2005

killgore zei:
hij bedoelt de serverside openssl extension die bij php zit . hij wilt blijkbaar een cms voor publiek doel maken .

Waarom brengt hij dan zijn gebruikers die een extensie zouden moeten installeren ten berde?

WHiSPy · 11 jul 2005

http://en.wikipedia.org/wiki/Challenge-response_authentication

0n3Liner · 11 jul 2005

dJeez zei:
Waarom brengt hij dan zijn gebruikers die een extensie zouden moeten installeren ten berde?

waarschijnlijk verkeerd gelezen ofzo, ik dacht dat dit niet standaard in een php installatie zat...

killgore · 12 jul 2005

dJeez zei:
Waarom brengt hij dan zijn gebruikers die een extensie zouden moeten installeren ten berde?

de webdevs die gebruik maken van zijn cms???

Impuls · 12 jul 2005

Dit kan je op iedere pagina "includen" zodat indien ze rechtstreeks naar subpagina's surfen er toch een controle is :

<?php
session_name(sessie);
session_start();
header("Cache-control: private"); // IE 6 Fix.

if (count($HTTP_SESSION_VARS) <= 0)
{session_unset();
session_destroy();
echo ("<script language='Javascript'>window.location='./alert.php?type=6';</script>");
}

?>

WHiSPy · 12 jul 2005

Impuls zei:
Dit kan je op iedere pagina "includen" zodat indien ze rechtstreeks naar subpagina's surfen er toch een controle is :

<?php
session_name(sessie);
session_start();
header("Cache-control: private"); // IE 6 Fix.

if (count($HTTP_SESSION_VARS) <= 0)
{session_unset();
session_destroy();
echo ("<script language='Javascript'>window.location='./alert.php?type=6';</script>");
}

?>

Dan is het challenge-response principe toch veel effectiever, hoor.

killgore · 12 jul 2005

Impuls zei:
Dit kan je op iedere pagina "includen" zodat indien ze rechtstreeks naar subpagina's surfen er toch een controle is :

<?php
session_name(sessie);
session_start();
header("Cache-control: private"); // IE 6 Fix.

if (count($HTTP_SESSION_VARS) <= 0)
{session_unset();
session_destroy();
echo ("<script language='Javascript'>window.location='./alert.php?type=6';</script>");
}

?>

1) oude code
2) slechte code
3) imho niet zo effectief

dJeez · 12 jul 2005

killgore zei:
de webdevs die gebruik maken van zijn cms???

Een CMS consulteer je doorgaans wel via een browser, er is dus niks extra te installeren dus in dat geval (buiten eventueel het self-signed certificaat zoals aangehaald, maar zelfs dat is geen vereiste als je met die popup kan leven

).

Impuls · 13 jul 2005

killgore zei:
1) oude code
2) slechte code
3) imho niet zo effectief

Ok ik ben een totale php noob...dus ik ben fier op mezelf dat dit al werkt.

Doch....challenge-respons....explain please !

Merci
Impuls

Archief - PHP: Sessions

0n3Liner

Legacy Member

DarkBone

Legacy Member

0n3Liner

Legacy Member

killgore

Legacy Member

[DZM]TheOne

Legacy Member

0n3Liner

Legacy Member

killgore

Legacy Member

0n3Liner

Legacy Member

dJeez

Legacy Member

killgore

Legacy Member

DarkBone

Legacy Member

dJeez

Legacy Member

WHiSPy

Legacy Member

0n3Liner

Legacy Member

killgore

Legacy Member

Impuls

Legacy Member

WHiSPy

Legacy Member

killgore

Legacy Member

dJeez

Legacy Member

Impuls

Legacy Member