Hi,

ich habe mir gerade überlegt, was für Möglichkeiten gäbe es eine Session
vor Diebstahl zu sichern.

a) Die erste und bisher einzige "brauchbare" Lösung ist bei mir die
Überprüfung der aktuellen IP Adresse mit der des Inhabers einer Session.

Quellcode für diese Prüfung bei mir (falls jemand sowas braucht):
....
protected function checkIpadress()
{
/*
* Falls in der Session eine IP Adresse hinterlegt ist, wird diese
* ueberprueft, ob Sie zum jetzigen Benutzer passt. Falls dies nicht
* der Fall ist (zum Beispiel bei Session Diebstahl) wird eine neue
* Session ID mit leerem Inhalt erzeugt
*/
if(isset($_SESSION['REMOTE_ADDR']))
{
if($_SESSION['REMOTE_ADDR'] != $_SERVER['REMOTE_ADDR'])
{
session_regenerate_id(true);
$_SESSION = array();
}
}

/*
* Falls in den Session Daten noch keine IP Adresse hinterlegt ist
* (Beim ersten Seitenaufruf oder bei neuer Sessiongenerierung) wird
* die IP Adresse des derzeitigen Benutzers in die Session gespeichert
*/
if(isset($_SESSION['REMOTE_ADDR']) == false)
{
$_SESSION['REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR'];
}
}
....

Fallen euch noch brauchbare andere Lösungen ein? Alternativen wüsste ich
zwar noch in Form vom Browseragent überprüfen z.B. aber das ist noch
unsicherer als die IP Adresse, von daher denke ich nicht brauchbar.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

..oO(Christoph Herrmann)

>ich habe mir gerade überlegt, was für Möglichkeiten gäbe es eine Session
>vor Diebstahl zu sichern.
>
>a) Die erste und bisher einzige "brauchbare" Lösung ist bei mir die
>Überprüfung der aktuellen IP Adresse mit der des Inhabers einer Session.

Gerade das funktioniert nicht (gibt's auch 'nen FAQ-Artikel zu). Eine IP
ist nicht eindeutig. Ein Benutzer kann Dutzende haben (auch innerhalb
einer Session kann sich die IP ändern!) und hunderte Benutzer können
dieselbe IP haben.

Micha

Christoph Herrmann meinte:
> Hi,
>
> ich habe mir gerade überlegt, was für Möglichkeiten gäbe es eine Session
> vor Diebstahl zu sichern.
>
> a) Die erste und bisher einzige "brauchbare" Lösung ist bei mir die
> Überprüfung der aktuellen IP Adresse mit der des Inhabers einer Session.

"Normalerweise" teilen sich haufenweise Benutzer eine IP-Adresse. Und
"normalerweise" wird ändert sich die auch in unregelmäßigen Abständen
bei Surfern mit einer - der name sagt's - dynamischen IP-Adresse.

Gruß, Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Christoph Herrmann schrieb:
> Hi,
>
> ich habe mir gerade überlegt, was für Möglichkeiten gäbe es ein=
e Session
> vor Diebstahl zu sichern.
>
> a) Die erste und bisher einzige "brauchbare" Lösung ist bei mir die
> =DCberprüfung der aktuellen IP Adresse mit der des Inhabers einer Ses=
sion.
>

29.15. Warum verwendet PHP nicht die IP-Nummer des Browsers als Schutz
gegen eine =DCbernahme der Session?
http://www.php-faq.de/q/q-sessions-ip.html

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Michael Fesser schrieb:
> Gerade das funktioniert nicht (gibt's auch 'nen FAQ-Artikel zu). Eine IP
> ist nicht eindeutig. Ein Benutzer kann Dutzende haben (auch innerhalb
> einer Session kann sich die IP ändern!) und hunderte Benutzer können
> dieselbe IP haben.

deswegen das "brauchbar" auch in Anführungszeichen. ;) Vorteil ist aber
es bietet zumindest etwas Schutz, ist schnell implementiert und hat kaum
Nachteile (Logout nach IP Wechsel dürfte eher weniger ein Problem sein,
oder?).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

On Wed, 07 Nov 2007 11:38:51 +0100 Christoph Herrmann wrote:
> > Ein Benutzer kann Dutzende haben (auch innerhalb einer Session
> > kann sich die IP ändern!) und hunderte Benutzer können dieselbe
> > IP haben.

> deswegen das "brauchbar" auch in Anführungszeichen. ;) Vorteil ist
> aber es bietet zumindest etwas Schutz,

Was ist "etwas" Schutz?

> ist schnell implementiert und hat kaum Nachteile (Logout nach IP
> Wechsel dürfte eher weniger ein Problem sein, oder?).

Die Nachteile sind so klein, dass es eines der ersten Dinge gewesen
ist, die ich nach der Uebernahme einer bestehenden Applikation
aendern durfte. Ob ein Logout nach IP-Wechsel ein Problem ist, musst
Du mit dem Anwender klaeren, der sich fuer jede (oder jede zweite
bis dritte) Seite neu anmelden darf.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

1998 Jahre seit der Schlacht im Teutoburger Wald! 1998 Jahre ohne Stefan. Rubbelt und ferkelt euch.</B
(Sloganizer)

Stefan Froehlich schrieb:
> Was ist "etwas" Schutz?

Wenn der Angreifer nicht hinter dem selben Proxy ist bewirkt es das was
es soll. Angreifer andere IP Adresse und daher kein Zugriff auf die
Session trotz geklauter Session ID.

> Die Nachteile sind so klein, dass es eines der ersten Dinge gewesen
> ist, die ich nach der Uebernahme einer bestehenden Applikation
> aendern durfte. Ob ein Logout nach IP-Wechsel ein Problem ist, musst
> Du mit dem Anwender klaeren, der sich fuer jede (oder jede zweite
> bis dritte) Seite neu anmelden darf.

Ein IP Erfolgt doch nur bei dynamischen IP Adressen nach der
Zwangstrennung alle 24h, oder? Dies stellt in meinen Augen kein Problem
dar, da es (gerade bei neuen Routern, bei denen man einstellen kann wann
dies erfolgt) seltener vorkommt.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Ein IP Erfolgt doch nur bei dynamischen IP Adressen nach der
> Zwangstrennung alle 24h, oder? Dies stellt in meinen Augen kein Problem
> dar, da es (gerade bei neuen Routern, bei denen man einstellen kann wann
> dies erfolgt) seltener vorkommt.
Was ist mit Benutzern von Anonymisierungsdiensten? Auch, wenn sich das
Thema evtl. nächstes Jahr gegessen hat ... :-/

ciao

ulf

Christoph Herrmann schrieb:
> Michael Fesser schrieb:
>> Gerade das funktioniert nicht (gibt's auch 'nen FAQ-Artikel zu). Eine IP
>> ist nicht eindeutig. Ein Benutzer kann Dutzende haben (auch innerhalb
>> einer Session kann sich die IP ändern!) und hunderte Benutzer können
>> dieselbe IP haben.
>
> deswegen das "brauchbar" auch in Anführungszeichen. ;) Vorteil ist aber
> es bietet zumindest etwas Schutz,

"Etwas Schutz"? naja ...

> ist schnell implementiert und hat kaum
> Nachteile (Logout nach IP Wechsel dürfte eher weniger ein Problem sein,
> oder?).

Letzteres vielleicht nicht, aber die Probleme mit Besuchern, die
über Proxys kommen und alle die selber IP haben, sehe ich schon
als großes Problem.

Ansonsten wären "session.use_only_cookies" und/oder session_regenerate_id()
ebenso schnell implementiert und stellen IMHO die einzig sinnvollen
Lösungen da.


Gruß
JPM

Ulf Seltmann schrieb:
> Was ist mit Benutzern von Anonymisierungsdiensten? Auch, wenn sich das
> Thema evtl. nächstes Jahr gegessen hat ... :-/

wieso hat sich das nächstes Jahr erledigt? Wenn es nächstes Jahr keine
Rolle spielt ist es für mich zumindest unwichtig, weil vorher werde ich
nicht mehr fertig. :)

Aber stimmt, die hab ich nicht bedacht. Also Fazit: IP Prüfung ist
schlechter als erwartet, und wie sehen die Alternativen aus?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Jens Peter Moeller schrieb:
> Letzteres vielleicht nicht, aber die Probleme mit Besuchern, die
> über Proxys kommen und alle die selber IP haben, sehe ich schon
> als großes Problem.

Nur ein Problem im Sinne von, die können sich halt noch gegenseitig die
Session klauen, oder? Daher nur bedingt Schutz, aber zumindest besser
als nichts würde ich meinen.

> Ansonsten wären "session.use_only_cookies" und/oder session_regenerate_id()
> ebenso schnell implementiert und stellen IMHO die einzig sinnvollen
> Lösungen da.

Erläuterung über das Vorgehen? Was für Sicherheitsrelevante Vorteile hat
es denn, nur auf Cookies zu setzen und was hat die Methode
"session_regenerate_id()" dann damit zu tun?

(Das war ja eigentlich mein Ziel, andere Ansätze zu finden zur Ergänzung
für besseren Schutz oder komplett als Alternative, wollte ja eigentlich
nicht auf die IP Prüfung rumhacken ^^)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Ulf Seltmann schrieb:
>> Was ist mit Benutzern von Anonymisierungsdiensten? Auch, wenn sich das
>> Thema evtl. nächstes Jahr gegessen hat ... :-/
>
> wieso hat sich das nächstes Jahr erledigt?

Ich denke Ulf spielt auf die Vorratsdatenspeicherung an, die in 2 Tagen
vielleicht verabschiedet wird.
http://de.wikipedia.org/wiki/Vorratsdatenspeicherung

Gruß,
Torsten

Christoph Herrmann schrieb:

> Ein IP Erfolgt doch nur bei dynamischen IP Adressen nach der
> Zwangstrennung alle 24h, oder?

Nein, es kann durch Load-Balancing des Proxys bei jedem Request zu einer
neuen IP kommen.

> Dies stellt in meinen Augen kein Problem
> dar, da es (gerade bei neuen Routern, bei denen man einstellen kann wan=
n
> dies erfolgt) seltener vorkommt.

Darauf hat man idR nur Einfluss durch die Provider-Wahl (s. AOL).

Die IP hat nur Sinn für die Strafverfolgungsbehörden in Verbindung mi=
t
den beim Provider gespeicherten Verbindungsdaten. Daher ist es klug, die
IP zusammen mit der Uhrzeit bei Forumsbeiträgen u.ä. festzuhalten.
Ansonsten ist sie völlig wertlos.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Christoph Herrmann schrieb:
> Jens Peter Moeller schrieb:

>> Ansonsten wären "session.use_only_cookies" und/oder session_regenerate_id()
>> ebenso schnell implementiert und stellen IMHO die einzig sinnvollen
>> Lösungen da.
>
> Erläuterung über das Vorgehen? Was für Sicherheitsrelevante Vorteile hat
> es denn, nur auf Cookies zu setzen und was hat die Methode
> "session_regenerate_id()" dann damit zu tun?

Ein Cookie zu klauen erfordert schon etwas mehr kriminelle Energie.
Spontan fällt mir da nur eine XSS-Attacke ein. Auf jeden Fall löst
es das Problem mit (versehentlich) weitergegebenen URLs.

session_regenerate_id() erneuert bei jedem Request die Session-ID.
Eine, wie auch immer geklaute Session, wäre für den Angreifer also
nur solange nutzbar, wie der Besitzer noch keine neue Seite aufgerufen
hat.


Gruß
JPM

Jens Peter Moeller schrieb:
> Ein Cookie zu klauen erfordert schon etwas mehr kriminelle Energie.
> Spontan fällt mir da nur eine XSS-Attacke ein. Auf jeden Fall löst
> es das Problem mit (versehentlich) weitergegebenen URLs.

Wenn Cookies erlaubt sind, werden diese ja eh immer genommen (soweit ich
jetzt weiß). Von daher bringt das kein mehr an Sicherheit außer dass
Leute ohne Cookies ausgeschlossen werden. Was für mich eher keiner
alternative ist.

> session_regenerate_id() erneuert bei jedem Request die Session-ID.
> Eine, wie auch immer geklaute Session, wäre für den Angreifer also
> nur solange nutzbar, wie der Besitzer noch keine neue Seite aufgerufen
> hat.

Das wäre schon mal eine schöne alternative. Hätte demnach für den
Benutzer keinerlei Nachteile und würde die Sicherheit für die Fälle
erhöhen, wo der Angreifer nicht schnell genug ist. Wenn auch etwas wage
die Sicherheit, aber dennoch mehr als ohne.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Fallen euch noch brauchbare andere Lösungen ein? Alternativen wüsste ich
> zwar noch in Form vom Browseragent überprüfen z.B. aber das ist noch
> unsicherer als die IP Adresse, von daher denke ich nicht brauchbar.

b) Zwar nicht gerade sicher, aber die Frage vielleicht doch mal in die
Runde werfen. Wie sicher oder zuverlässig ist denn die Überprüfung
verschiedener Browserinformationen? Diese sollten für den Benutzer ja
kein Problem darstellen, da sich diese innerhalb einer Session wohl
nicht ändern werden und es somit nicht zu ungewollten Auto Logouts
kommen kann.

Und Detailfrage noch, welche Informationen lassen sich denn mit PHP
besorgen (also welche Variablen beinhaltet hier welche Informationen zu
dem Thema)?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> Jens Peter Moeller schrieb:
>> session_regenerate_id() erneuert bei jedem Request die Session-ID.
>> Eine, wie auch immer geklaute Session, wäre für den Angreifer also
>> nur solange nutzbar, wie der Besitzer noch keine neue Seite aufgerufen
>> hat.
>
> Das wäre schon mal eine schöne alternative. Hätte demnach für den
> Benutzer keinerlei Nachteile und würde die Sicherheit für die Fälle
> erhöhen, wo der Angreifer nicht schnell genug ist. Wenn auch etwas wage
> die Sicherheit, aber dennoch mehr als ohne.

Bzw. Was wenn der Angreifer schnell genug ist, dann hat er auf einmal
eine gültige Session, aber der legitime Benutzer nicht mehr und wird
ausgeloggt. Somit könnte der Angreifer schön schaden anrichten während
der Benutzer sich erstmal wieder einloggen muss.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann schrieb:
> b) Zwar nicht gerade sicher, aber die Frage vielleicht doch mal in die
> Runde werfen. Wie sicher oder zuverlässig ist denn die Überprüfung
> verschiedener Browserinformationen? Diese sollten für den Benutzer ja
> kein Problem darstellen, da sich diese innerhalb einer Session wohl
> nicht ändern werden und es somit nicht zu ungewollten Auto Logouts
> kommen kann.
>
> Und Detailfrage noch, welche Informationen lassen sich denn mit PHP
> besorgen (also welche Variablen beinhaltet hier welche Informationen zu
> dem Thema)?

c) eine Erweiterung dazu, wenn Cookies erlaubt sind:
Der Cookie bekommt ebenfalls die Daten des Browsers verpasst. Stimmen
diese dann nicht mit denen in der Session mit dem aktuellen Request
überein ist es ein Angriff. Auf diese Weise müsste ein Angreifer den
Cookie zusätzlich klauen.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

> Aber stimmt, die hab ich nicht bedacht. Also Fazit: IP Prüfung ist
> schlechter als erwartet, und wie sehen die Alternativen aus?

Es so lassen, wie es vorgesehen ist. Bestenfalls noch SessionID aus der URL
verbannen, also auf Cookies einschränken.

Christoph Herrmann:

> a) Die erste und bisher einzige "brauchbare" Lösung ist bei mir die
> Überprüfung der aktuellen IP Adresse mit der des Inhabers einer Session.

Mittlerweile solltest Du wissen, dass das ein Schmarn ist.

> Fallen euch noch brauchbare andere Lösungen ein?

- Nur mit Cookies zu arbeiten (nicht jeder kann Cookies)
- die SID bei jedem Request ändern
--
Mit PHP Kontonummern auf Gültigkeit prüfen:
<http://bav.malkusch.de/>

Christoph Herrmann schrieb:

> Ein IP Erfolgt doch nur bei dynamischen IP Adressen nach der
> Zwangstrennung alle 24h, oder?

Du gehst also davon aus, dass alle Surfer 24 Stunden am Stück online
sind? Und Du gehst davon aus, dass alle Provider nach 24 Stunden eine
Zwangstrennung durchführen?

Nicht jeder hat DSL. Nicht jeder hat eine Flatrate. Nicht jeder hat
Deinen Provider. Willkommen in der Realität.

Gruß. Claus

..oO(Christoph Herrmann)

>Jens Peter Moeller schrieb:
>
>> Ein Cookie zu klauen erfordert schon etwas mehr kriminelle Energie.
>> Spontan fällt mir da nur eine XSS-Attacke ein. Auf jeden Fall löst
>> es das Problem mit (versehentlich) weitergegebenen URLs.
>
>Wenn Cookies erlaubt sind, werden diese ja eh immer genommen (soweit ich
>jetzt weiß). Von daher bringt das kein mehr an Sicherheit außer dass
>Leute ohne Cookies ausgeschlossen werden. Was für mich eher keiner
>alternative ist.

Eine SID in der URL ist einfacher abzugreifen als ein Cookie, da sie im
Serverlogfile gespeichert wird und per HTTP Referrer auch sehr leicht an
andere Sites durchsickern kann.

Micha

Claus Reibenstein schrieb:
> Du gehst also davon aus, dass alle Surfer 24 Stunden am Stück online
> sind? Und Du gehst davon aus, dass alle Provider nach 24 Stunden eine
> Zwangstrennung durchführen?
>
> Nicht jeder hat DSL. Nicht jeder hat eine Flatrate. Nicht jeder hat
> Deinen Provider. Willkommen in der Realität.

Natürlich nicht, wer sich mit Modem neu einwählt bekommt auch eine neue
IP Adresse oder wer keine Dauerverbindung offen hält. Aber wie oft macht
man das? Höchstens der Router macht es automatisch, also nach 5 min
nichts tun abmelden und bei Gebrauch wieder einwählen, das wär dann nen
Problem. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Michael Fesser schrieb:
> Eine SID in der URL ist einfacher abzugreifen als ein Cookie, da sie im
> Serverlogfile gespeichert wird und per HTTP Referrer auch sehr leicht an
> andere Sites durchsickern kann.

Das ist klar, aber sollte man deswegen Benutzer ausschließen, welche
keine Cookies erlauben?

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

> Die IP hat nur Sinn für die Strafverfolgungsbehörden in Verbindung mit
> den beim Provider gespeicherten Verbindungsdaten. Daher ist es klug, die
> IP zusammen mit der Uhrzeit bei Forumsbeiträgen u.ä. festzuhalten.
Ob das wirklich so klug ist?

Siehe Urteil vom AG/LG Berlin:
http://www.telemedicus.info/article/436-Dont-track-your-user s-IP-Adressen-speichern-verboten.html

Das gilt im Prinzip auch für Foreneinträge, sofern keine wirksame
Einwilligung vorliegt (und ein einfacher Texthinweis ist in der Regel
nicht wirksam!).

--
Adrian Schneider
http://www.telemedicus.info/
PGP: http://www.asfs.de/pgp/pub.asc

Christoph Herrmann schrieb:

> Claus Reibenstein schrieb:
>
>> Nicht jeder hat DSL. Nicht jeder hat eine Flatrate. Nicht jeder hat
>> Deinen Provider. Willkommen in der Realität.
>
> Natürlich nicht, wer sich mit Modem neu einwählt bekommt auch eine neue
> IP Adresse oder wer keine Dauerverbindung offen hält. Aber wie oft macht
> man das?

Macht man was? Eine Dauerverbindung per DSL offen halten? Mache ich nie.
So asozial bin ich nicht.

Wer eine Dauerverbindung haben möchte, soll sich gefälligst eine
Standleitung mieten. Dazu sind sie da.

> Höchstens der Router macht es automatisch, also nach 5 min
> nichts tun abmelden und bei Gebrauch wieder einwählen, das wär dann nen
> Problem. :)

Das ist bei mir der Normalfall. Ich belege Ressourcen dann, wenn ich sie
brauche, und gebe sie frei, wenn ich sie nicht mehr brauche. Eine
Dauerverbindung über 24 Stunden offen zu halten, wenn ich sowieso nur
10-12 Stunden am Tag am Rechner sitze und davon vielleicht 2-3 Stunden
online bin, ist Unfug.

Gruß. Claus

Hoppla, falsche E-Mail Adresse. Entschuldigung.

--
Adrian Schneider
http://www.telemedicus.info/
PGP: http://www.asfs.de/pgp/pub.asc

..oO(Christoph Herrmann)

>Michael Fesser schrieb:
>> Eine SID in der URL ist einfacher abzugreifen als ein Cookie, da sie im
>> Serverlogfile gespeichert wird und per HTTP Referrer auch sehr leicht an
>> andere Sites durchsickern kann.
>
>Das ist klar, aber sollte man deswegen Benutzer ausschließen, welche
>keine Cookies erlauben?

In diesem Fall riskiere ich es (ja, ich habe gründlich darüber
nachgedacht). URL-SIDs gibt's bei mir grundsätzlich _nicht_ mehr.
Wer selbst Session-Cookies ablehnt, hat bei mir schlechte Karten.

Ich gehe ohnehin davon aus, daß die meisten Browser Cookies standard-
mäßig akzeptieren und die Benutzer, die ihren Browser selbst konfigu-
rieren können, fähig genug sind, Session-Cookies bei Bedarf zuzulassen.

Micha

Christoph Herrmann schrieb:

> Michael Fesser schrieb:
>
>> Eine SID in der URL ist einfacher abzugreifen als ein Cookie, [...]
>
> Das ist klar, aber sollte man deswegen Benutzer ausschließen, welche
> keine Cookies erlauben?

Das hängt von der jeweiligen Situation ab.

Wenn die Daten kritisch genug sind, um solche Sicherheitsmaßnahmen zu
erfordern, sollte man diese Maßnahmen auch treffen. Wer sich nicht
danach richten will, hat dann eben Pech.

Gruß. Claus

..oO(Claus Reibenstein)

>Christoph Herrmann schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> Nicht jeder hat DSL. Nicht jeder hat eine Flatrate. Nicht jeder hat
>>> Deinen Provider. Willkommen in der Realität.
>>
>> Natürlich nicht, wer sich mit Modem neu einwählt bekommt auch eine neue
>> IP Adresse oder wer keine Dauerverbindung offen hält. Aber wie oft macht
>> man das?
>
>Macht man was? Eine Dauerverbindung per DSL offen halten? Mache ich nie.
>So asozial bin ich nicht.

Ich nutze nur die Resourcen, für die ich auch monatlich bleche.
Was bitte ist daran asozial?

>Das ist bei mir der Normalfall. Ich belege Ressourcen dann, wenn ich sie
>brauche, und gebe sie frei, wenn ich sie nicht mehr brauche. Eine
>Dauerverbindung über 24 Stunden offen zu halten, wenn ich sowieso nur
>10-12 Stunden am Tag am Rechner sitze und davon vielleicht 2-3 Stunden
>online bin, ist Unfug.

Für mich wäre es Unfug, noch darüber nachzudenken. Ich nutze das Netz
ganz einfach, so als wäre mein Arbeitsrechner ständig "online". Um den
eigentlichen Auf- und gelegentlichen Abbau kümmert sich der Rechner
nebenan automatisch. Da dieser 24/7 durchläuft und gelegentlich auch
selbst was aus dem Netz zieht, ist die Verbindung praktisch den größten
Teil des Tages offen.

Micha

Christoph Herrmann schrieb:
> Michael Fesser schrieb:
>> Eine SID in der URL ist einfacher abzugreifen als ein Cookie, da sie im
>> Serverlogfile gespeichert wird und per HTTP Referrer auch sehr leicht an
>> andere Sites durchsickern kann.
>
> Das ist klar, aber sollte man deswegen Benutzer ausschließen, welche
> keine Cookies erlauben?

<em class="uebertreib">Der Mythos der bösen Cookies gehört
ausgerottet, notfalls mit Gewalt. Und wer unwissentlich Cookies
blockiert, weil er sich gelbe Schachteln, o.ä. Schlangenöl, ins
Haus geholt hat, verdient es eh nicht besser.</em>


SNCR
JPM

On Wed, 07 Nov 2007 12:22:34 +0100 Christoph Herrmann wrote:
> > Die Nachteile sind so klein, dass es eines der ersten Dinge
> > gewesen ist, die ich nach der Uebernahme einer bestehenden
> > Applikation aendern durfte. Ob ein Logout nach IP-Wechsel ein
> > Problem ist, musst Du mit dem Anwender klaeren, der sich fuer
> > jede (oder jede zweite bis dritte) Seite neu anmelden darf.

> Ein IP Erfolgt doch nur bei dynamischen IP Adressen nach der
> Zwangstrennung alle 24h, oder?

Oder.

> Dies stellt in meinen Augen kein Problem dar, da es (gerade bei
> neuen Routern, bei denen man einstellen kann wann dies erfolgt)
> seltener vorkommt.

Du gehst zu sehr von typischen Anwendungsfaellen aus. Es haengt halt
auch immer davon ab, wen Du mit den Seiten erreichen willst und
musst. Im oben angesprochenen Fall war jeder einzelne Kunde sehr
wichtig - und da gab es halt (mehrere) Faelle mit Proxy-Verbuenden,
die ihre Requests gleichmaessig ueber 2 bis 8 IP-Adressen verteilt
haben. Ich kaenne auch Faelle, wo PDF-Dokumente konsequent von
anderen IP-Adressen aus angefordert werden, als HTML-Seiten. Keine
Ahnung, was da fuer Infrastruktur dahinter ist, aber man sollte
besser nicht damit rechnen, sich auf irgendetwas verlassen zu
koennen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Stefan - stramm, überlegen in allen Nächten!
(Sloganizer)

Michael Fesser schrieb:
> Ich nutze nur die Resourcen, für die ich auch monatlich bleche.
> Was bitte ist daran asozial?

Bin ich auch der Meinung und spätestens wenn IPv6 mal Standard ist hat
es auch überhaupt keine negative Auswirkung auf den Rest der Menschheit.
Zumal bei mir (legale) Downloads den ganzen Tag laufen in der Regel.

Aber die Moral steht hier ja nicht zur Debatte. :)

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Jens Peter Moeller schrieb:
> <em class="uebertreib">Der Mythos der bösen Cookies gehört
> ausgerottet, notfalls mit Gewalt. Und wer unwissentlich Cookies
> blockiert, weil er sich gelbe Schachteln, o.ä. Schlangenöl, ins
> Haus geholt hat, verdient es eh nicht besser.</em>

was ist daran schlimm, wenn ich mich der Verfolgung durch Google, Amazon
und Co. entziehen will? ;) Deswegen werden bei mir Cookies bei
Browserende gelöscht (verbieten tue ich Sie nicht, da Sie gerade im
Falle von Sessions für mehr Sicherheit sorgen).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann meinte:
> Christoph Herrmann schrieb:
>> Fallen euch noch brauchbare andere Lösungen ein? Alternativen wüsste
>> ich zwar noch in Form vom Browseragent überprüfen z.B. aber das ist
>> noch unsicherer als die IP Adresse, von daher denke ich nicht brauchbar.
>
> b) Zwar nicht gerade sicher, aber die Frage vielleicht doch mal in die
> Runde werfen. Wie sicher oder zuverlässig ist denn die Überprüfung
> verschiedener Browserinformationen? Diese sollten für den Benutzer ja
> kein Problem darstellen, da sich diese innerhalb einer Session wohl
> nicht ändern werden und es somit nicht zu ungewollten Auto Logouts
> kommen kann.

Wenn überhaupt, wirst du keine sinnvoll zuordenbare Infos kriegen.

> Und Detailfrage noch, welche Informationen lassen sich denn mit PHP
> besorgen (also welche Variablen beinhaltet hier welche Informationen zu
> dem Thema)?

$_SERVER['HTTP_USER_AGENT']. Praktisch jeder, der dich mit einem IE
ansurft, hat den gleichen User Agent, jeder der mit Firefox kommt detto.
Die verwertbare Information ist bei viel zu vielen Benutzer nicht
unterscheidbar.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler schrieb:
> $_SERVER['HTTP_USER_AGENT']. Praktisch jeder, der dich mit einem IE
> ansurft, hat den gleichen User Agent, jeder der mit Firefox kommt detto.
> Die verwertbare Information ist bei viel zu vielen Benutzer nicht
> unterscheidbar.

und wie sieht es mit "get_browser()" aus? Wenn man das komplette Array
nimmt und in die Session speichert und immer vergleicht.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Herrmann meinte:
> Gregor Kofler schrieb:
>> $_SERVER['HTTP_USER_AGENT']. Praktisch jeder, der dich mit einem IE
>> ansurft, hat den gleichen User Agent, jeder der mit Firefox kommt
>> detto. Die verwertbare Information ist bei viel zu vielen Benutzer
>> nicht unterscheidbar.
>
> und wie sieht es mit "get_browser()" aus? Wenn man das komplette Array
> nimmt und in die Session speichert und immer vergleicht.

Was soll das bringen? Mehr als ein Zerpflücken des HTTP_USER_AGENTS
passiert da auch nicht. Indentischer HTTP_USER_AGENT liefert IMO idente
Rückgabewerte mit get_browser().

Hol dir eine Extension (etwa FireBug) und schau dir die Header an -
außer dem User-Agent-String erfährt der Server nix. Und den
User-Agent-String kann ich nach Lust und Laune ändern...

Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Christoph Herrmann schrieb:
> Gregor Kofler schrieb:
>> $_SERVER['HTTP_USER_AGENT']. Praktisch jeder, der dich mit einem IE
>> ansurft, hat den gleichen User Agent, jeder der mit Firefox kommt detto.
>> Die verwertbare Information ist bei viel zu vielen Benutzer nicht
>> unterscheidbar.
>
> und wie sieht es mit "get_browser()" aus?

Hast du dir mal die Manualseite angeschaut!? Die Funktion verwendet
normalerweise die Informationen aus $_SERVER['HTTP_USER_AGENT'], und bei
gleichem User Agent wirst du wohl kaum andere Informationen rausbekommen...

Christoph

Gregor Kofler schrieb:
> Was soll das bringen? Mehr als ein Zerpflücken des HTTP_USER_AGENTS
> passiert da auch nicht. Indentischer HTTP_USER_AGENT liefert IMO idente
> Rückgabewerte mit get_browser().
>
> Hol dir eine Extension (etwa FireBug) und schau dir die Header an -
> außer dem User-Agent-String erfährt der Server nix. Und den
> User-Agent-String kann ich nach Lust und Laune ändern...

Aber im Prinzip muss man diesen erstmal kennen als Angreifer. Auch wenn
es nicht viele verschiedene Browser gibt ist die Überprüfung doch besser
als wenn man nichts hat, oder? :)

Perfekt ist nichts, aber eine Kombination aus mehreren Dingen dürfte es
wenigstens dem Angreifer etwas schwerer machen, wodurch er die Lust
verliert es weiter zu probieren (wenn nicht genug "Gewinn" oder Schaden
bei Erfolg in Aussicht ist).

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Christoph Bersch schrieb:
> Hast du dir mal die Manualseite angeschaut!? Die Funktion verwendet
> normalerweise die Informationen aus $_SERVER['HTTP_USER_AGENT'], und bei
> gleichem User Agent wirst du wohl kaum andere Informationen rausbekommen...

angeschaut ja, aber nicht durchgelesen *zugeb*. :) Aber ok, dann macht
es keinerlei Sinn die Funktion zu verwenden.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/