[Uitdaging] Checken op ingelogd zijn

[Rob]

Stel je hebt 2 domein. Laten we als voorbeeld eenvoorbeeld.com en tweakers.net gebruiken.
Je logt in op tweakers.net en surft verder, op een gegeven moment kom je op eenvoorbeeld.com. eenvoorbeeld.com herkent jou als ingelogd zijnde op tweakers.net.

Op eenvoorbeeld.com mag je alles uithalen om dit werkend te krijgen. Je mag ook op tweakers.net alles doen om dit tot werkend te krijgen. Wat mag niet: een centrale server (het zijn fysiek 2 servers) of servers die via allerlei vage protocollen met elkaar praten.

Nu de grote vraag: kan dit?
Cookies werken niet in dit geval.

[sig69]

Tuurlijk kan dit, zeker als je "alles mag uithalen".
VPN tussen de 2 server bijvoorbeeld, via welke elkaars status uitgelezen wordt etc. etc.

[sdomburg]

De enige manier waarop tweakers.net ziet dat je ingelogt bent is doormiddel van een cookie. ALs je zegt dat cookies niet werken, is het topic bij voorbaat al gedoemd.

Verder trek ik m'n twijfels bij dit topic en de bedoelingen van de TS.

[edit]
Oh, als je op 2 willekeurige sites van alles mag doen is het simpel http://www.eerstesite/login.php?user=naam%20pass=pass, tweede site leest dit uit de referral.

[ Voor 29% gewijzigd door sdomburg op 22-04-2004 15:39 ]

[ripexx]

Kort en krachtig zover ik kan na gaan niet. Aangezien cookies niet mogen werken en het verschillende servers zijn, daarnaast is cummunicatie tussen servers uitgesloten. Dus niet echt mogelijk, ten zij je een form laat posten naar de andere server, dit kan wel met javascript/html dan zou het kunnen maar anders niet.

[Michali]

ripexx schreef op 22 april 2004 @ 15:39:
Kort en krachtig zover ik kan na gaan niet. Aangezien cookies niet mogen werken en het verschillende servers zijn, daarnaast is cummunicatie tussen servers uitgesloten. Dus niet echt mogelijk, ten zij je een form laat posten naar de andere server, dit kan wel met javascript/html dan zou het kunnen maar anders niet.

Een beetje script checked de referer van de post. Lijkt me dat dat dan ook niet door gaat.

[Jelmer]

Als tweakers naar eenvoorbeeld linkt, moeten ze achter de request een token zetten.
eenvoorbeeld.com gebruikt dit token om bij tweakers de gegevens van de gebruiker te controleren.

op tweakers: <a href="http://www.eenvoorbeeld.com/index.html?token=tw5232347sdfs3htr82q3g4s84t9st4j">

eenvoorbeeld.com vraagt via ssl
https://www.tweakers.net/verifytoken.php?token=tw54...st4j
op en geeft de gebruikersnaam terug.

Vereist is dus dat tweakers dit token in de database opslaat. Zoek eens een casus over passport.com van microsoft/msn, die doen het ook zo.

[ Voor 35% gewijzigd door Jelmer op 22-04-2004 15:45 ]

[BraveWorld]

Of als de sessions in een database worden opgeslagen en je hebt wederzijds toegang tot de databases (dus remote connections toegestaan, en je hebt de beschikking over de wachtwoorden) dan kan je het gewoon met een query opvragen. Toch?

[Rob]

- Tuurlijk kan dit, zeker als je "alles mag uithalen". VPN tussen de 2 server bijvoorbeeld, via welke elkaars status uitgelezen wordt etc. etc.

Dit valt onder mijn: "vage" protocollen

- De enige manier waarop tweakers.net ziet dat je ingelogt bent is doormiddel van een cookie. ALs je zegt dat cookies niet werken, is het topic bij voorbaat al gedoemd.

Cookies mogen wel gebruikt worden, maar cookies zet je op domeinnamen. Als ik dus een cookie zet op tweakers.net dan kan eenvoorbeeld.com deze niet lezen.

- Dus niet echt mogelijk, ten zij je een form laat posten naar de andere server, dit kan wel met javascript/html dan zou het kunnen maar anders niet.

In mijn verhaals surf je wat rond en kom je al surfend via via op de andere server.

- Of als de sessions in een database worden opgeslagen en je hebt wederzijds toegang tot de databases (dus remote connections toegestaan, en je hebt de beschikking over de wachtwoorden) dan kan je het gewoon met een query opvragen. Toch?

Ze mogen niet dezelfde server gebruiken.


Ik heb zelf al een oplossing gevonden die volgens mij goed werkt.
Een iframe..... of zie ik hier wat over het hoofd?

[Voutloos]

Stel: Het zijn 2 domeinen, beiden hebben al een userbase en deze users wisten eerst nog niet dat alles gekoppeld ging worden.

Maw: Noem nou maar 2 concrete voorbeelden, licht toe waarom het 2 servers/domeinen zijn en waarom protocollen onderling niet kunnen.

[sig69]

-Rob- schreef op 22 april 2004 @ 16:00:
- Tuurlijk kan dit, zeker als je "alles mag uithalen". VPN tussen de 2 server bijvoorbeeld, via welke elkaars status uitgelezen wordt etc. etc.

Dit valt onder mijn: "vage" protocollen

Ok, als je dit al "vage protocollen" vindt wordt het iets lastiger ja.

[Rob]

Voutloos schreef op 22 april 2004 @ 16:04:
Stel: Het zijn 2 domeinen, beiden hebben al een userbase en deze users wisten eerst nog niet dat alles gekoppeld ging worden.

Maw: Noem nou maar 2 concrete voorbeelden, licht toe waarom het 2 servers/domeinen zijn en waarom protocollen onderling niet kunnen.

Het is een niet bestaande situatie. Ik probeer te achterhalen hoe veilig het een en ander kan zijn.

[seweso]

Via een iframe is toch ook een vaag protocol....

[sdomburg]

seweso schreef op 22 april 2004 @ 16:06:
Via een iframe is toch ook een vaag protocol....

Sinds wanneer is een iFrame een protocol?

[seweso]

sdomburg schreef op 22 april 2004 @ 16:09:
[...]

Sinds wanneer is een iFrame een protocol?

Als je een iframe gebruikt om gegevens over te sturen (van server1 naar server2 via de client). Dat is toch een vaag protocol...toch?

Als iemand op zijn/haar server deze url in een iframe stopt: http://test.seweso.com/cookieinframe.php

Dan komen we er snel achter of dat uberhaupt kan.

* seweso is wel nieuwsgierig

[djluc]

Het http protocol lijkt me in deze context echt niet een vaag protocol
Ik zie bij je link mijn sessionid, ip en nog wat nummers. Wat betekenen die laatste nummers?

[seweso]

djluc schreef op 22 april 2004 @ 16:22:
Het http protocol lijkt me in deze context echt niet een vaag protocol
Ik zie bij je link mijn sessionid, ip en nog wat nummers. Wat betekenen die laatste nummers?

Ik heb gewoon ff snel, het volgende gedaan.

PHP:

<?php
session_start();
$_SESSION['oebiedoebie'] = 'blaat';
echo "<pre>";
print_r($_COOKIE);
?>

Ik ben trouwens wel van mening dat er communicatie tussen de servers moet zijn voor de beveiliging, én dat een server de hoofd server als het ware is.

Ooh en je kunt heel goed bovenop een onvaag protocol (zoals http) zelf een vaag protocol verzinnen.

[ Voor 15% gewijzigd door seweso op 22-04-2004 16:35 . Reden: verkleind, taalgebruik ]

[MisterData]

Werken cookies eigenlijk ook als je bijvoorbeeld op www.test.nl een cookie zet op subdomein.test.nl? Als dat zo is, dan zou je bijvoorbeeld www.site1.nl kunnen verwijzen naar www1.test.nl en www.site2.nl naar www2.test.nl. Dan krijgen beide subdomeinen dezelfde koekjes.... (overigens moet je dan natuurlijk wel een doorverwijzing aan de browserkant doen bijv met Location-header, javascript of metatag)

maar zoals gezegd ik weet het niet zeker

[ Voor 17% gewijzigd door MisterData op 22-04-2004 16:31 ]

[seweso]

MisterData schreef op 22 april 2004 @ 16:31:
Werken cookies eigenlijk ook als je bijvoorbeeld op www.test.nl een cookie zet op subdomein.test.nl? Als dat zo is, dan zou je bijvoorbeeld www.site1.nl kunnen verwijzen naar www1.test.nl en www.site2.nl naar www2.test.nl. Dan krijgen beide subdomeinen dezelfde koekjes.... (overigens moet je dan natuurlijk wel een doorverwijzing aan de browserkant doen bijv met Location-header, javascript of metatag)

maar zoals gezegd ik weet het niet zeker

Ja dat werkt

[Erik Jan]

Ik vind dit een vaag topic. Hoe zou "eenvoorbeeld.com" nou moeten weten wat voor informatie ik met "tweakers.net" heb uitgewisseld als zij geen onderlinge relatie onderhouden? Dat is toch de essentie van een geswitched netwerk als internet?

Het hele idee van cookies is dat sites een stukje informatie op jouw computer kunnen opslaan, zonder zich zorgen te hoeven maken dat andere sites ook toegang krijgen tot die informatie. Mocht iemand toch al jouw cookies kunnen uitlezen, dan is dit gewoon een security issue in de browsersoftware. Aangezien de huidige browsers (bv. IE en Mozilla) hier echt wel op aangepast zijn is de discussie een beetje zinloos.

[eghie]

Wat je ook kunt doen is 1 sql database en daar laat je beide servers mee communiceren. Sla daar een sessionid op en ip en gebruikersnaam en w8woord op als een gebruiker inlogd (maybe gebruikersnaam en w8woord geencrypt, waar je je sessionid als key gebruikt). Dan kun je zorgen dat je bij de 1e server via een form het sessionid naar de 2e server stuurt. Dan controlleerd de 2e server die met de database en je ip en dan logt hij je in op de 2e server als het klopt. Wel zorgen dat SQL injection niet werkt.

Zorg ook dat er een tijdslimiet aan die sessionid's zit, via scriptje ofzo.

[ Voor 8% gewijzigd door eghie op 23-04-2004 11:01 ]

[mindcrash]

-Rob- schreef op 22 april 2004 @ 15:34:
Wat mag niet: een centrale server (het zijn fysiek 2 servers) of servers die via allerlei vage protocollen met elkaar praten.

Nu de grote vraag: kan dit?

Ik weet niet wat er bij jou onder "vage protocollen" valt maar het Open Source Drupal project heeft een in mijn ogen vrij schaalbare en betrouwbare oplossing gebouwd op basis van XML-RPC waarmee je op elk gewenst domein die deze methode ondersteund kunt authorizen door achter je logginnaam een apestaart te zetten in combinatie met de domeinnaam waarop je jezelf hebt geregistreerd (bijvoorbeeld '[e-mail]').

Voorbeeld:

We hebben 2 domeinen, laten we zeggen jantje.org en pietje.org. Als jan, de eigenaar van jantje.org, vervolgens inlogt op de server van piet, pietje.org, zal gekeken worden of er een '@<domein>' in zijn login naam voorkomt. Is dat zo dan wordt er via XML-RPC contact gezocht met de server in het domein veld (hier bijvoorbeeld jantje.org). Op deze server wordt dan een functie aangeroepen die checked of de credentials van jantje kloppen en vervolgens wordt er iets naar de server van pietje gereturned waaruit blijkt dat zijn gegevens kloppen. Omgekeerd (dus pietje logt in op de server van jantje) gebeurt hetzelfde. En mocht er geen '@' in de naam voorkomen dan zal geprobeerd worden om de gebruiker te authenticaten op hetzelfde domein waar hij zichzelf aanmeldt.

Wat je trouwens vervolgens met de verkregen gegevens doet laat ik aan jou over

[Eärendil]

Je zou ook de de gegevens (username,password(-hash),enz.) op een of andere manier kunnen versleutelen en de versleutelde data meesturen naar de andere host