Sichere Übertragung durch HTTPS und Session-ID

[Uli]

Hallo,

ich habe eine sehr spezielle Frage, auf die ich in diesem Archiv trotz
Recherche keine Antwort finden konnte:

Hab ich ein Problem, wenn ich Daten mit HTTP über SSL (mit 128 bit)
verschlüssele, aber eine Session-ID mit URL-Rewriting einsetze, welche ja
in der URL prinzipiell lesbar ist (Referer,zwischengeschaltete Server,etc.)?

Etwas konkreter:

Reicht es aus, während der Gültigkeitsdauer der Session-ID, diese
mitzuschneiden und wieder einzuspielen, um in die Sitzung einzubrechen, und
sich als der ursprüngliche Nutzer auszugeben ? Oder greift hier auch noch
die SSL-Verschlüsselung zwischen Client und Server - diese Kommunikation
habe ich ja damit nicht gebrochen, oder ?

Sprich, bewirke ich durch Erzeugen von neuen Datenpaketen und der so
"gewonnenen" Session-ID sinnvolle Daten oder aufgrund der
HTTPS-Verschlüsselung nur Datenmüll ?

Vielen Dank für sachdienliche Hinweise und vieleicht eine möglichst genaue
Erklärung. Wo kann ich "offizielle" Informationen hierzu nachlesen ?

PS: Hoffentlich fühlt sich keiner genervt, das hier vieleicht ein 0815-Thema
hinterfragt wird.

Gruß Uli

[xwolf]

Hi,

ich habe eine sehr spezielle Frage, auf die ich in diesem Archiv trotz
Recherche keine Antwort finden konnte:

Klar, weil die Frage nicht allgemein beantwortbar ist.

Hab ich ein Problem, wenn ich Daten mit HTTP über SSL (mit 128 bit)
verschlüssele, aber eine Session-ID mit URL-Rewriting einsetze, welche ja
in der URL prinzipiell lesbar ist (Referer,zwischengeschaltete Server,etc.)?

Kommt darauf an, wie du die Session-IDs erstellst und verwaltest.
Siehe unten.

Etwas konkreter:

Reicht es aus, während der Gültigkeitsdauer der Session-ID, diese
mitzuschneiden und wieder einzuspielen, um in die Sitzung einzubrechen, und
sich als der ursprüngliche Nutzer auszugeben ? Oder greift hier auch noch
die SSL-Verschlüsselung zwischen Client und Server - diese Kommunikation
habe ich ja damit nicht gebrochen, oder ?

Die Uebertragung ist nach jeder einzelnen Seite, nach jedem Formsubmit beendet/abgebrochen.
Eben deswegen benutzt durch doch Session-IDs.
Damit du den User beim nächsten Aufruf gleich wiedererkennst.

Sprich, bewirke ich durch Erzeugen von neuen Datenpaketen und der so
"gewonnenen" Session-ID sinnvolle Daten oder aufgrund der
HTTPS-Verschlüsselung nur Datenmüll ?

Die HTTPS-Verschluesselung hat nichts mit deinen Session-IDs zu tun!

Die Verschluessung ist nur das was es heisst: Eine Verschluesselung.
Auf dem Web vom Client zum Server bekommt jemand, der die Verbindung abhoert nur Datenmüll zu sehen.
Egeal ob es Session-IDs sind oder reale Namen und Daten.

Die Session-Id benutzt du bei einer Transaktion in der regel für was anedres. Naemlich zum Beispiel bei einer Benutzerdatenbank könnte darin die ID des Benutzers in der DB sein.

Wie acuh immer: Die Frage, wie sicher all das ist, ist die Kernfrage?
Nun: Wenn jemand anhand der Session-IDs erkennen kann, wie die Session-IDs gebildet werden, DANN kannst du es auch alles offen lassen :)

Beispiel: Deine Session-IDs sind einfach fortlaufende Nummern der Ids der Benutzer aus der Datenbank.

Wenn nun ein neuer User A die ID 123 bekommt und im Quellcode dann sieht und er als nächstes ueber einen anderen Provider reingeht und sieht, als neuer Nutzer B die ID 124 bekommt, was wird er dann wohl schliessen?
"Heureka: Er weiss, dass es sehr wahrscheinlich ist, dass es 122 andere User gibt, die die IDs 1 - 122 nutzen :)

Und wenn man die Aktionen der User nur noch mit IDs macht, kann der also für die anderen User ne Menge Mist bauen.

Ciao,
  Wolfgang

[Uli]

Hallo,

erst mal vielen Dank für die (schnellen) Antworten ...

Ich muß noch mal etwas ausholen. Für das "Aufbauen" von Sitzungen gibt es ja
3 Möglichkeiten:

- Cookie
 - URL-Rewriting
 - Hidden Fields

Bei der zweiten Variante wird die Session-ID ja in der URL mitgeführt.

Kern meiner Frage hätte wohl sein müssen:

Geht die URL bei HTTPS (und mit ihr eine mögliche session-id) im Klartext
über die Leitung oder ist sie Bestandteil der HTTPS-Verschlüsselung ?

Mir geht es hier um das Abhören durch Dritte. Start und Zeilssystem können
wir dabei mal außen vor lassen.

Bei den Session-Alternativen Cookie und Hidden Fields ist es offensichtlich so.

Wo könnte man das Thema (gerne leicht verständlich) nachlesen ?

Gruß Uli

PS: Gehört natürlich hier hin ...

[xwolf]

Hi,

erst mal vielen Dank für die (schnellen) Antworten ...

Ich muß noch mal etwas ausholen. Für das "Aufbauen" von Sitzungen gibt es ja
3 Möglichkeiten:

• Cookie
• URL-Rewriting
• Hidden Fields

Bei der zweiten Variante wird die Session-ID ja in der URL mitgeführt.

Kern meiner Frage hätte wohl sein müssen:

Geht die URL bei HTTPS (und mit ihr eine mögliche session-id) im Klartext
über die Leitung oder ist sie Bestandteil der HTTPS-Verschlüsselung ?

Praktisch ja über die Referer-Variable.
Wenn du zum Beispiel mal auf deiner Webseite einen Counter einbaust, der notiert, wo laut Referer die Leute vorher waren, wirst du wahrscheinlich auch sowas finden:
https://webmail.providername.blub/read/5124365425665/121

Wenn du dann darauf klickst, hast du dann bei einem *schlechten*
Dienst die Mail von einem User des Webmaildienstes vor Augen.
Bei einen normalen Webmaildienst wird dagegen hoffentlich eine Fehlermeldung kommen.

Hiergegen sollte man im wesentlichen eines machen: Die Variablen
mit der Methode POST uebertragen anstelle von GET.
Das ist zwar in der Bedienung schlechter wenn die Leute den Back-Button betaetigen, aber naja...
Hier kann man ja dann andere Moeglichkleiten einbauen.

Mir geht es hier um das Abhören durch Dritte. Start und Zeilssystem können
wir dabei mal außen vor lassen.

Bei den Session-Alternativen Cookie und Hidden Fields ist es offensichtlich so.

Das kommt bei den Hidden Fields auf die Methode drauf an.
Es gibt fast keinen Unterschied zwischen der Angabe der ID in
der URL oder als Hidden Fields bei der GET-Methode.
Genaugenommen wird bei der GET-Methode schliesslich ja auch alles in der URL codiert.

Bei Cookies stelt sich neben der Sicherheit auch die Frage, inwieweit man sich auf diese verlassen kann. Was, wenn Leute auf Firmenbrowsern arbeiten, bei denen Cookies abgeschaltet ist?

Du hast bei der URL-methode nur zustaetzlich noch die Moeglichkeit mit PATH_INFO zu arbeiten.

Wo könnte man das Thema (gerne leicht verständlich) nachlesen ?

»»

Es gibt diverse Buecher zum Thema Security von Servern etc.
Fuer Web-Security selbst ist mir jedoch kein *aktuelles* Buch bekannt,
welches ich empfehlen kann. Allerhoechstens das Buch von Lincoln Stein
"Web Security".
Jedoch ist dies schon ein paar Jaehrchen alt und berucksichtigt daher nicht unbedingt neueste Entwicklungen.

Ich wuerde eher empfehlen, dass du einfach mal im netz dazu rumschaust und fragst, wie du es schon getan hast.

Bei mir findest du zum Thema ein paar Artikel, aber die beschaeftigen sich mehr mit CGI an sich. Ggf waere dieser interessant: http://www.xwolf.de/artikel/cgisec.shtml .

Ciao,
  Wolfgang

[Uli]

Hallo Wolfgang,

wenn ich in einer HTTPS-gesicherten Webpräsenz auf externe Links verzichte,
hab ich das Referer-Problem also nicht mehr. Erst mal vielen Dank für
diesen Hinweis.

Aber mir ist folgendes noch nicht ganz klar:

Wie ist es jetzt noch mal mit der HTTPS-Übertragung bei

- URL-Rewriting bzw.
 - Hidden Fields und GET-Methode (Parameter-Übergabe per URL) ?

Geht die URL bei HTTPS (und mit ihr eine mögliche session-id) im Klartext
über die Leitung oder ist sie Bestandteil der HTTPS-Verschlüsselung ?

Muß ich die Referer-Variable als Parameter im HTTP-Protokol ansehen, die
immer mitgeführt wird und auf die Vorgängerseite verweist - und dabei
unverschlüsselt übermittelt wird - oder werden auch diese Felder durch SSL
mitverschlüsselt (also bei HTTPS) ?

Oder bezog sich die Aussage

Praktisch ja über die Referer-Variable.

nur auf das obige Thema mit einer (externen) Verlinkung ?

Gruß Uli

[Michael Schröpl]

Hi Uli,

Geht die URL bei HTTPS (und mit ihr eine mögliche session-id) im Klartext
über die Leitung oder ist sie Bestandteil der HTTPS-Verschlüsselung ?

ich kann Deine Frage leider nicht beantworten (die Netscape-SSL-Doku
ist mir zu "leitungsnah") - ich kann sie nur "übersetzen":

Wird bei HTTPS das gesamte HTTP-Paket (HTTP-Header plus Body) mit SSL
verschlüsselt oder nur der Body-Teil?

Alle von Dir genannten "kritischen" Informationen (angeforderter URL
inklusive GET-Parametern, Referrer, Cookie) sind Bestandteil des HTTP-
Headers - für sie muß die Antwort also immer gleich ausfallen.

Falls die Antwort lautet "das gesamte Paket" (womit ich eigentlich
rechne, alles andere wäre m. E. "zu kurz gesprungen"), dann sind alle
genannten Session-Methoden gleichermaßen geschützt.
Lautet die Antwort "nur der Body-Teil", dann wären alle im HTTP-Header-
Abschnitt enthaltenen Informationen belauschbar - was ich mir nicht so
recht vorstellen kann (eben weil gerade dort wirklich interessante In-
formationen für einen potentiellen Angreifer stehen).

Relevant wird die Frage nur, wenn Du Informationen in den Body ver-
schieben würdest, was im Falle einer Übertragung via POST statt GET
der Fall wäre. Das hätte allerdings den Nachteil, daß Du keine normalen
Links mehr verwenden darfst, sondern Deine Seiten mit Formularen ver-
knüpfen mußt (Links verwenden immer GET, bei Formularen gibst Du die
Methode im <form>-Tag an).

Viele Grüße
      Michael

P.S.: Der Begriff "hidden" für Formular-Parameter bringt Dir in Sachen
      Sicherheit übrigens nichts: "Versteckt" sind diese Informationen
      nur für den Betrachter der Seite, nicht für den Belauscher der
      Leitung.

[Henryk Plötz]

Moin,

Hab ich ein Problem, wenn ich Daten mit HTTP über SSL (mit 128 bit)
verschlüssele, aber eine Session-ID mit URL-Rewriting einsetze, welche ja
in der URL prinzipiell lesbar ist (Referer,zwischengeschaltete Server,etc.)?

Wenn die Inhalte eine HTTPS-Verbindung auf Zwischenrechnern lesbar sind, hast du ohnehin ein Problem. ;-)
Generell schützt HTTPS aber die gesamte Verbindung, so dass niemand irgendetwas darin lesen kann, seien es nun die Dateninhalte oder die URLs. Wenn du nicht grade Windows einsetzt, was zur Zeit ein paar Probleme mit SSL-Zertifikaten hat (zumindest laut Microsoft ist das aktuelle IE-Problem was im Prinzip beliebiges Abhören von SSL-Verbindungen ermöglicht nämlich kein IE- sondern ein Betriebssystemproblem), brauchst du dir über die Sicherheit der Übertragung selbst eigentlich keine Gedanken zu machen, wenn es denn wirklich 128 Bit sind.

Problematisch wird es dann erst an den beiden Endpunkten: Kann jemand auf das Access-Log des Webservers mit den darin enthaltenen Session-IDs zugreifen? Oder gar auf den Speicher in dem die Sessiondaten gehalten werden? Ist der Rechner des Benutzers hinreichend vertrauenswürdig (keine Trojaner oder Keylogger), und wird die Session immer ordnungsgemäß gelöscht? (Das ist besonders wichtig, wenn andere Zugriff auf den selben Rechner haben und evt. in die URL-History schauen könnten.) Und natürlich sollte dein Angebot selbst keine direkten externen Links enthalten, sonst kommt der Referer wieder ins Spiel.

--
Henryk Plötz
Grüße von der Ostsee

[Uli]

Hallo,

erst mal vielen Dank für die (schnellen) Antworten ...

Ich muß noch mal etwas ausholen. Für das "Aufbauen" von Sitzungen gibt es ja
3 Möglichkeiten:

- Cookie
 - URL-Rewriting
 - Hidden Fields

Bei der zweiten Variante wird die Session-ID ja in der URL mitgeführt.

Kern meiner Frage hätte wohl sein müssen:

Geht die URL bei HTTPS (und mit ihr eine mögliche session-id) im Klartext
über die Leitung oder ist sie Bestandteil der HTTPS-Verschlüsselung ?

Mir geht es hier um das Abhören durch Dritte. Start und Zeilssystem können
wir dabei mal außen vor lassen.

Bei den Session-Alternativen Cookie und Hidden Fields ist es offensichtlich so.

Gruß Uli