[PHP.ini] Session behouden verschillende domeinnamen

[Verwijderd]

Hallo, ik heb een website en die draait op meerder domeinnamen, bijvoorbeeld:
www.domeinnaam.nl (nederlands)
www.domeinnaam.co.uk (engels)
www.domeinnaam.de (duits)

Als ik inlog wil ik kunnen wisselen tussen domeinnamen waarop mijn website draait, om bijvoorbeeld tussen talen te wisselen.

Nu had ik al eens iets ingesteld om tussen subdomeinen te wisselen, echter wil ik nu verschillende domeinnamen gebruiken.

Ik weet niet of ik iets kan instellen als:
session.cookie_domain = .domeinnaam.
Mischien dat dit werkt, of is dat heel dom?

Dit zijn mijn huidige instellingen in php.ini:

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain = .domeinnaam.com

; Check HTTP Referer to invalidate externally stored URLs containing ids.
session.referer_check = .domeinnaam.com

Iemand een goede suggestie voor mij?

[djluc]

Je kan toch geen cookie setten voor een ander domein? Wellicht kan je doorsturen naar een speciale pagina, bijvoorbeeld:

Je bent bij NL en klikt op EN:
1. ga naar domein.nl/move.php?id=en
2. save een code op de server
3. redirect naar domein.com/acceptmove.php?code=je code
4. maak een nieuwe login aan met cookie

Uiteraard moet je dit goed op veiligheid checken!

[Gwaihir]

Verwijderd schreef op donderdag 24 mei 2007 @ 15:37:
Ik weet niet of ik iets kan instellen als:
session.cookie_domain = .domeinnaam.
Mischien dat dit werkt, of is dat heel dom?

Dat werkt niet. Je kunt dat wel leuk instellen, maar de browsers doen er niet aan mee.

Het makkelijkst is waarschijnlijk het tijdens die wisselingen via de URL meegeven van het sessie-id.

Aangezien je bij dezelfde server met dezelfde folder met sessies uitkomt hoef je daar op de server niets bijzonders voor op te slaan. Wel moet je die referer_check laten vallen (geeft toch weinig veiligheid) en op een andere manier session hijacking tegengaan.

[ Voor 23% gewijzigd door Gwaihir op 24-05-2007 20:25 ]

[Verwijderd]

Dit lijkt me niet mogelijk, de sessie code wordt normaal doorgegeven via een cookie en cookies zijn domeinspecifiek.

Dit los je normaal op door de sessie tijdelijk in de database op te slaan, een code daaruit aan de gebruiker te geven die je vervolgens via de URL of via POST meegeeft aan het andere domein zodat je de sessie daar kunt herstellen.

[Verwijderd]

Verwijderd schreef op donderdag 24 mei 2007 @ 20:30:
Dit lijkt me niet mogelijk, de sessie code wordt normaal doorgegeven via een cookie en cookies zijn domeinspecifiek.

Dit los je normaal op door de sessie tijdelijk in de database op te slaan, een code daaruit aan de gebruiker te geven die je vervolgens via de URL of via POST meegeeft aan het andere domein zodat je de sessie daar kunt herstellen.

Dat laatste bedoelt hij waarschijnlijk ook, maar vooral GET (de url ) is zeer vatbaar voor session hijacking.

[Tomsworld]

Werken met een derde .eu domein en de andere domeinen naar binnen redirecten ?

domein.nl -> nl.domein.eu
domein.de -> de .domein.eu

Zo zit je voor je sessies en cookies op 1 main domein ?

[djluc]

Nu had ik al eens iets ingesteld om tussen subdomeinen te wisselen, echter wil ik nu verschillende domeinnamen gebruiken.

Lijkt me dus niet dat hij naar 1 domein toe wil.

[Verwijderd]

Bedenk even wat het begrip "domein" eigenlijk betekent.

quote: http://www.vandale.nl/opzoeken/woordenboek/?zoekwoord=domein

do·mein (het ~, ~en)
1 gebied waarin iem. het voor het zeggen heeft => machtsgebied
2 geestelijk gebied => terrein
3 een groep computers in een netwerk met een gezamenlijk adres, bv. een e-mailadres
4 domeinnaam

Kijk dan met name naar de eerste betekenis. Impliciet staat er dat je het dus niet voor het zeggen hebt buiten je domein.

Aangezien domeinnamen op geen enkele manier aan elkaar gekoppeld kunnen worden op de manier die je wilt, is het dus niet mogelijk om "onder water" een sessie te laten voortduren. Het zal via de client moeten, en dat betekent een mogelijk beveiligingsrisico, afhankelijk van wat je bezoekers op je site moeten kunnen doen.

En toch is het mogelijk. Je zult de client moeten laten doorverbinden naar het nieuwe domein, vervolgens de client op het oude domein een pagina laten opvragen met een of andere unieke token, waarbij je controleert of het ip adres nog wel hetzelfde is. Op de pagina met het oude domein stuur je dan weer op basis van de oude cookie een token naar de server, waardoor de server weet welke twee "sessies" bij elkaar horen, en kun je de gegevens laten overdragen. Daarna kun je eventueel de oude vernietigen, want de gegevens zijn overgestuurd.

Voorbeeld:
1 De client heeft een sessie via domein 1, met een of andere unieke, niet te raden private token.
2 De client wordt gestuurd naar domein 2 (of dat dezelfde server is maakt niet uit, als ze dan maar onderling kunnen communiceren.
3 De server start een sessie, en genereert een geheime en een publieke token.
4 De client wordt gestuurd naar domein 1, met de publieke token in de url.
5 De client moet bijvoorbeeld zijn private token XOR encoden met de publieke token, en doet een request naar domein 1 met in de cookie zijn private token en in de URL de XOR encoded private token.
6 De server ontvangt de gegevens, kan de boel decoden met de private token van de client, en kan dan de gegevens uit de sessie van domein 1 doorgeven aan de sessie van domein 2.
7 De client wordt weer naar domein 2 gestuurd.

Er zijn geen hoogwaardige encryptietechnieken vereist. Het belangrijkste is dat er nooit private tokens in de request URI terecht komen.

Dit kun je eventueel doen via een XMLHttpRequest.

[ Voor 27% gewijzigd door Verwijderd op 24-05-2007 21:44 ]

[Verwijderd]

Verwijderd schreef op donderdag 24 mei 2007 @ 20:48:
[...]

Dat laatste bedoelt hij waarschijnlijk ook, maar vooral GET (de url ) is zeer vatbaar voor session hijacking.

Mwah, dat boeit niets.

Je bent hoe dan ook kwetsbaar voor session hijacking dus je zal er altijd iets tegen moeten doen, of je nu een beetje kwetsbaar bent of heel erg kwetsbaar.

[Gwaihir]

Verwijderd schreef op donderdag 24 mei 2007 @ 20:30:
Dit lijkt me niet mogelijk, de sessie code wordt normaal doorgegeven via een cookie en cookies zijn domeinspecifiek.

"Normaal", als in "dat ben je zo gewend", maar je kunt de sessie-id ook (tijdelijk) via de URL doorgeven. Je gebruikt dan nog altijd rechtstreeks PHP's ingebouwde sessie mechaniek en dat maakt dit stuk van jouw oplossing overbodig:

Dit los je normaal op door de sessie tijdelijk in de database op te slaan, een code daaruit aan de gebruiker te geven die je vervolgens via de URL of via POST meegeeft aan het andere domein zodat je de sessie daar kunt herstellen.

Verwijderd schreef op donderdag 24 mei 2007 @ 20:48:
maar vooral GET (de url ) is zeer vatbaar voor session hijacking.

Klopt, daarom gebruik je normaal gesproken liever cookies. Maar ja, dat gaat hier nu juist effe niet..


Overigens.. voor alle cookie fans: denken jullie er wel aan voor de session_start() session.use_only_cookies te zetten? Staat dat uit, dan worden sessie-IDs uit de URL gewoon geaccepteerd (al zijn ze uiteraard nog wel moeilijker te achterhalen zo lang je ze niet op die manier uitgeeft).

[Verwijderd]

Birdie schreef op vrijdag 25 mei 2007 @ 10:45:
[...]

"Normaal", als in "dat ben je zo gewend", maar je kunt de sessie-id ook (tijdelijk) via de URL doorgeven. Je gebruikt dan nog altijd rechtstreeks PHP's ingebouwde sessie mechaniek en dat maakt dit stuk van jouw oplossing overbodig:

Nee, normaal als in zo wordt het gedaan tenzij je het anders wilt hebben.
Normaal als in default

Klopt, daarom gebruik je normaal gesproken liever cookies. Maar ja, dat gaat hier nu juist effe niet..

Zoals gezegd, dat boeit niets. Je bent altijd kwetsbaar voor session hijacking dus je moet altijd maatregelen treffen. In dit geval helpt die security through obscurity dus helemaal niets.

Overigens.. voor alle cookie fans: denken jullie er wel aan voor de session_start() session.use_only_cookies te zetten? Staat dat uit, dan worden sessie-IDs uit de URL gewoon geaccepteerd (al zijn ze uiteraard nog wel moeilijker te achterhalen zo lang je ze niet op die manier uitgeeft).

Je kunt PHP's eigen sessie id's niet gebruiken omdat deze domeinsgebonden zijn en bij een juist geconfigureerde server hebben andere domeinen (dus andere users) niet eens toegang tot de sessie bestanden van een ander domein.

Je zult dus even zelf een systeempje moeten maken, iets wat echt erg eenvoudig is dus niet echt nuttig om naar andere omslachtige oplossingen te zoeken.

Je kunt de gehele session array gewoon serialized in de database opslaan, voeg daar even het IP adres van de gebruiker aan toe en een random uniek code (bijvoorbeeld uit de random pool van het OS) dan ben je al een heel eind klaar en veilig.

[FREAKJAM]

Heb je hier iets aan? Of hier misschien.. En aan deze heb je denk ik het meeste..

google is your friend

[ Voor 91% gewijzigd door FREAKJAM op 25-05-2007 12:39 ]

[Verwijderd]

FREAKJAM schreef op vrijdag 25 mei 2007 @ 12:27:
Heb je hier iets aan? Of hier misschien.. En aan deze heb je denk ik het meeste..

google is your friend

In plaats van te verwijzen naar Google, zou je ook in kunnen gaan op mijn post. Ik zeg natuurlijk niet voor niets dat je de private token (bijvoorbeeld de session id) niet in de URL moet transferren naar het 2e domein. De 3e link is redelijk goed, de andere 2 had je net zo goed weg kunnen laten.

Dit is overigens niet echt een "standaard" probleem. Ik denk niet dat je zoiets moet willen, maar áls je het wilt, zul je het wel zorgvuldig moeten aanpakken. Het is heel eenvoudig om op te lossen, iets lastiger om het ook goed op te lossen. En juist daarvoor is P&W wat mij betreft. Google is niet altjd voldoende.

[FREAKJAM]

Verwijderd schreef op vrijdag 25 mei 2007 @ 13:35:
[...]

In plaats van te verwijzen naar Google, zou je ook in kunnen gaan op mijn post. Ik zeg natuurlijk niet voor niets dat je de private token (bijvoorbeeld de session id) niet in de URL moet transferren naar het 2e domein. De 3e link is redelijk goed, de andere 2 had je net zo goed weg kunnen laten.

Dit is overigens niet echt een "standaard" probleem. Ik denk niet dat je zoiets moet willen, maar áls je het wilt, zul je het wel zorgvuldig moeten aanpakken. Het is heel eenvoudig om op te lossen, iets lastiger om het ook goed op te lossen. En juist daarvoor is P&W wat mij betreft. Google is niet altjd voldoende.

zie dat ik mijn post had ge-edit..vond link 3 pas later, maar misschien bevatte link 1 en 2 ook interresante informatie.. sorry for stepping on your toes!

[Janoz]

Verwijderd schreef op vrijdag 25 mei 2007 @ 12:24:
Je kunt PHP's eigen sessie id's niet gebruiken omdat deze domeinsgebonden zijn en bij een juist geconfigureerde server hebben andere domeinen (dus andere users) niet eens toegang tot de sessie bestanden van een ander domein.

De sessies van php worden op geen enkele manier aan het domein gebonden. Andere domeinen zijn namelijk niet per definitie andere users op de server. Je kunt rustig zo configureren dat meerdere domeinen naar exact dezelfde website wijzen. De enige 'domein' beperking die je in dat geval hebt is dat de browser de cookies van het andere domein niet meestuurt.

Een link van het ene domein naar het andere domein met de sessionid aan de url en waarbij bij het nieuwe domein weer een cookie wordt gezet id genoeg om de sessie mee te nemen. Eventueel maak je een speciale cookie sync feature waarbij je via een aantal pagina's en clientside redirect snel voor alle sites een cookie kunt zetten.

[Verwijderd]

Ik ga hier mee aan de slag, iedereen bedankt voor de suggesties