[PHP/SSL]session variabele gebruiken in combinatie met ssl*

[Arcane Apex]

Wij hebben een deel van onze site in een speciale ssl directory ondergebracht. Alle bestanden welke via SSL verzonden moeten worden zitten in die directory. Alle bestanden welke geen SSL benodigen zitten buiten die directory.

Nou is het volgende probleem ontstaan.
Wanneer iemand inlogt dan wordt via een server-side sessie een variabele overgeheveld naar bestanden die die sessievariabele nodig hebben om de pagina op een bepaalde manier te displayen. i.e. wanneer de status is dat iemand niet ingelogd is moet een bepaalde pagina op een bepaalde manier getoond worden en wanneer iemand ingelogd is dan moet die pagina op een andere manier getoond worden.
Echter de sessie variabele kan door de niet-SSL bestanden niet ontvangen worden vanuit een bestand dat in de SSL directory zit.
Ons hele systeem is hierdoor gebroken en we kunnen niet alles in de SSL directory doen zodat de sessie daarbinnen wel werkt. (de sessie variabelen beperken zich tot de SSL dir vanwege SSL, daarbuiten zijn ze niet toegankelijk en dat is ons probleem)

We hebben een manier nodig om die variabelen als nog over te hevelen van SSL enabled files naar non-SSL enabled files.

Heeft iemand enig idee hoe je dit kan doen?

[Verwijderd]

session_set_cookie_params

Zie de secure parameter. Deze zou moeten bepalen of de session cookie ook over HTTP mag. Verder moet uiteraard ook de path overeenkomen. Een cookie set je dan ook bij voorkeur voor /

[Creepy]

offtopic:
Psst: *** Over topictitels in PRG - lezen voor topic openen!!! ***

[ Voor 61% gewijzigd door Creepy op 12-05-2008 18:21 ]

[martijnve]

Verwijderd schreef op maandag 12 mei 2008 @ 18:02:
session_set_cookie_params

Zie de secure parameter. Deze zou moeten bepalen of de session cookie ook over HTTP mag. Verder moet uiteraard ook de path overeenkomen. Een cookie set je dan ook bij voorkeur voor /

Als ik de comments onder het artikel lees werkt dit pas vanaf firefox3 en in safari werkt het nog helemaal niet omdat het een microsoft "uitvinding" is die pas sinds kort door andere browsers is overgenomen.

Dus dit is de komende tijd nog geen oplossing.

[ Voor 3% gewijzigd door martijnve op 12-05-2008 18:29 ]

[Verwijderd]

Volgens mij lees je helemaal niet, dus moet je het verder maar zelf uitzoeken.

[Verwijderd]

offtopic:
rofl

Jammer dat je niet doorhebt dat php server-sided werkt Veel succes.

[Arcane Apex]

Ik weet wel degelijk dat PHP op de serverside werkt, echter voorkomt het gebruik van SSL dat een serverside session variabele overgehevelt kan worden van een bestand welke over https verstuurd wordt naar een bestand dat over http verstuurd wordt. Dit is een serverside probleem.
We hebben wel een oplossing gevonden door de session identifier over te hevelen, maar dit brengt beveiligingsissues met zich mee.
We hebben een veilige oplossing nodig.

@Cheatah: Hebben die parameters alleen betrekking op client-side cookies of ook op server side sessions?

[ Voor 10% gewijzigd door Arcane Apex op 12-05-2008 19:12 ]

[Arcane Apex]

PS: Sorry voor het topic titel, ik heb de titel niet afgemaakt voordat ik op verstuur bericht klikte.
Misschien kan een moderator deze veranderen naar: "[PHP/SSL] Server-side session variabele gebruiken in combinatie met SSL."

[ Voor 38% gewijzigd door Arcane Apex op 12-05-2008 19:23 ]

[djiwie]

Arcane Apex schreef op maandag 12 mei 2008 @ 19:09:
We hebben een veilige oplossing nodig.

De enige veilige oplossing is alles met SSL versleutelen (dus alles in je ssl-mapje). Anders kan iemand alsnog je sessie hijacken.

[Verwijderd]

djiwie schreef op maandag 12 mei 2008 @ 19:28:

De enige veilige oplossing is alles met SSL versleutelen (dus alles in je ssl-mapje). Anders kan iemand alsnog je sessie hijacken.

SSL biedt geen enkele extra veiligheid voor de client betreft bijvoorbeeld XSS, afgezien van dat het verkeer geencrypt wordt, en het feit dat de client kan bepalen of de server is wie hij zegt dat hij is (maar dat wordt haast nooit gecontroleerd). Die ene flag voor cookies is of ze wel of niet verstuurd mogen worden over een onbeveiligde verbinding. Voor fatsoenlijke security biedt dit bijna geen meerwaarde, want je moet sowieso geen gevoelige informatie op de client opslaan. En de mogelijkheid om "secure" cookies te setten zit er volgens mij al haast vanaf het begin van Netscape's cookies in.

[BCC]

Arcane Apex schreef op maandag 12 mei 2008 @ 19:09:
We hebben een veilige oplossing nodig.

Het klinkt alsof je een veiligheidslek ranzig wil oplossen. Wat wil je precies bereiken? Wat is het probleem dat je wil oplossen?

Volgens mij wil je secure downloading voor geautoriseerde gebruikers (ingelogd met session). Daar zijn heel veel andere oplossingen voor, zoals het aanmaken van een download ticket.

[ Voor 24% gewijzigd door BCC op 12-05-2008 19:57 ]

[Arcane Apex]

BCC schreef op maandag 12 mei 2008 @ 19:37:
[...]

Het klinkt alsof je een veiligheidslek ranzig wil oplossen. Wat wil je precies bereiken? Wat is het probleem dat je wil oplossen?

Volgens mij wil je secure downloading voor geautoriseerde gebruikers (ingelogd met session). Daar zijn heel veel andere oplossingen voor, zoals het aanmaken van een download ticket.

Zoals het er op het moment voorstaat is de site niet goed bruikbaar voor onze gebruikers. Ik heb liever dat het opgelost wordt, dan dat de site onbruikbaar is. Een hack welke het oplost is misschien niet elegant, maar dan kunnen onze gebruikers de site tenminste weer gebruiken, al is het maar tijdelijk tot we een betere oplossing hebben.
We willen geen secure downloading. We willen een server-side session variabele overhevelen van een SSL gedeelte van de site naar een niet-SSL gedeelte.

[ Voor 10% gewijzigd door Arcane Apex op 12-05-2008 20:58 ]

[BCC]

Eeh, tja.. los het dan gelijk goed op zodat het in de toekomst veilig en bruikbaar blijft. Ducktape oplossingen kosten later alleen maar meer tijd.

We willen geen secure downloading. We willen een server-side session variabele overhevelen van een SSL gedeelte van de site naar een niet-SSL gedeelte.

Ja, dat snap ik. Zit het SSL gedeelte op een ander domein (oftewel, zit je achter een gedeeld SSL certificaat van je hoster?). Zo ja, dan gaat het zowieso niet werken. Dan zul je de variabelen die je nodig hebt moeten pasen via de query string.

Een echt ranzige oplossing kan als je een verschillend domein hebt, die fysiek door dezelfde server afgehandeld worden, dan kun je in de query string het sessie ID meegeven en die dan weer opstarten bij je HTTPS domein, dus zoiets:

Link naar SSL part:

https://secure.jehost.nl/...name/transfer.php?sid=<?= session_id(); ?>

Met in transfer.php:

session_id($_GET['sid']);
session_start();

Als je hoster maar enige vorm van redundantie gebruikt gaat dit waarschijnlijk hard mis. Nogmaals: dit is echt een hele ranzige workaround. Koop ZSM een eigen certificaat.

[ Voor 98% gewijzigd door BCC op 12-05-2008 21:20 ]

[Arcane Apex]

Alles staat op hetzelfde domein waar we tevens al een certificaat voor hebben.

[BCC]

Dan begrijp ik je probleem niet.

[Voutloos]

Arcane Apex schreef op maandag 12 mei 2008 @ 17:57:
...
de sessie variabelen beperken zich tot de SSL dir vanwege SSL, daarbuiten zijn ze niet toegankelijk en dat is ons probleem
...
We hebben een manier nodig om die variabelen als nog over te hevelen van SSL enabled files naar non-SSL enabled files.

Geef eens een concreet voorbeeld, want imo klink je nu als een manager die totaal niet wat het echte probleem is.

[MueR]

Arcane Apex schreef op maandag 12 mei 2008 @ 20:56:
We willen geen secure downloading. We willen een server-side session variabele overhevelen van een SSL gedeelte van de site naar een niet-SSL gedeelte.

Dus je wil data opslaan om die op een andere site (even SSL/non-SSL als aparte sites beschouwd) te gebruiken? Neem een database.

[AndriesLouw]

Lees nu session-set-cookie-params eens een keer goed door! Dat verhaal over Firefox 3 en Safari is alleen van toepassing op de httponly parameter, eentje waar je helemaal niks mee nodig hebt!

De eerste reactie (van Cheatah) is in mijn ogen gewoon de oplossing voor je probleem..

[BCC]

Als het pad overeenkomt dan moet dat idd gewoon werken.

[djiwie]

Verwijderd schreef op maandag 12 mei 2008 @ 19:36:
[...]

SSL biedt geen enkele extra veiligheid voor de client betreft bijvoorbeeld XSS,

Dat beweer ik ook niet.

afgezien van dat het verkeer geencrypt wordt,

Waarmee je in ieder geval MITM attacks en session hijacking deels mee voorkomt. Ik schreef niet dat je er met SSL bent, maar als je een veilige oplossing wilt zul je _in ieder geval_ SSL moeten gebruiken, IMHO.

[bigbeng]

Wij hebben een soortgelijk probleem (in ons geval een website die uit Java en DotNet stukken bestaat, waarvan de 1 in tomcat draait en de ander in IIS) opgelost door een sessie transfer meganisme te bouwen. Het komt er op neer dat je bij de overgang (in ons geval van Java naar .Net, in jouw geval van http naar https) de sessie serialiseert naar een datastore (wij gebruikten een database, maar via het filesystem kan natuurlijk ook), een unieke code erbij genereert die je in de redirect aan de client meegeeft. Deze code kan aan de https kant van de pijp weer gebruikt worden om de sessie te deserializen (en de datastore te legen).

Er zitten wel wat haken en ogen aan dit mechanisme, zowel qua security als qua serialization issues, maar mogelijk is dit toch een oplossing

[djiwie]

Ik zie niet in waarom je een dergelijk omslachtig mechanisme wilt gebruiken voor dit probleem. Als ik zo de reacties van TS lees staat alles op een server en is het enige probleem dat de sessies gemaakt onder HTTPS niet worden geinitialiseerd onder HTTP. Dit kan verschillende oorzaken hebben, maar daar zijn ook al verschillende oplossingen voor gegeven in dit topic.

[bigbeng]

djiwie schreef op woensdag 14 mei 2008 @ 13:48:
Ik zie niet in waarom je een dergelijk omslachtig mechanisme wilt gebruiken voor dit probleem. Als ik zo de reacties van TS lees staat alles op een server en is het enige probleem dat de sessies gemaakt onder HTTPS niet worden geinitialiseerd onder HTTP. Dit kan verschillende oorzaken hebben, maar daar zijn ook al verschillende oplossingen voor gegeven in dit topic.

Een reden die ik zou kunnen bedenken is dat het browser onafhankelijk is, maar goed als de oplossing voor de TS tussen de bovengenoemde replies staat, dan kan hij neem ik aan ook zonder jouw hulp mijn geboden oplossing wel negeren

[Verwijderd]

djiwie schreef op woensdag 14 mei 2008 @ 10:14:

Waarmee je in ieder geval MITM attacks en session hijacking deels mee voorkomt.

In theorie. In praktijk kan ik gerust een willekeurig SSL certificaat aanschaffen bij een "trusted" CA, en dan alsnog een MITM attack uitvoeren. Mensen kijken meestal niet waarmee ze verbonden zijn. Een gele adresbalk is "voldoende". Er wordt in praktijk nog te weinig gebruik gemaakt van OCSP, het is nog geen common knowlegde dat een SSL certificaat nog iets anders is dan een EV SSL certificaat.

Ik schreef niet dat je er met SSL bent, maar als je een veilige oplossing wilt zul je _in ieder geval_ SSL moeten gebruiken, IMHO.

Als bank of overheid hoor je minimaal een EV certificaat te hebben. Een gewoon SSL certificaat is op zich wel voldoende voor bijvoorbeeld webshops en dergelijke. Voor systemen waar met vertrouwelijke informatie wordt gewerkt, hoort in elk geval een goed beveiligingsplan te worden gemaakt. Een SSL certificaat is daarbij niet eens het belangrijkst. Dat is de slagroom op de taart.

[djiwie]

bigbeng schreef op woensdag 14 mei 2008 @ 14:18:
[...]

Een reden die ik zou kunnen bedenken is dat het browser onafhankelijk is, maar goed als de oplossing voor de TS tussen de bovengenoemde replies staat, dan kan hij neem ik aan ook zonder jouw hulp mijn geboden oplossing wel negeren

Zijn cookies dan zo browserafhankelijk?