it-swarm-eu.dev

Sichere Sitzungscookies

Beim Nachschlagen von Methoden zum Erstellen sicherer Sitzungscookies bin ich auf diese Veröffentlichung gestoßen: A Secure Cookie Protocol . Es wird die folgende Formel für ein Sitzungscookie vorgeschlagen:

cookie = user | expiration | data_k | mac

wo

  • | Bezeichnet die Verkettung.
  • user ist der Benutzername des Clients.
  • expiration ist die Ablaufzeit des Cookies.
  • data_k Sind verschlüsselte Daten, die dem Client zugeordnet sind (z. B. eine Sitzungs-ID oder Warenkorbinformationen), die mit dem Schlüssel k verschlüsselt wurden.
    • k wird von einem privaten Serverschlüssel abgeleitet sk; k = HMAC(user | expiration, sk).
    • data_k Könnte mit AES mit dem Schlüssel k verschlüsselt werden.
  • mac ist ein HMAC des Cookies, um die Echtheit des Cookies zu überprüfen. mac = HMAC(user | expiration | data | session-key, k).
    • data sind die unverschlüsselten Daten, die dem Client zugeordnet sind.
    • session-key Ist der SSL-Sitzungsschlüssel.
  • HMAC ist HMAC-MD5 oder HMAC-SHA1.

Dem Papier zufolge bietet es Cookie-Vertraulichkeit und verhindert Wiederholungen und Volumenangriffe. Für mich (ein Amateur in Sicherheit/Kryptographie) sieht das ziemlich gut aus. Wie gut ist diese Methode für Sitzungscookies oder Cookies im Allgemeinen?

35
user369450

Ja, dies scheint ein ziemlich gutes Schema zum Schutz von Cookies zu sein.

Ein weiteres neueres Schema in diesem Bereich ist SCS: Secure Cookie Sessions für HTTP , ein solides Schema, das sehr gut durchdacht ist. Ich empfehle, die Sicherheitsdiskussion dieses Dokuments zu lesen, um einen guten Eindruck von den Sicherheitsbedrohungen zu bekommen.

Um den Zweck und die Rolle des von Ihnen erwähnten Cookie-Schemas zu verstehen, lassen Sie mich einen Rückblick geben und einen Kontext angeben. Es ist üblich, dass Webanwendungen den Sitzungsstatus beibehalten müssen: d. H. Einen Status, dessen Lebensdauer auf die aktuelle Sitzung beschränkt ist und der an die aktuelle Sitzung gebunden ist. Es gibt zwei Möglichkeiten, den Sitzungsstatus beizubehalten:

  1. Sitzungsstatus auf dem Server speichern. Der Webserver füttert den Browser mit einem Sitzungscookie: einem Cookie, dessen einziger Zweck darin besteht, eine große, nicht erratene Bitfolge zu speichern das dient als Sitzungskennung. Der Server führt eine Nachschlagetabelle mit einem Eintrag pro geöffneter Sitzung, die von der Sitzungskennung dem gesamten Sitzungsstatus zugeordnet wird, der dieser Sitzung zugeordnet ist. Dies erleichtert dem Webanwendungscode das Abrufen und Aktualisieren des Sitzungsstatus, der einer bestimmten HTTP/HTTPS-Anforderung zugeordnet ist. Die meisten Webanwendungs-Frameworks bieten integrierte Unterstützung für das Speichern des Sitzungsstatus auf der Serverseite.

    Dies ist die sicherste Methode zum Speichern des Sitzungsstatus. Da der Sitzungsstatus auf dem Server gespeichert ist, hat der Client keinen direkten Zugriff darauf. Daher gibt es für Angreifer keine Möglichkeit, den Sitzungsstatus zu lesen oder zu manipulieren (oder alte Werte wiederzugeben). Es erfordert zusätzliche Arbeit, um den Sitzungsstatus auf allen Servern synchron zu halten, wenn Ihre Webanwendung auf mehrere Back-End-Rechenknoten verteilt ist.

  2. Sitzungsstatus auf dem Client speichern. Der andere Ansatz besteht darin, den Sitzungsstatus in ein Cookie zu setzen und das Cookie an den Browser zu senden. Jetzt enthält jede nachfolgende Anforderung vom Browser den Sitzungsstatus. Wenn die Webanwendung den Sitzungsstatus ändern möchte, kann sie ein aktualisiertes Cookie an den Browser senden.

    Wenn dies naiv erfolgt, ist dies eine massive Sicherheitslücke, da ein böswilliger Client den Sitzungsstatus anzeigen und ändern kann. Ersteres ist ein Problem, wenn im Sitzungsstatus vertrauliche Daten enthalten sind. Letzteres ist ein Problem, wenn der Server dem Sitzungsstatus in irgendeiner Weise vertraut oder sich darauf verlässt (z. B. ob der Sitzungsstatus den Benutzernamen des angemeldeten Benutzers und ein Bit enthält, das angibt, ob dieser Benutzer ein Administrator ist oder nicht; dann könnte ein böswilliger Client den Authentifizierungsmechanismus der Webanwendung umgehen.

    Der von Ihnen erwähnte Vorschlag und das SCS-System sollen diese Risiken so gut wie möglich abwehren. Sie können dies auf eine Weise tun, die meistens erfolgreich ist. Sie können jedoch nicht verhindern, dass ein böswilliger Client das Cookie löscht (und damit den Sitzungsstatus löscht). Außerdem können sie nicht verhindern, dass ein böswilliger Client einen älteren Wert des Cookies wiedergibt (und somit den Sitzungsstatus auf einen älteren Wert zurücksetzt), wenn die ältere Version aus derselben Sitzung stammt. Daher muss der Entwickler der Webanwendung diese Risiken kennen und darauf achten, welche Werte im Sitzungsstatus gespeichert werden.

Aus diesem Grund ist das Speichern des Sitzungsstatus in Cookies etwas riskanter als das Speichern auf dem Server, selbst wenn Sie eines dieser kryptografischen Schemata zum Schutz von Cookies verwenden. (Wenn Sie jedoch den Sitzungsstatus in Cookies speichern möchten, empfehle ich auf jeden Fall, eines dieser beiden Schemata zu verwenden, um die Werte in den Cookies zu schützen. )

Warum sollte jemand den Sitzungsstatus in Cookies speichern, da er genauso einfach auf der Serverseite gespeichert werden kann? Meistens gibt es keinen Grund dazu. In einigen Ausnahmefällen, z. B. bei einem HTTP-Server, dessen Speicherplatz extrem eingeschränkt ist, oder bei Webanwendungen mit Lastenausgleich, die auf mehrere Computer verteilt sind und den synchronisierten Sitzungsstatus nicht gut unterstützen, kann dies jedoch der Fall sein Es ist eine gute Idee, berechtigte Gründe in Betracht zu ziehen, den Sitzungsstatus in Cookies zu speichern und dann eines dieser Schemata zu verwenden.

P.S. Ein verwandtes Thema: Wenn Sie ASP.NET View State verwenden, stellen Sie sicher, dass Sie es so konfigurieren, dass es verschlüsselt und authentifiziert wird: dh konfigurieren Sie ViewStateEncryptionMode bis Always und EnableViewStateMac bis true; Wenn Sie mehrere Serverknoten verwenden, generieren Sie einen starken kryptografischen Schlüssel und konfigurieren Sie das machineKey jedes Servers, um diesen Schlüssel zu verwenden . Stellen Sie schließlich sicher, dass Sie über eine aktuelle Version des ASP.NET-Frameworks verfügen. ältere Versionen hatte eine schwerwiegende Sicherheitslückein der ViewState-Krypto .

30
D.W.

Welches Problem versuchen Sie zu lösen?

Ich kann mir zwei Dinge vorstellen:

  1. Sie möchten sichere Benutzersitzungen einrichten. In diesem Fall müssen Sie höchstwahrscheinlich nicht einmal Ihre eigenen Sitzungscookies generieren - diese können über eine SSL-Sitzung mit Ihrem Server generiert werden und sind im Allgemeinen sicher für alle Website-Anforderungen. Stellen Sie einfach sicher, dass die Site SSL korrekt implementiert, und verwenden Sie eine bekannte Methode zur Sitzungsgenerierung, wie sie in gängigen Sprachen wie PHP oder ASP) zu finden ist.
  2. Sie möchten sichere Daten zum späteren Abrufen im Cookie speichern. Dies ist aufgrund vieler Probleme mit Cookies viel schwieriger zu sichern. Es ist besser, stattdessen serverseitig zu speichern und die Daten mit einer anderen Methode dem Benutzer zuzuordnen. Wenn Sie dies tun müssen, sieht die von Ihnen beschriebene Methode insgesamt ziemlich gut aus, obwohl mir nicht klar ist, wie sie Wiederholungsangriffe oder andere Angriffe wie Man in the Middle wie SSL verhindert.

Sie können mich gerne direkt kontaktieren, wenn Sie mehr besprechen möchten.

4
Charlie B

Ein Teil der von ihnen vorgeschlagenen Methode besteht darin, den SSL-Sitzungsschlüssel als Teil der verschlüsselten Nutzdaten zu verwenden - dies dauert jedoch nur so lange wie die SSL-Sitzung -, d. H. Sie können diese Methode nicht für Cookies verwenden, die mehr als eine Browsersitzung umfassen sollen. Es ist auch nicht gerade trivial; Der Zugriff auf den SSL-Sitzungsschlüssel, insbesondere auf die SSL-Beendigung, erfolgt nicht auf dem http-Server.

In der Praxis ist es viel einfacher, einen zufälligen Wert für das Cookie als Handle für die auf dem Server gespeicherten Daten zu verwenden. Dies kann an Dinge wie einen Hash des Browser-Benutzeragenten und den Netznamen (nicht IP-Adresse) des Clients gebunden sein. Und/oder, falls erforderlich, den SSL-Sitzungsschlüssel auf dem Server. Es ist nicht erforderlich, alle diese Daten zu verschlüsseln und an den Client weiterzuleiten.

2
symcbean

Dies ist eine vernünftige Implementierung, da sie die folgenden Probleme löst:

  • Nicht-Zurückweisung (Überprüfung des Wertes wurde nicht geändert)
  • Vertraulichkeit (dass der verschlüsselte Inhalt nicht gelesen werden kann)

Die Benutzerinformationen sind jedoch etwas schwach und können beeinträchtigt werden, wenn sie nicht in die verschlüsselten Informationen für einen späteren Vergleich aufgenommen werden.

Das größte Problem mit Cookies oder Daten, auf die über den Client zugegriffen werden kann, besteht darin, dass der Client (Hacker) diese ändern oder kopieren kann. Session-Hijacking ist trotz SSL leicht durchzuführen (wie bereits erwähnt als ausreichend - was nicht der Fall ist). Verschiedene Formen von Malware, Man-in-the-Middle-, Man-in-the-Browser- und anderen Angriffen können das Sitzungscookie erfassen, auf einen anderen Computer kopieren und diese Sitzung jetzt "besitzen". Für ein Card-on-File-System wie Amazon kann dies problematisch sein.

Um die Schleife zu diesem Vorschlag zu schließen, muss die Client-Identifikation einigermaßen eindeutig sein und dann an die Daten im verschlüsselten Abschnitt gebunden werden, um zu verhindern, dass ein anderer Computer das Sitzungscookie stiehlt. Davon abgesehen scheinen die Bestandteile des Vorschlags solide zu sein.

0
Darrell Teague