Security-Konzept -> Mies oder Gut? -> Vorschlaege?

[Aqua]

Hallo!

Derzeit versuche ich, ein Kundenmenü sicherer zu bekommen als es derzeit ist.
Sicherheit würde ich gerne folgendermaßen herstellen:

****
User loggt sich ein,
es werden 2 Session-ID's erzeugt.

Die erste Session-ID wird im Cookie gespeichert,
die zweite im Query-String.

Diese beiden ID's werden natürlich noch zusaetzlich in der Datenbank gespeichert.

Weiters werden in der Datenbank die IP-Adresse gespeichert,
sowie Referrer und Browser des Users.

Wenn sich der User dann weiter durchklicken will auf der Homepage,
und auch nur ein Wert passt nicht,
wird er sofort ausgeloggt!!

Bei jedem Mal, wo der User auf irgendeinen Link klickt,
wird - nachdem gecheckt wurde ob alle Daten passen -
sofort wieder eine neue Session-ID für den Cookie
und eine weitere für den Querystring erzeugt.

Weiters kommt SSL zum einsatz.

Viele Leute meinten bisher schon,
dass mich das vor "the man in the middle" auch nicht beschützt,
und generell nicht sicher sei.

Als absolute Alternativ-Methode stünde noch
das CPAN-Modul "CGI::Session" zur verfügung.

Meine Fragen

1. Was muß ich an meinem Konzept veraendern?
2. Ist CGI::Session sicherer als das was ich von Hand mache?
3. Muß ich meine Idee Komplett schmeißen oder was geht?
4. Wie würdest ihr halbwegst gute Sicherheit herstellen?

Vielen Lieben Dank!
Aqua ;o)

PS.: Dass es 100%ige Sicherheit in der Hinsicht
     nicht geben kann weiß ich!

[Helmut Weber]

Hallo Aqua,

Die erste Session-ID wird im Cookie gespeichert,
die zweite im Query-String.

Die Session-ID sollte sowieso "zufällig" erzeugt werden. Außerdem sollte eine Session nach einer gewissen Zeit ohne aktivität wieder gelöscht werden. D.h. _eine_ Session-ID im Query-String ist meiner Ansicht nach sicher genug (was vorraussetzt, das die Session-ID nicht zu einfach aufgebaut ist).

Weiters werden in der Datenbank die IP-Adresse gespeichert,
sowie Referrer und Browser des Users.

IP-Adresse kann Probleme geben, da mehrere User über eine IP-Adresse mit dem INternet verbunden sein können, oder die IP-Adresse wärend einer Sitzung sich ändern kann (Wenn sich die Internetverbindung z.B. nach einer gewissen Zeit automatisch abwählt)

Weiters kommt SSL zum einsatz.

Dadurch wird nur der Datenverkehr zwischen Browser und Server verschlüsselt. Bietet also nur mehr Sicherheit für die Daten die hin- und her-geschickt werden und nicht für die Sicherheit der Session.

Viele Leute meinten bisher schon,
dass mich das vor "the man in the middle" auch nicht beschützt,
und generell nicht sicher sei.

Ich schliesse mich den "vielen Leuten" an ;)

Meine Fragen

1. Was muß ich an meinem Konzept veraendern?
2. Ist CGI::Session sicherer als das was ich von Hand mache?
3. Muß ich meine Idee Komplett schmeißen oder was geht?
4. Wie würdest ihr halbwegst gute Sicherheit herstellen?

Ich würde die 2. Session-ID in den Cookies weglassen. Die Session-ID für den Query-String sollte einen komplexen Aufbau aus Zahlen und Buchstaben haben und mindestens 10-stellig sein.
Eine Session-ID solltest Du nach einer gewissen Zeit ohne aktivitäten löschen, so das deine Datenbank nicht voll ist von benutzbaren Session-IDs.

Gruß
Helmut Weber

[Philipp Hasenfratz]

Halihallo Aqua

User loggt sich ein,
es werden 2 Session-ID's erzeugt.

Och nö... Warum denn zwei? - Um die Wahrscheinlichkeit um den Faktor 2 zu verringern?
Häng einfach ein bit mehr an die zufällig gewählte Session-ID und du hast das selbe
Ergebnis...

Die erste Session-ID wird im Cookie gespeichert,
die zweite im Query-String.

Und was ist mit Kunden ohne Cookies? - Bzw. Er öffnet in der zwischenzeit mehrere
andere Websiten und dein Cookie fällt aus der Liste der ersten 300? - Denn mehr
werden laut RFC nicht empfohlen.

Diese beiden ID's werden natürlich noch zusaetzlich in der Datenbank gespeichert.

Was meinst du mit ID? - Ich hoffe doch stark, dass dies keine normalen autoinc-Werte
sind, die sich einfach erraten lassen? - Ich hoffe, dass du MD5 verwendest und so einen
zufälligen 128-bit Schlüssel generierst...

Weiters werden in der Datenbank die IP-Adresse gespeichert,
sowie Referrer und Browser des Users.

Bringt nix.

Wenn sich der User dann weiter durchklicken will auf der Homepage,
und auch nur ein Wert passt nicht,
wird er sofort ausgeloggt!!

OK.

Bei jedem Mal, wo der User auf irgendeinen Link klickt,
wird - nachdem gecheckt wurde ob alle Daten passen -
sofort wieder eine neue Session-ID für den Cookie
und eine weitere für den Querystring erzeugt.

Die Idee halte ich für gut und sehr interessant. Bloss: Was, wenn der Kunde auf den
Browser-Zurück-Button klickt und dort noch die alten SessionKeys in dem QueryString
stehen? - Ende feuer, logout, warum fragt sich dann der Kunde?
Das liesse sich zwar alles über JS beheben... Sicherheitstechnisch mag das ein Vorteil
sein, aber programmiertechnisch und kundentechnisch bestimmt nicht.

Zudem: Wenn bei jedem Request der SessionKey (nicht -ID, bitte) ändert, wären Man in the
middle Attacken dennoch denkbar, nur müsste derjenige in der Mitte einfach schneller
sein, als dein Kunde... Aber die Wahrscheinlichkeit verringerst du damit.

Weiters kommt SSL zum einsatz.

OK.

Viele Leute meinten bisher schon,
dass mich das vor "the man in the middle" auch nicht beschützt,
und generell nicht sicher sei.

"Generell nicht sicher sei"? - Was haben sie denn für Kritik geäussert?

2. Ist CGI::Session sicherer als das was ich von Hand mache?

Die Funktionsweise von CGI::Session entnimm der Doku. Vergleiche deren Mechanismen mit
deinen. Vorweg: CGI::Session ist ein allgemeines Packet und genügt den meisten
Sicherheits-Anforderungen.

4. Wie würdest ihr halbwegst gute Sicherheit herstellen?

[pref:t=48537&m=264832] ff. vielleicht interessiert dich die Diskussion dort.

PS.: Dass es 100%ige Sicherheit in der Hinsicht
     nicht geben kann weiß ich!

leider wahr :-)

Viele Grüsse

Philipp

[Sven Rautenberg]

Moin!

Derzeit versuche ich, ein Kundenmenü sicherer zu bekommen als es derzeit ist.

Welche Angriffsmöglichkeiten hast du für den jetzigen Zustand herausgefunden? Nur wenn du weißt, wie man beim jetzigen Zustand angreifen kann, kannst du Methoden entwickeln, diese Lücken zu schließen.

Sicherheit würde ich gerne folgendermaßen herstellen:

****
User loggt sich ein,
es werden 2 Session-ID's erzeugt.

Zwei Session-IDs bringen genausoviel, wie eine Session-ID. Denn grundsätzlich gilt: Authentifizierung wird bei HTTP dadurch realisiert, dass der Client dem Browser mit jedem Request etwas mitsendet, was den Client authentifiziert. Das kann eine Username/Passwort-Kombi sein, oder eben die richtige (weil auf dem Server als "eingeloggt" registrierte) Session-ID.

Die einzige Angriffsmöglichkeit ist im Prinzip "Ausprobieren durch Raten". Du schaffst also mehr Sicherheit, indem du mehr Ratemöglichkeiten ermöglichst, so dass das Ausprobieren aller Kombinationen sehr lange dauert bzw. mit heutiger Hardware schlicht unmöglich in einem Menschenleben zu schaffen ist.

Wichtig ist dabei natürlich, dass das Raten wirklich in einem Raum passiert, in der keine Session-ID irgendwie häufiger vorkommt bzw. gar aufgrund von Analysen vorhergehender IDs abgeschätzt oder gar direkt berechnet werden kann.

Das größte Problem allerdings dürfte sein, dass du trotz aller Session-IDs (und dem ganzen restlichen Kram, den du noch realisieren willst), einen Punkt hast, der dir dein ganzes Konzept zum Einsturz bringen wird! Und zwar die zum Login benötigten Daten!

User sind faul. Sie wählen sich Passworte, die man leicht raten kann. Sie haben auch Usernamen, die nicht schwer herauszufinden sind. Wer also ein Login realisieren kann, indem er einen gültigen Usernamen und Passwort eingibt, der wird deine restliche Sicherheitsbarriere ganz einfach überwinden können, weil sie für den eingeloggten User eben keine Barriere ist.

Dagegen kannst du im Prinzip nur etwas tun, indem du die Usernamen und insbesondere die Passworte ziemlich lang machst, um sie gegen Rateversuche zu schützen. Aber du kannst nichts dagegen tun, dass die Benutzer das Passwort möglicherweise ungeschützt mit sich herumtragen oder es sogar fremden Personen verraten!

Aber im Detail noch ein paar Kommentare:

Die erste Session-ID wird im Cookie gespeichert,
die zweite im Query-String.

Das zwei Session-IDs nicht sicherer sind als eine, sondern im Prinzip nur als eine lange Session-ID betrachtet werden können, hatte ich erwähnt. Es ist für den Angreifer auch kein Problem, die eine lange Session-ID in zwei Teile zu teilen und den einen als URL-Parameter, den anderen als Cookie an deinen Server zu senden.

Weiters werden in der Datenbank die IP-Adresse gespeichert,
sowie Referrer und Browser des Users.

Referrer und Browser des Users sind ebenfalls Daten, die der Angreifer sich selbst aussuchen und manipulieren kann. Es ist im Prinzip eine Verlängerung der Session-ID, nur leider: Die IP kann sich ohne Zutun des Benutzers ändern. Deswegen ist deine Lösung in diesem Punkt schlecht.

Wenn sich der User dann weiter durchklicken will auf der Homepage,
und auch nur ein Wert passt nicht,
wird er sofort ausgeloggt!!

Und das wird die User ziemlich ärgern, wenn das häufiger passiert.

Bei jedem Mal, wo der User auf irgendeinen Link klickt,
wird - nachdem gecheckt wurde ob alle Daten passen -
sofort wieder eine neue Session-ID für den Cookie
und eine weitere für den Querystring erzeugt.

Das widerspricht dem System der Sessions. Eine Session-ID bleibt über die gesamte Dauer identisch, damit man den User wiedererkennen kann.

Weiters kommt SSL zum einsatz.

Das ist sehr positiv.

Viele Leute meinten bisher schon,
dass mich das vor "the man in the middle" auch nicht beschützt,
und generell nicht sicher sei.

Auf diese Leute solltest du dann einfach nicht hören.

Natürlich gibt es keine absolute Sicherheit. Aber nach meiner Meinung ist eine hinreichend lange Session-ID zusammen mit SSL vollkommen ausreichend.

Begründung: SSL selbst liefert dir eine gesicherte Verbindung zum Server. Diese Verbindung ist gegen Man-in-the-middle-Attacken gesichert! Niemand kann, ohne dem Benutzer aufzufallen (weil das Zertifikat seines Servers ein anderes ist als deins) unter _deinem_ Servernamen Dienste anbieten, die so aussehen wie deine, und damit Logindaten abgreifen. Mit SSL kannst du hinreichend sicher sein, dass niemand an diese Daten rankommt, außer der Benutzer und du.

Zweitens: Die übliche Session-ID-Länge beträgt 128 Bit (jedenfalls bei PHP). Verwendet wird (hoffentlich) ein Zufallswert. Das bedeutet: Die Login-Daten werden eingetauscht gegen eine Session-ID, die danach als Authentifizierungsmittel dient. Wer die ID kennt, gilt als eingeloggt.

Man muß also entweder Username und Passwort richtig raten, oder die Session-ID. Gehen wir mal davon aus, dass die Session-ID geraten werden soll. Ich hatte eine Überschlagrechnung unter anderem mal in </archiv/2002/6/13365/#m75077> gemacht - die sollte dich doch eigentlich überzeugen, dass 128 Bit Session-ID-Länge ausreichend sein dürften, oder?

Als absolute Alternativ-Methode stünde noch
das CPAN-Modul "CGI::Session" zur verfügung.

Das ist sicher eine gute Idee. Denn das Modul generiert mindestens so gute Session-IDs wie du, wahrscheinlich aber bessere, weil zufälligere.

- Sven Rautenberg

[Lude]

Hi,

PS.: Dass es 100%ige Sicherheit in der Hinsicht
     nicht geben kann weiß ich!

Du koenntest die gesamte "Umgebung" des Clients speichern und jeweils mit der gesendeten in ausgewaehlten Segmenten vergleichen.

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

PS.: Dass es 100%ige Sicherheit in der Hinsicht
     nicht geben kann weiß ich!
Du koenntest die gesamte "Umgebung" des Clients speichern und jeweils mit der gesendeten in ausgewaehlten Segmenten vergleichen.

Dir ist aber schon bewusst, dass dies das kleinste Problem für einen Cracker ist, ja?
Ich glaube, dass _das_ keinen cracker davon abhalten würde und wenn, dann muss er sich
gar nicht erst bemühen. Das halte ich eigentlich für blosse Zeitverschwendung und ist
IMHO sogar gefährlich: Das stellt der Client mal kurz JS aus, oder installiert ein
neues Plugin und schon schmeisst der böse Aqua ihn raus :-)

Viele Grüsse

Philipp

[Lude]

Hi,

PS.: Dass es 100%ige Sicherheit in der Hinsicht
     nicht geben kann weiß ich!
Du koenntest die gesamte "Umgebung" des Clients speichern und jeweils mit der gesendeten in ausgewaehlten Segmenten vergleichen.

Dir ist aber schon bewusst, dass dies das kleinste Problem für einen Cracker ist, ja?

nein, warum nicht?

Gruss,
Lude

[Philipp Hasenfratz]

Halihallo Lude

Dir ist aber schon bewusst, dass dies das kleinste Problem für einen Cracker ist, ja?
nein, warum nicht?

Alles was zwischen Client und Server kommuniziert wird, kann von Cracker nachgebildet
werden und nur das, was kommuniziert wird, ist der Server im Stande zu erkennen, sprich:
Der cracker kann _alles_, was ein anderer Client sendet emulieren.

OK, ich glaube begriffen zu haben, was du gesagt hast: Der cracker müsste die Browser-
Konfiguration, die beim Login gespeichert wurde, erraten. Nun, da
mindestens 75% mit IE6 und WinXP und den mitgelieferten Plugins und 17'' Bildschrim
unterwegs sind, dürfte sich das nicht als allzu schwer erweisen, zumindest nicht
schwerer, als wenn dies mit der Anzahl Möglichkeiten des SessionKey's vergleicht.

Nun, den zusätzlichen Schutz halte ich für minimal und wie gesagt, es können damit
auch "Nebenwirkungen" erscheinen.

Viele Grüsse

Philipp

[Lude]

Hi,

OK, ich glaube begriffen zu haben, was du gesagt hast: Der cracker müsste die Browser-
Konfiguration, die beim Login gespeichert wurde, erraten. Nun, da
mindestens 75% mit IE6 und WinXP und den mitgelieferten Plugins und 17'' Bildschrim
unterwegs sind, dürfte sich das nicht als allzu schwer erweisen, zumindest nicht
schwerer, als wenn dies mit der Anzahl Möglichkeiten des SessionKey's vergleicht.

die "Umgebung" gibt doch einiges her. - Erraten kann man doch da kaum etwas. - Wenn unter SSL auch die Umgebung verschluesselt wird und nicht nur die "Formulardaten" bzw. POST-Daten, dann geht doch nur noch etwas fuer den Hacker / Cracker, wenn er das Netzwerk monitort, oder?

Gruss,
Lude

[Henryk Plötz]

Moin,

die "Umgebung" gibt doch einiges her. - Erraten kann man doch da kaum etwas. - Wenn unter SSL auch die Umgebung verschluesselt wird und nicht nur die "Formulardaten" bzw. POST-Daten, dann geht doch nur noch etwas fuer den Hacker / Cracker, wenn er das Netzwerk monitort, oder?

SSL ist korrekt eingesetzt an sich ein völlig ausreichender Schutz vor sniffenden Angreifern oder Männern-in-der-Mitte. Die HTTP-Header zu speichern bietet _keinen_ (in Worten: Null, Nada, Niente) zusätzlichen Schutz vor Angreifern, führt aber dazu dass ein berechtigter User unnützerweise abgewiesen werden könnte.

[Lude]

Hi,

SSL ist korrekt eingesetzt an sich ein völlig ausreichender Schutz vor sniffenden Angreifern oder Männern-in-der-Mitte. Die HTTP-Header zu speichern bietet _keinen_ (in Worten: Null, Nada, Niente) zusätzlichen Schutz vor Angreifern, führt aber dazu dass ein berechtigter User unnützerweise abgewiesen werden könnte.

dann war und ist die ganze Diskussion also sinnlos. btw - Cool bleiben gegenueber den Redundanzen im Web sollte doch von einem Forumsbullen erwartet werden koennen.

Gruss,
Lude

[Henryk Plötz]

Moin,

OK, ich glaube begriffen zu haben, was du gesagt hast: Der cracker müsste die Browser-
Konfiguration, die beim Login gespeichert wurde, erraten.

Wieso das? Wenn er die Session-ID ersniffen konnte, konnte er den Rest auch sehen. Das wurde kürzlich in de.comp.lang.php.netzprotokolle diskutiert. Message-ID [e-mail] und folgende. Ich habe jetzt keine Lust meine Argumente hier noch einmal zu wiederholen.

Die Kurzform: IP-Addresse speichern ist eine absolut schlechte Idee. Andere HTTP-Header speichern ist ebenfalls eine blöde Idee.

[Henryk Plötz]

Moin,

Wieso das? Wenn er die Session-ID ersniffen konnte, konnte er den Rest auch sehen. Das wurde kürzlich in de.comp.lang.php.netzprotokolle diskutiert. Message-ID [e-mail] und folgende. Ich habe jetzt keine Lust meine Argumente hier noch einmal zu wiederholen.

Ich hatte grade einen Anruf (Aqua, warst du das?) und offensichtlich wird de.comp.lang.php.netzprotokolle nicht bei Google archiviert.

Also doch eine Wiederholung:
Die Header zu speichern bringt keine zusätzliche Sicherheit. Wenn ein Angreifer nämlich die Session-ID ersniffen kann, kann er auch die anderen Header kriegen und sie für den Angriff zurückspielen. Bei einer normalen Benutzung hingegen können sich die Header schonmal ändern und der Benutzer würde dann ausgeloggt, was für den Benutzer dann sehr ärgerlich ist.

Die IP-Addresse zu speichern ist eine blöde Idee, da sie sich auch bei normaler Nutzung ändern kann (durch Proxy-Batterien wie sie manche Provider einsetzen zum Beispiel). Auch können mehrere User hinter der selben Addresse stecken.

Korrekt könnte man nun HTTP Digest Authentication einsetzen, um Angreifer abzuwehren welche sniffen können (und in gewissem Maße auch solche die die Verbindung manipulieren können), das kann der Internet Explorer aber wieder nicht.

Da aber hier schon SSL im Einsatz ist: SSL (also HTTPS) ist an sich ausreichend gegen alle möglichen Angriffe (modulo Implementationsfehler, auch die hat es gegeben). Sniffende Angreifer können die verschlüsselten Daten nicht entschlüsseln. Es sei denn der Serverbetreiber geht mit seinem geheimen Schlüssel unsicher um.
Männer-in-der-Mitte müssten auffallen da sie höchstwahrscheinlich kein Zertifikat kriegen, welches auf den verwendeten Servernamen von einer Instanz der der Browser vertraut zertifiziert wurde. (Verisign zum Beispiel hatte aber schonmal ein falsches Microsoft-Zertifikat ausgestellt.) Dagegen hilft es, wenn der Benutzer das Serverzertifikat anhand seines Fingerprints über einen sicheren Kanal zum Serverbetreiber überprüft. Persönlicher Kontakt ist zum Beispiel klasse, Telefon könnte eventuell auch gehen.
Die Sicherheit geht aber soweit, dass viele Leute dem ihre Kreditkartendaten anvertrauen.

[Philipp Hasenfratz]

Halihallo Henryk

Wieso das? Wenn er die Session-ID ersniffen konnte, konnte er den Rest auch sehen. Das wurde kürzlich in de.comp.lang.php.netzprotokolle diskutiert. Message-ID [e-mail] und folgende. Ich habe jetzt keine Lust meine Argumente hier noch einmal zu wiederholen.

Korrekt was das ersniffen angeht. Wenn ich den Trick von Lude richtig deute geht es nicht
um das ersniffen, sondern um das erschweren einer Bruteforce-Attacke. Das das loggen
von Clientseitigen Daten keinen grossen Mehrwert bringt habe ich bereits gesagt.
Beim ersniffen bringt es keinen Mehrwert, bei Bruteforce schon, wobei dies, wie ich
eben schon gesagt habe, durch ein zusätzliches bit im Schlüssel ausgegelicht werden kann.
Zudem halte ich es allgemein für unglücklich die Sicherheit vom Client abhängig zu
machen (SSL ist hierbei die Ausnahme), da bin ich absolut deiner Meinung.

Ansonsten Full ACK.

Viele Grüsse

Philipp