Hallo Welt,

ich hatte letztens eine kleine Diskusion mit einem bekannten =C3=BCber
das Thema "*SessionID in Hidden-Felder ablegen oder Cookies nutzen*"?

Das man in Hidden-Feldern keine sicherheitsrelevanten Informationen
ablegen sollte wie z.B. ein Passwort ist klar, gleiches gilt aber
auch f=C3=BCr die URL (Get-Methode) ebenso wie f=C3=BCr Cookies, wobei di=
e
SessionID so oder so =C3=BCber die i.d.R. unverschl=C3=BCsselte Leitung w=
andert,
Ausnahme nat=C3=BCrlich man verwendet https anstelle von http.

Stellt sich also im allgemeinen die Frage weshalb man kein
Hidden-Feld in einem Sticky-Form nutzen sollte, anstatt =C3=BCber
Cookies oder die URL die SessionID in Erfahrung zu bringen.

Denn Cookies kann nicht jeder Browser, sie in URLs zu speichern
sieht h=C3=A4sslich aus und Hidden-Felder gehen immer. Warum also
nicht ein einziges Hidden-Feld nutzen anstelle von Cookies,
die zudem immer nur auf eine bestimmte Session begrenzt sind?

Was meint Ihr dazu? Ich bin hoch gespannt auf eure Antworten!
--
Gru=C3=9F Martin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
::::::::::::: Ich mache keine Gesch=C3=A4fte mit dem Teufel! ::::::::::::=
:
::::::::::::: Hasta la "VISTA",Baby http://opensuse.org :::::::::::::
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

..oO(Martin Parusel)

>ich hatte letztens eine kleine Diskusion mit einem bekannten über
>das Thema "*SessionID in Hidden-Felder ablegen oder Cookies nutzen*"?

Cookie.

>[...]
>
>Stellt sich also im allgemeinen die Frage weshalb man kein
>Hidden-Feld in einem Sticky-Form nutzen sollte, anstatt über
>Cookies oder die URL die SessionID in Erfahrung zu bringen.

Für ein einzelnes Formular mag das mit dem Hidden-Feld noch gehen.
Sobald es aber darüber hinausgeht und die Session auf der gesamten
Website nutzbar sein soll (z.B. Warenkorb in einem Onlineshop), ist's
Essig mit den Hidden-Feldern, denn mit normalen Links funktioniert
dieser Ansatz nicht. Taugt also nicht wirklich.

>Denn Cookies kann nicht jeder Browser

In diesem Fall ist mir das schnuppe. Letztlich gibt es zum Ablegen der
Session-ID nur zwei brauchbare Möglichkeiten: Cookie oder URL. Letzteres
scheidet für mich persönlich aus diversen Gründen aus, ergo bleiben nur
Cookies. Praktisch jeder Browser kann das und standardmäßig sind Cookies
ohnehin aktiviert. Die erfahreneren Benutzer, die ihre Browser beherr-
schen und Cookies abschalten können, sollten auch in der Lage sein,
diese bei Bedarf gezielt für einzelne Sites wieder freizugeben.

>sie in URLs zu speichern
>sieht hässlich aus und Hidden-Felder gehen immer.

Hidden-Felder gehen eben nur mit Formularen, sonst nicht. Ich brauche
Sessions aber für weit mehr als nur für Formulare. Schon ein einfaches
Loginsystem für geschützte Bereiche auf einer Website wäre mit diesem
Ansatz nicht praktikabel realisierbar. Außer natürlich, man stopft jede
Seite komplett in ein Formular und nutzt nur Submit-Buttons anstelle von
Links, aber wer will das schon?

Micha

Martin Parusel wrote:

> Denn Cookies kann nicht jeder Browser, sie in URLs zu speichern
> sieht hässlich aus und Hidden-Felder gehen immer. Warum also
> nicht ein einziges Hidden-Feld nutzen anstelle von Cookies,
> die zudem immer nur auf eine bestimmte Session begrenzt sind?
>
> Was meint Ihr dazu? Ich bin hoch gespannt auf eure Antworten!

Verschick doch jedes mal per post das Session-Ding und dann benutz mal
Reload() oder Zurück mit dem Browser - da bekommst du dauernd Meldungen, ob
du die POST Variablen noch einmal abschicken möchtest, das könnte zu einem
echten Hindernis werden.

Gruß
Johannes

--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.

Johannes Mueller schrieb:
> Martin Parusel wrote:
>
>> Denn Cookies kann nicht jeder Browser, sie in URLs zu speichern
>> sieht hässlich aus und Hidden-Felder gehen immer. Warum also
>> nicht ein einziges Hidden-Feld nutzen anstelle von Cookies,
>> die zudem immer nur auf eine bestimmte Session begrenzt sind?
>>
>> Was meint Ihr dazu? Ich bin hoch gespannt auf eure Antworten!
>
> Verschick doch jedes mal per post das Session-Ding und dann benutz mal
> Reload() oder Zurück mit dem Browser [...]

Das ist für mich das größte Gegenargument gegen dieses hidden-Feld.
Außerdem ist es vollkommen unelegant.
Also ich bin kein Experte, aber ich mache es immer so, dass ich an jeden
Link SID dranhänge, also z.B.
echo <a href=\"irgendwas.php?".SID."\">Link</a>";
In jedes Formular baue ich ein hidden-Feld ein, damit die SessionID auch
bei Formularen weitertransportiert. Hat der Besucher Cookies aktiviert,
ist die Konstante SID leer und die Url bleibt "sauber". Gegen Datenklau
habe ich eine billige IP-Sicherung. Es ist zwar klar dass das nicht
gerade sicher ist, doch es stellt ein weiteres Hindernis für
dahergelaufene Scriptkiddies dar.
Natürlich ist das nicht sicher - Sessions sind generell nicht sicher.
Fremden Variablen muss grundsätzlich misstraut werden. Aber ein
Sicherheitsgewinn durch Cookies gibt es meines Erachtens auch nicht.
Auch Cookies werden unverschlüsselt gesendet und viele Besucher haben
Cookies deaktiviert.

..oO(Adrian Ebeling)

>Natürlich ist das nicht sicher - Sessions sind generell nicht sicher.
>Fremden Variablen muss grundsätzlich misstraut werden. Aber ein
>Sicherheitsgewinn durch Cookies gibt es meines Erachtens auch nicht.
>Auch Cookies werden unverschlüsselt gesendet und viele Besucher haben
>Cookies deaktiviert.

In diesem Punkt sind Cookie-SIDs und URL-SIDs praktisch identisch. Die
Sicherheit steht und fällt mit dem verwendeten Protokoll (HTTP/HTTPS).

Aber Cookies haben dennoch einen Vorteil bzw. die URLs haben einen
entscheidenden Nachteil: Eine SID in der URL landet unweigerlich auch in
den Logfiles der Server - in denen des eigenen sowieso, aber nahezu
unvermeidlich auch in denen _anderer_ Server, nämlich über den HTTP-
Referrer.

Vor Jahren war dies eine beliebte Methode, um an gültige Session-IDs der
großen Freemailer wie GMX und Web.de zu kommen und Postfächer zu klauen.
Der Klick eines Benutzers im Webinterface auf einen speziellen Link
genügte, um per Referrer die aktuelle Session-ID an den pösen Purschen
zu schicken. Praktisch eine Lieferung des Wohnungsschlüssels frei Haus.

Dazu kommt das durchaus nicht immer klare Verhalten von Suchmaschinen,
wenn sie dank wechselnder SID im Query-String bei jedem Besuch eine
andere URL vorgesetzt bekommen. Moderne SEs sollten zwar damit umgehen
können, drauf verlassen würde ich mich aber dennoch nicht.

Beide Methoden haben ihre Nachteile. Für mich haben aber SIDs in URLs
deutlich mehr Nachteile als in Cookies, weswegen ich _ausschließlich_
letztere Methode verwende. Keine Cookies, keine Kekse. Oder so.

Micha

On Thu, 11 Oct 2007 22:22:09 +0200 Adrian Ebeling wrote:
> Gegen Datenklau habe ich eine billige IP-Sicherung. Es ist zwar klar
> dass das nicht gerade sicher ist,

Es ist nicht nur eine Frage der Sicherheit. Ein ernstzunehmender
Prozentsatz der Besucher meiner Seiten kommt ueber staendig wechselnde
IP-Adressen (vermutlich Proxy-Verbuende oder aehnliches). Ich _hatte_
vor Jahren einmal so eine Pruefung in einer ernsthaften Applikation
(d.h. einer, wo die Benutzer angerufen haben, wenn sie aus der Sitzung
geworfen wurden, anstatt sich einfach zu verabschieden) und das sehr
schnell wieder bleibenlassen.

Seither gilt bei mir: ohne (Session-) Cookies keine Session. Darueber
hat sich bislang noch keiner beschwert. Es ist aber auch wirklich nur
_ein_ Cookie und eben eines mit auf die Session begrenzter Lebensdauer.

> Auch Cookies werden unverschlüsselt gesendet und viele Besucher haben
> Cookies deaktiviert.

Meiner Erfahrung nach _deutlich_ weniger, als mit wechselnden
IP-Adressen durch das Netz wandern.

Einziger Pluspunkt von Sessions in der URL waere in meinen Augen:
Mozilla/Firefox kann (jedenfalls unter Linux) nur ein Cookie gleichen
Namens zur gleichen Zeit halten. Damit ist es nicht moeglich, sich
gleichzeitig mit zwei User-IDs an einem System anzumelden, was bei der
Entwicklung durchaus stoerend ist.

Servus,
Stefan

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

2007! Das Jahr des versauten Aufstiegs von Stefan.
(Sloganizer)

..oO(Stefan Froehlich)

>Einziger Pluspunkt von Sessions in der URL waere in meinen Augen:
>Mozilla/Firefox kann (jedenfalls unter Linux) nur ein Cookie gleichen
>Namens zur gleichen Zeit halten. Damit ist es nicht moeglich, sich
>gleichzeitig mit zwei User-IDs an einem System anzumelden, was bei der
>Entwicklung durchaus stoerend ist.

Welcher Browser kann das überhaupt? I.d.R. gilt ein Cookie browserweit
und nicht nur bezogen auf das jeweilige Tab, was auch sinnvoll ist. Als
Entwickler hat man ohnehin mehrere Browser zur Verfügung. ;)

Micha

On Thu, 11 Oct 2007 23:47:39 +0200 Michael Fesser wrote:
> >Mozilla/Firefox kann (jedenfalls unter Linux) nur ein Cookie gleichen
> >Namens zur gleichen Zeit halten. Damit ist es nicht moeglich, sich
> >gleichzeitig mit zwei User-IDs an einem System anzumelden, was bei der
> >Entwicklung durchaus stoerend ist.

> Welcher Browser kann das überhaupt?

Traurig, aber wahr: wenn man den IE in mehreren Instanzen startet (also
nicht mit Ctrl-N, sondern ein neues Programm), dann klappt das. Mozilla
hingegen prueft beim Start auf laufende Instanzen, schickt dorthin eine
Nachricht und beendet sich danach selbst.

> I.d.R. gilt ein Cookie browserweit und nicht nur bezogen auf das
> jeweilige Tab, was auch sinnvoll ist. Als Entwickler hat man ohnehin
> mehrere Browser zur Verfügung. ;)

Isch will aber nicht fuer jeden Account einen anderen Browsertyp
verwenden, das ist ja eklig... (der Workaround unter Linux ist,
mehrere Benutzeraccounts zu verwenden).

Servus,
Stefan

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

Das ist doch mal ein hurtiger Gedanke: Stefan!
(Sloganizer)

On Fri, 12 Oct 2007, Stefan Froehlich wrote:

> Traurig, aber wahr: wenn man den IE in mehreren Instanzen startet (also
> nicht mit Ctrl-N, sondern ein neues Programm), dann klappt das. Mozilla
> hingegen prueft beim Start auf laufende Instanzen, schickt dorthin eine
> Nachricht und beendet sich danach selbst.
> [...]

> Isch will aber nicht fuer jeden Account einen anderen Browsertyp
> verwenden, das ist ja eklig... (der Workaround unter Linux ist,
> mehrere Benutzeraccounts zu verwenden).

Wenn die Environment-Variable MOZ_NO_REMOTE den Wert 1 hat, läuft beim
Firefox auch ein zweites Exemplar ordentlich an. Ich verwende es dazu, um
aus einer Linux-Sitzung heraus den Firefox unter zwei verschiedenen
Identitäten (mit unterschiedlichen Zertifikaten) laufen zu lassen. Mit
Cookies habe ich keine Erfahrung, nehme aber an, dass das dann auch geht.

--
Helmut Richter

Adrian Ebeling wrote:
> Also ich bin kein Experte, aber ich mache es immer so, dass ich an jeden
> Link SID dranhänge, also z.B.
> echo <a href=\"irgendwas.php?".SID."\">Link</a>";

PHP macht das automatisch für Dich.

> In jedes Formular baue ich ein hidden-Feld ein, damit die SessionID auch
> bei Formularen weitertransportiert.

PHP macht das automatisch für Dich.

> Hat der Besucher Cookies aktiviert,
> ist die Konstante SID leer und die Url bleibt "sauber".

PHP macht das automatisch für Dich.

> Gegen Datenklau
> habe ich eine billige IP-Sicherung.

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

> Fremden Variablen muss grundsätzlich misstraut werden. Aber ein
> Sicherheitsgewinn durch Cookies gibt es meines Erachtens auch nicht.
> Auch Cookies werden unverschlüsselt gesendet und viele Besucher haben
> Cookies deaktiviert.

Ein Sicherheitsgewinn durch verwendung von Cookies existiert, jedenfalls
gegenüber einer Session-ID die in URLs weitergegeben wird.

29.14. Soll die Session-ID in URL-Parametern oder Cookies gespeichert
werden?
http://www.php-faq.de/q/q-sessions-methode.html

Die Hinweise auf die Fallback-Klasse und andere Dinge über Sessions, auf die
dort verlinkt wird, sind mittlerweile haarsträubend veraltet.

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Kristian Köhntopp schrieb:

> Adrian Ebeling wrote:
>
>> Also ich bin kein Experte, aber ich mache es immer so, dass ich an jeden
>> Link SID dranhänge, also z.B.
>> echo <a href=\"irgendwas.php?".SID."\">Link</a>";
>
> PHP macht das automatisch für Dich.

Wäre dem so, wäre das ein gewaltiger Minuspunkt für PHP.

PHP hängt die ID nur dann an die URL, wenn es in obiger Form dazu
aufgefordert wird (und Cookies deaktiviert sind). Und das ist auch gut
so: Ich will nicht an _jedem_ Link die Session-ID kleben haben, sondern
möchte das selber bestimmen können.

>> In jedes Formular baue ich ein hidden-Feld ein, damit die SessionID auch
>> bei Formularen weitertransportiert.
>
> PHP macht das automatisch für Dich.

Komisch. Ich finde bei mir kein "hidden-Feld", welches die SID enthält.

>> Hat der Besucher Cookies aktiviert,
>> ist die Konstante SID leer und die Url bleibt "sauber".
>
> PHP macht das automatisch für Dich.

Das weiß Adrian. Deshalb hat er das ja auch geschrieben.

Gruß. Claus

Kristian K=C3=B6hntopp schrieb:
> Adrian Ebeling wrote:
>> In jedes Formular baue ich ein hidden-Feld ein, damit die SessionID au=
ch
>> bei Formularen weitertransportiert.
>
> PHP macht das automatisch f=C3=BCr Dich.

Und zerhaut, sofern man es verwendert, das XHTML dabei. Zumind. frueher
wurde das Hidden nicht geschlossen. <hidden ... />

Des weiteren haettest du erwaehnen sollen das PHP es automatisch macht
wenn TRANS_SID aktiviert ist.

Gruss
Joerg

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

Michael Fesser schrieb:
> Hidden-Felder gehen eben nur mit Formularen, sonst nicht. Ich brauche
> Sessions aber f=C3=BCr weit mehr als nur f=C3=BCr Formulare. Schon ein =
einfaches
> Loginsystem f=C3=BCr gesch=C3=BCtzte Bereiche auf einer Website w=C3=A4=
re mit diesem
> Ansatz nicht praktikabel realisierbar. Au=C3=9Fer nat=C3=BCrlich, man s=
topft jede
> Seite komplett in ein Formular und nutzt nur Submit-Buttons anstelle vo=
n
> Links, aber wer will das schon?

A) Wozu sollte man sonst noch Sessions ben=C3=B6tigen au=C3=9Fer f=C3=BCr=
Formulare?
B) Warum nicht Praktikabel/Inwiefern Sollte das nicht Funktionieren?

Genau das ist es worauf ich hinaus will! Was ist daran so schlecht,
schlimm geschweige denn *unsicher*, wenn man ein Sticky-Form macht,
also eine Website die ein rekursives Formular aufbaut
(Eine Seite =3D Ein Formular) und die Navigation dann mit Buttons
anstatt Links realisiert? Nat=C3=BCrlich werden die Inhalte dank
Templates variieren, alles andere h=C3=A4tte ansonsten schlie=C3=9Flich
keinen Sinn.

Wenn man eine Seite hat die Beispielsweise eine fremde oder eine mit
statischem bzw. nicht relevanter Nachverfolgung aufrufen will z.B.
des Impressums, oder einer Linksammlung, kann man immer noch einen
Link verwenden. Sobald man jedoch irgendeine Art von Funktionalit=C3=A4t
an die Seite kn=C3=BCpft ist klar das eine SessionID zwingend ist,
egal welcher Methode man sich bedient.

Mir geht es dabei einzig und alleine um die *Sicherheitsrelevanz*
der unterschiedlichen Methoden (URL, Cookie, Hidden). =C3=84ndern
l=C3=A4sst sich alles egal bei welcher Methode (solange die Seite
nicht verschl=C3=BCsselt ist), somit kann man doch nicht wirklich
von Sicherheit reden, ergo m=C3=BCsste es doch im Prinzip egal sein
welcher Methode man sich bedient, sofern eine bestimmte Methode an
sich keine Sicherheitsprobleme aufwirft, wie dies z.b. bei URL's der
falls ist, darum scheiden URL-SID's f=C3=BCr mich kategorisch aus
(Thema Session-klau durch Logs, Referer, {transparente} Proxys).
--
Gru=C3=9F Martin

Joerg Behrens wrote:
> Und zerhaut, sofern man es verwendert, das XHTML dabei. Zumind. frueher
> wurde das Hidden nicht geschlossen. <hidden ... />

PHP 5.2.0 (+ suhosin) generiert

<input type="hidden" name="PHPSESSID"
value="2b6ck7h2o4v11pus2he1htffv3or792f" />

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Claus Reibenstein wrote:
>>> Also ich bin kein Experte, aber ich mache es immer so, dass ich an jeden
>>> Link SID dranhänge, also z.B.
>>> echo <a href=\"irgendwas.php?".SID."\">Link</a>";
>>
>> PHP macht das automatisch für Dich.
>
> Wäre dem so, wäre das ein gewaltiger Minuspunkt für PHP.

Genau genommen macht PHP es noch automatischer.

Wenn session.auto_start = 1 ist, wird session_start() automatisch aktiviert.
Das ist empfehlenswert, denn so sind auch persistente Objekte möglich.

Wenn session.use_cookies = 1 ist, wird PHP versuchen, die Session mit einem
PHPSESSID abzufahren. Genau genommen wird session.name als Name für den
Cookie verwendet, und man kann noch einen Haufen weiterer Parameter
einstellen. Im Grunde ist nur wichtig, daß man session.cookie_lifetime = 0
läßt, denn dann werden Session-Cookies verwendet.

Session-Cookies unterscheiden sich von gewöhnlichen Cookies in mehrfacher
Hinsicht:

1. Sie haben keine Expire-Zeit, sondern leben implizit so lange wie die
Instanz des Browsers, in der sie gesetzt sind. Dadurch werden sie nicht auf
Platte gespeichert (können also nur eingeschränkt zum Usertracking
verwendet werden) und sie brauchen nicht refreshed zu werden.

Gewöhnliche Cookies haben eine Lifetime, nach deren Ablauf der lokale
Browser sie expired. Daher müssen sie bei jedem Request neu gesetzt werden,
um die Expire-Zeit zu refreshen und den Ablauf der Session zu verhindern.

2. Viele moderne Browser haben getrennte P3P Security Policies für
Session-Cookies und gewöhnliche Cookies. In der Regel sind die Chancen,
Session Cookies setzen zu dürfen höher als die Chancen, gewöhnliche Cookies
setzen zu dürfen.


Wenn das mit dem Setzen des Cookies nicht gelingt (und
session.use_only_cookies = 0 ist und session.use_trans_sid = 1 ist), wird
PHP mit Hilfe von Output Buffering das generierte PHP einfangen und
modifizieren. Es wird eine Reihe von Tags um seine Session-ID automatisch
erweitern.

Welche Tags das sind, steht in url_rewriter.tags. Meist steht das
auf "a=href,area=href,frame=src,input=src,form=fakeentry".
Das "form=fakeentry" ist es, das das Hidden-Feld generiert.

So wird

<?php
if (! isset($_SESSION['counter']) )
$_SESSION['counter'] = 1;
else
$_SESSION['counter'] ++;

echo "<h1>The Value is {$_SESSION[counter]}</h1>";
?>
Reload
<form action="index.php" method="post">
<input type="text" name="name" value="" />
<input type="submit" name="sub" value="Los!" />
</form>

zu

<h1>The Value is 7</h1><a
href="index.php?PHPSESSID=te1jn3necla63c1bkv8ekkt2aagprb6h"> Reload</a>
<form action="index.php" method="post"><input type="hidden" name="PHPSESSID"
value="te1jn3necla63c1bkv8ekkt2aagprb6h" />
<input type="text" name="name" value="" />
<input type="submit" name="sub" value="Los!" />
</form>

Beachte das nach dem "<form>"-Tag eingefügte hidden-Feld "PHPSESSID".


(Config:

session.auto_start = 1
session.use_cookies = 1
session.use_only_cookies = 0
session.use_trans_sid = 1
session.cookie_lifetime = 0
url_rewrite.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
)

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Stefan Froehlich wrote:
> Es ist nicht nur eine Frage der Sicherheit. Ein ernstzunehmender
> Prozentsatz der Besucher meiner Seiten kommt ueber staendig wechselnde
> IP-Adressen (vermutlich Proxy-Verbuende oder aehnliches).

Dies betrifft _alle_ AOL-Benutzer und alle Benutzer von T-Online, die den
T-Online Proxy verwenden.

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Martin Parusel meinte:

> A) Wozu sollte man sonst noch Sessions benötigen außer für Formulare?

Ein Benutzer loggt sich (über ein Formular) ein. Alle weiteren Seiten
will er ebenfalls registriert besuchen. Und diese Seiten werden
günstigerweise über simple Anchors und nicht als Links verkleidete
Formulare angesprungen.


> B) Warum nicht Praktikabel/Inwiefern Sollte das nicht Funktionieren?

S.o. Aber Michael hatte das schon erklärt.

> Genau das ist es worauf ich hinaus will! Was ist daran so schlecht,
> schlimm geschweige denn *unsicher*, wenn man ein Sticky-Form macht,
> also eine Website die ein rekursives Formular aufbaut
> (Eine Seite = Ein Formular) und die Navigation dann mit Buttons
> anstatt Links realisiert? Natürlich werden die Inhalte dank
> Templates variieren, alles andere hätte ansonsten schließlich
> keinen Sinn.

Links sind Links und Formularelemente sind Formularelemente. Mit all
ihren Besonderheiten (fängt schon bei der Formatierung an). Bei jeder
Vor-Zurück-Navigation wird der Benutzer darauf hingewiesen, dass seine
Daten erneut gesendet werden - da wird er blöd schauen. Und woanders
surfen gehen. Vom aufgeblähten Markup und einem (wahrscheinlichen)
serverseitigen Overhead ganz zu schweigen.

> Wenn man eine Seite hat die Beispielsweise eine fremde oder eine mit
> statischem bzw. nicht relevanter Nachverfolgung aufrufen will z.B.
> des Impressums, oder einer Linksammlung, kann man immer noch einen
> Link verwenden.

Und deine "Identifizierung" ist flöten. Super.

> Mir geht es dabei einzig und alleine um die *Sicherheitsrelevanz*

[snip]

Nachdem alles ziemlich gleich (un)sicher ist, nimmt man das, was für den
Zweck explizit vorgesehen wurde und das sind Cookies. Fertig.

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

Michael Fesser wrote:
> Vor Jahren war dies eine beliebte Methode, um an gültige Session-IDs der
> großen Freemailer wie GMX und Web.de zu kommen und Postfächer zu klauen.

Das ist jetzt zwar offtopic, aber:

Dazu kommt, daß die meisten dieser Account-Diebstähle auch transitiv sind.
Wenn man zum Beispiel ebay-Benutzer ist und sich dort - wie auch immer -
seinen Account (mit Paßwort, nicht mit Session-ID) klauen läßt, dann steht
da ja eine Mailadresse drin.

Der handelsübliche Fishing-Bot wird nun mit dieser Mailadresse und dem
geklauten eBay-Paßwort bei der betreffenden Freemail-Adresse (von GMX,
web.de, Arcor oder was auch immer) einloggen und hat so zusätzlich zum
eBay-Account auch etwa den web.de Account mit geklaut.

Die ganze Serie der Sober.?-Viren hat so große Accountlisten drin gehabt -
jeweils zwischen 1200 und 2000 Name-Paßwort-Paare.

Wenn also (grundsätzlich nachts um zwei Uhr deutscher Zeit) eine neue
Sober-Welle los ging, hat es etwa 300 Accounts bei web.de erwischt, deren
Paßworte geklaut werden. Wir haben diese Accounts meist automatisch
erkennen und disablen können, aber Sober hat noch mehr Accounts drin und
wechselt dann alle 2-4 Stunden auf den nächsten Satz unverbrannte Accounts.

Sober verwendet diese Accounts, mit mit Hilfe von SMTP AUTH die recht
leistungsfähigen Mailer der diversen Webmail-Hoster als Spamrelays zu
mißbrauchen.

> Beide Methoden haben ihre Nachteile. Für mich haben aber SIDs in URLs
> deutlich mehr Nachteile als in Cookies, weswegen ich _ausschließlich_
> letztere Methode verwende. Keine Cookies, keine Kekse. Oder so.

Das ist die empfohlene Methode.

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Martin Parusel wrote:
> Genau das ist es worauf ich hinaus will! Was ist daran so schlecht,
> schlimm geschweige denn *unsicher*, wenn man ein Sticky-Form macht,
> also eine Website die ein rekursives Formular aufbaut
> (Eine Seite = Ein Formular) und die Navigation dann mit Buttons
> anstatt Links realisiert?

Du bist in allen Suchmaschinen unsichtbar.

Es ist aber egal - wenn Du den Betrieb ohne Cookies gestatten willst, ist
PHP in der Lage, das für Dich vollkommen transparent und automatisch zu
realisieren.

Kris

--
Kristian =?iso-8859-15?q?Köhntopp?= <kris [at] xn--khntopp-90a.de>

Kristian Köhntopp schrieb:
> Joerg Behrens wrote:
>> Und zerhaut, sofern man es verwendert, das XHTML dabei. Zumind. fruehe=
r
>> wurde das Hidden nicht geschlossen. <hidden ... />
>
> PHP 5.2.0 (+ suhosin) generiert
>
> <input type=3D"hidden" name=3D"PHPSESSID"
> value=3D"2b6ck7h2o4v11pus2he1htffv3or792f" />

Du hast Recht. Auch ohne suhosin generiert PHP nun "bessere" hidden field=
s.

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

Stefan Froehlich wrote:
> On Thu, 11 Oct 2007 22:22:09 +0200 Adrian Ebeling wrote:
>
>>Gegen Datenklau habe ich eine billige IP-Sicherung. Es ist zwar klar
>>dass das nicht gerade sicher ist,
>
>
> Es ist nicht nur eine Frage der Sicherheit. Ein ernstzunehmender
> Prozentsatz der Besucher meiner Seiten kommt ueber staendig wechselnde
> IP-Adressen (vermutlich Proxy-Verbuende oder aehnliches). Ich _hatte_
> vor Jahren einmal so eine Pruefung in einer ernsthaften Applikation
> (d.h. einer, wo die Benutzer angerufen haben, wenn sie aus der Sitzung
> geworfen wurden, anstatt sich einfach zu verabschieden) und das sehr
> schnell wieder bleibenlassen.
>
> Seither gilt bei mir: ohne (Session-) Cookies keine Session. Darueber
> hat sich bislang noch keiner beschwert. Es ist aber auch wirklich nur
> _ein_ Cookie und eben eines mit auf die Session begrenzter Lebensdauer.
>
>
>>Auch Cookies werden unverschlüsselt gesendet und viele Besucher haben
>>Cookies deaktiviert.
>
>
> Meiner Erfahrung nach _deutlich_ weniger, als mit wechselnden
> IP-Adressen durch das Netz wandern.
>
> Einziger Pluspunkt von Sessions in der URL waere in meinen Augen:
> Mozilla/Firefox kann (jedenfalls unter Linux) nur ein Cookie gleichen
> Namens zur gleichen Zeit halten. Damit ist es nicht moeglich, sich
> gleichzeitig mit zwei User-IDs an einem System anzumelden, was bei der
> Entwicklung durchaus stoerend ist.

Das ist doch ganz einfach zu lösen:
1. Firefox und Mozilla können mehrere Profile haben. Pro Profil
hast Du dann eine Session.

2. Unter Linux kannst Du auch Dich auch noch parallel als zweiter
User anmelden und kannst einen weiteren Browser starten.

3. Von meinem Entwicklungsrechner aus greife ich auch auf einen VMware
Server zu. Das ermöglicht es nicht nur Firefox, sondern auch IE in
verschiedenen Fassungen zu testen (IE 6.0 und IE 7.0).

4. Mein Entwicklungsapache bietet die Möglichkeit ein und die selbe
Webseite einfach per symlink auch unter einem anderen Namen
anzusprechen. Somit kann ich dann wiederum auch andere Cookies
benutzen. (Ganz abgesehen von der Tatsache, dass ich über unter
schiedliche Ports auch unterschiedliche PHP/Apache-Versionen
nutzen kann)

Hallo Welt,

ich hatte mich noch ein wenig weiter privat per eMail mit Gregor
=C3=BCber dieses Thema unterhalten und bei seinem Argument...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Formulare auszuwerten ist IMO immer komplizierter als einen simplen
Link - den muss ich nicht auswerten.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2E..bin ich schlussendlich absolut =C3=BCberzeugt worden, *R-E-S-P-E-C-T=
*!!!

Ich gebe zu, ich mache es anderen nicht Leicht mich von etwas zu
=C3=BCberzeugen, doch das hat seine Gr=C3=BCnde. Allerdings ist dieses
vom Gegenteil =C3=BCberzeugen genau das worauf ich gehofft habe,
als ich dieses Thema in der NG begonnen habe! Den wahren Experten
erkennt man eben an =C3=9Cberzeugenden Argumenten und nicht daran,
das er blindlings mit der Masse schwimmt :)

Ich bedanke mich bei allen beteiligten, f=C3=BCr die M=C3=BChe und Kritik=
zum
Thema, besonderst bei Gregor und die Energie die er daf=C3=BCr in den
privaten Mails aufgebracht hat! Sei noch erw=C3=A4hnt, ich sehe Kritik
nicht als etwas negatives, im Gegenteil, denn man kann daraus nur lernen!=

In diesem Sinne... Danke f=C3=BCr die =C3=9Cberzeugung!

P.S: Gregor hatte nichts dagegen das ich sein Kommentar aus einer
privaten Mail hier poste, nicht das jemand denkt ich w=C3=BCrde
sowas ohne Einverst=C3=A4ndnis machen, selbst wenn es sich dabei
um etwas handelt das meiner Meinung nach kein Problem sein sollte
--
----
------ Gru=C3=9F Martin -------------------------------------------------=
--
----
--