Entwickler-Ecke
Sonstiges (Web-Entwicklung) - 2 Rechner im Internet voneinander unterschieden
Heiko - Di 02.10.07 17:49
Titel: 2 Rechner im Internet voneinander unterschieden
Hallo,
besteht die Möglichkeit zwei Rechner, die hinter dem gleichen Router stecken, von einander zu unterschieden, ohne etwas beim Browser zu hinterlassen (keine Cookies etc.). Das eine Teil, an was ich mit programmiere, soll Cookielos funktionieren, sprich die sid für immer mitgegeben und aufm Server gespeichert. Allerdings besteht das Problem, wenn man den Link mitigbt und die sid nicht entfernt, dass einer sich ja des Accounts bemächtigen könnte, falls der andere noch eingeloggt ist. Die einzige Variante Rechner von einander zu unterscheiden scheint REMOTE_ADDR, von $_SERVER zu sein. HTTP_X_FORWARDED_FOR und HTTP_CLIENT_IP werden bei mir leider nicht gesetzt :(.
Aber irgendwie muss das ganze doch gehen, denn der Router muss ja wissen, wohin mit den Paketen...
Grüße
Heiko
Narses - Di 02.10.07 18:25
Titel: Re: 2 Rechner im Internet voneinander unterschieden
Moin!
Heiko hat folgendes geschrieben: |
Aber irgendwie muss das ganze doch gehen, denn der Router muss ja wissen, wohin mit den Paketen... |
Das geht aber AFAIK nur im Router, nicht von aussen.
Hintergrund:
- Der Router kriegt ein Paket von privateIP1:Port1 für einen Webservern, er leitet das Paket unter publicIP:Port2 weiter an den Webserver.
- Der Router kriegt kurz danach ein Paket von privateIP2:Port3 für den gleichen Webserver, er leitet das Paket unter publicIP:Port4 weiter.
- Der Webserver antwortet an publicIP:Port2, was der Router umschlüsseln kann zu privateIP1:Port1
- Der Webserver antwortet an publicIP:Port4, was der Router umschlüsseln kann zu privateIP2:Port3
Es wird klar, dass nur der Router wissen kann, welche IP/Port-Kombination zu welcher Verbindung gehört (das ist der Zweck der TCP-Forward-Table im Router). :nixweiss: Noch schlimmer: wenn die Pakete alle von privateIP1 gesendet würden, sieht das für den Webserver sogar gleich aus! :shock:
Fazit: du kannst einen PC oder eine zweite Browsersession hinter einem NAT-Router nicht mehr unterscheiden! :mahn: :|
cu
Narses
Agawain - Di 02.10.07 23:27
Hi
naja, gäb da wohl mehrere Möglichkeiten, je nach Kontext
Im Grunde kann man es bis auf die MAC-Addie auflösen.
Jetzt fehlt aber Input...wenn Du zum Beispiel einen Server geschrieben hast mit Session-Verwaltung, dann kannste einfach eine Port-Tabelle verwalten, welche Ports bereits von Sessions belegt sind und eine neue Session muß einen freien Port anfragen.
Na ja, aber solange man nicht weiß, was Du da vor hast :nixweiss:
Gruß
Aga
Narses - Mi 03.10.07 00:01
Moin!
Agawain hat folgendes geschrieben: |
naja, gäb da wohl mehrere Möglichkeiten, je nach Kontext
Im Grunde kann man es bis auf die MAC-Addie auflösen. |
Damit ich dich richtig verstehe: du kannst die MAC-Adresse der Karte hinter einem NAT-Router ermitteln, von der aus ich einen http-Request gestellt habe (und zwar ohne das Scripting im Browser erlaubt ist)?
Das glaube ich erst, wenn du es demonstriert hast! ;) Bin gespannt. :zustimm:
cu
Narses
Agawain - Mi 03.10.07 00:08
HI
@Narses, steht nix von NAT-Router da und von der Restriktion Scripting auch nicht
Gruß
Aga
PS deswegen soll ja mehr input
Narses - Mi 03.10.07 00:18
Moin!
Agawain hat folgendes geschrieben: |
@Narses, steht nix von NAT-Router da |
Heiko hat folgendes geschrieben: |
besteht die Möglichkeit zwei Rechner, die hinter dem gleichen Router stecken, von einander zu unterschieden,
[...]
denn der Router muss ja wissen, wohin mit den Paketen |
OK, das NAT beim Router habe ich unterstellt - aber damit muss man heutzutage ja wohl rechnen, oder? ;)
Agawain hat folgendes geschrieben: |
und von der Restriktion Scripting auch nicht |
Auch das ist eine heutzutage durchaus übliche Restriktion (ich habe in meiner Internetzone keinerlei Scripting etc. aktiviert :nixweiss:).
cu
Narses
Agawain - Mi 03.10.07 11:03
Huhu Narses
und manchmal kotzen die Pferde herdenweise vor der Apotheke :wink:
Ne mal im Ernst, NAT-Router ist nicht der Normalfall nach meiner Erfahrung, bei Networkern evtl. aber es gibt mit Sicherheit tausende von Fällen, die würden fragen, NAT-R0uter, was ist das, kann man das essen?
Was Scripting angeht, naja, da sind einige auch recht unbedarft
Support darf nie davon ausgehen, daß irgendwelche Voraussetzungen erfüllt sind, im Zweifelsfall fehlt einfach der Strom...ist mir jetzt die Tage direkt 2 mal passiert, weil Chefe auf dem Strospartrip ist und unter anderem eine Steckerleiste so blöd angeschlossen war, dass zwar die Rechner gingen, aber der Switch nicht...demzufoge ging Bankverkehr nicht, weil Netzwerk nicht da...s.o.
Gruß
Aga
:rofl:
Heiko - Mi 03.10.07 11:50
Agawain hat folgendes geschrieben: |
Support darf nie davon ausgehen, daß irgendwelche Voraussetzungen erfüllt sind |
Japp, nur wenn man Möglichkeiten kennt, sollte man die noch einbeziehen, auch wenn es ohne funktionieren muss ;).
Als Resumé sehe ich jetzt einfach mal: dass meine Hoffnung auf "versteckte" TCP/HTTP-Parameter nicht erfüllt sind. (Ich hatte schon gedacht die Unique_ID hilft mir, aber die ist ja jesesmal anders :( ). Eine Möglichkeit wäre z.b. auch gewesen, dass jeder Browser ne InstallationsID hat, die er mitschickt. Aber nun ja, was solls :schulterzuck: .
Bei einem Browsergame sollte es nicht so schlimm srein, wenn man das kleine Sicherheitsloch lässt - denn wie wahrscheinlich ist es, dass einer eine URL inkl. sid weitergibt und ein gleicher ausm internen Netz den Link aufruft, bevor der andere sich ausgeloggt hat? Eigentlich relativ gering. Die einzige Sicherheitsmöglichkeit, die man bei Cookielosen Verfahren einbauen könnte, wäre jedesmal eine andere sid dem User zu geben. Hätte allerdings den Nachteil, dass man nur einen Tab gleichzeitg offen haben kann ;).
Grüße
Heiko
matze - Mi 03.10.07 12:40
Du könntest zur Unterscheidung sämtliche HTTP Header nehmen, also User Agent, Accept-Chars, accept-Formats und so weiter. Das ist zwar nicht der riesen Hit, aber es könnte klappen.
BenBE - Mi 03.10.07 13:13
Außerdem könnte man "OneTime-IDs" verwenden, deren Gültigkeit auf wenige Minuten begrenzt ist.
Verfeinert werden könnte dies z.B. durch Client-Skripting, um zusätzliche ID-Informationen auszulesen.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!