web-dev-qa-db-de.com

Sichere Cookies und gemischte Nutzung der https / http-Website

Viele Websites scheinen https zu unterstützen, verwenden jedoch keine sicheren Cookies. Ich möchte, dass meine Website sichere Cookies verwendet, aber stattdessen den Zugriff auf einige Inhalte über http zulässt.

Ein sinnvoller Weg, dies zu tun, scheint darin zu bestehen, ein sicheres Cookie für die eigentliche Sitzung und ein nicht sicheres Cookie zu haben, das nur eine Markierung darstellt, die angibt, ob der Benutzer angemeldet ist oder nicht (um verschiedene Dinge in der Kopfzeile anzuzeigen, z. B. einen Abmeldelink anstelle eines Anmeldelinks). Dieses Cookie würde keine "echten" Sitzungsinformationen enthalten und dient nur dazu, dass die Site Seiten für angemeldete Benutzer geringfügig anders anzeigt als für ausgeloggte Seiten auf http-Abschnitten der Site.

Die ganze Site als https zu haben, ist eine andere Option, aber dies scheint ein bisschen langsamer zu sein als normales http und ist daher nicht wirklich ideal.

Warum verwenden Websites diese Art der Einrichtung nicht und haben sichere Cookies? Die Möglichkeit des Diebstahls von Cookies scheint heutzutage eine Notwendigkeit für sichere Cookies zu sein. Gibt es einen besseren Weg, um dasselbe zu erreichen?

51
David Gardner

Die von Ihnen vorgeschlagene Lösung scheint zu funktionieren, solange Sie nichts dagegen haben, dass nicht autorisierte Personen den nicht sicheren (http-) Teil der Website so anzeigen können, als wären sie angemeldet - also so lange wie möglich Der http-Teil der Website enthält keine vertraulichen Informationen, und der einzige Unterschied zwischen angemeldeten und nicht angemeldeten Benutzern besteht in einer harmlosen Angabe in der Kopfzeile.

Der Grund, warum es nicht sehr oft verwendet wird, kann einer der folgenden sein:

  • Dieses Szenario ist möglicherweise nicht sehr verbreitet. Wenn Sie einen Teil Ihrer Site sicher machen möchten, beschränken Sie die Anmeldesitzung normalerweise nur auf diesen sicheren Teil, oder Sie sorgen dafür, dass die gesamte Site immer HTTPS verwendet (wie z. B. Paypal).
  • Es gibt bereits Lösungen, die sicher sind und mehr können, z. B. das Anmelden einer Person in einem HTTPS-Anmeldeformular und das Beibehalten dieser Sitzung, während diese zurück an HTTP übertragen wird. OpenID ist ein Beispiel. Denken Sie auch an flickr oder gmail: Ihre Anmeldeseite ist immer HTTPS, aber sobald die Sitzung gestartet wurde, migrieren Sie zurück zu HTTP, während Sie die Sitzung sicher verwalten.

pdate (Aug 2014)

Seit ich dies im Jahr 2009 geschrieben habe, ist die Praxis, eine sichere Verbindung für den Anmeldebildschirm zu haben, aber nach dem Anmelden wieder auf HTTP zuzugreifen, so gut wie verschwunden.

Der Aufwand für die Verwendung von HTTPS auf der Seite wird nicht mehr als große Sache angesehen. Das neue SPDY-Protokoll von Google (inzwischen zu HTTP/2 weiterentwickelt) wird browserübergreifend und von wichtigen Webservern unterstützt und verbessert die HTTPS-Geschwindigkeit.

Und schließlich wird der Datenschutz als wichtiger denn je angesehen, auch für Aktionen, die für die Authentifizierung nicht kritisch sind, z. B. das Schreiben von Kommentaren, das Hochladen von Fotos und mehr.

Google hat kürzlich sogar angekündigt, dass Websites, die nur HTTPS-fähig sind, von Suchmaschinen-Rankings profitieren werden.

31
thomasrutter

Aus Sicherheitsgründen sollten Sie niemals Inhalten vertrauen, die über eine nicht gesicherte Verbindung gesendet werden. Aus diesem Grund ist es sicher, ein Cookie, das über eine unverschlüsselte Verbindung gesendet wird, nur dann zu verwenden, wenn die Kosten für Diebstahl oder Missbrauch dieses Cookies ungefähr Null betragen.

In diesem Sinne sind die meisten Websites so konzipiert, dass die Daten nicht zwischen den Kanälen "lecken" dürfen. Schließlich sind Daten, die von der Seite verschlüsselt stammen, normalerweise privilegiert und sollten daher im normalen Kanal nicht zugelassen werden, während Daten, die von der Seite nverschlüsselt stammen, möglicherweise gefälscht werden. und sollte nicht vertraut werden.

Wenn Sie Daten haben, die nicht zu diesen Verallgemeinerungen passen, können Sie diese nach Belieben verwenden.

11
tylerl

Das Übertragen von Sitzungscookies über HTTP hat mich eine Weile gestört. Ich denke, die von Ihnen beschriebene Technik ist die einzig vernünftige Möglichkeit, Cookies zu sichern, während angemeldete Benutzer HTTP-Seiten durchsuchen können, als wären sie angemeldet. Ich habe dies jedoch selten implementiert gesehen.

Warum verwenden Websites diese Art der Einrichtung nicht und haben sichere Cookies?

Ich denke, der Hauptgrund für die mangelnde Akzeptanz ist Risikomanagement :

  • Das Stehlen von Sitzungstoken durch Abhören ist viel schwieriger als z. Cross-Site-Scripting (vorausgesetzt, es liegt eine Sicherheitslücke vor). Sie benötigen Zugriff auf das Netzwerk (z. B. LAN oder ISP des Benutzers). Daher sollten Entwickler laut risikobasierter Priorisierung zuerst XSS-Probleme angehen, da dies eine viel größere Angriffsfläche bietet (die Wahrscheinlichkeit eines Angriffs ist viel höher).
  • Gleiches gilt für CSRF- und UI-Korrekturen (auch bekannt als Click-Jacking).
  • Wenn die geschäftlichen Auswirkungen von Sitzungen, die gehackt werden, hoch sind (z. B. das Speichern von Kreditkarten für die spätere Verwendung in einem Webshop), sollten Sie möglicherweise Ihre gesamte Website auf HTTPS beschränken.

Ein weiterer Grund können Usability-Probleme sein: Mit Ihrem vorgeschlagenen Schema verwalten Sie effektiv zwei gleichzeitige Sitzungen für einen einzelnen Benutzer. Dies ist einfach genug, solange das angemeldete Flag der einzige in der unsicheren Sitzung gespeicherte Status ist. Wenn Sie in beiden Sitzungen auch Einstellungen wie Sprache und Land ändern können, kann dies zu Problemen führen (Implementierung oder Verwendung).

Gibt es einen besseren Weg, um das Gleiche zu erreichen?

From Das Handbuch für Webanwendungs-Hacker :

Wenn HTTP-Cookies zum Übertragen von Token verwendet werden, sollten diese als secure gekennzeichnet werden, um zu verhindern, dass der Browser des Benutzers sie jemals über HTTP überträgt. Wenn möglich, sollte HTTPS für jede Seite der Anwendung verwendet werden, einschließlich statischer Inhalte wie Hilfeseiten, Bilder usw.

Stellen Sie im Ernst, dass die gesamte Site HTTPS verwendet. Vor einigen Jahren war dies möglicherweise nicht möglich, da CDNs keine HTTPS-Unterstützung bieten. Heute geht es vor allem darum, Entwicklungs- und Betriebskosten in Einklang zu bringen.

9
Pankrat

Mir ist völlig bewusst, dass die empfohlene Vorgehensweise darin besteht, nur SSL auf der gesamten Site zu erzwingen. Es gibt jedoch sicherlich Einzelfälle, in denen die Auswahl zwischen HTTP und HTTPS nützlich sein könnte.

Ich hatte ein ähnliches Szenario wie @Dsavid Gardner. Mein Unternehmen verwendet einen Drittanbieter, um unseren Shop-Teil unserer Website zu verwalten. Dieser Shop befindet sich in der Unterdomäne " https: //store.mysite.com ". Wir haben Videocontent im Wert von 15 Jahren und unser aktueller Videomanagement-Anbieter bricht ab, wenn ein Video in ein SSL eingebettet ist. (Ich vermute, es werden Ressourcen aus HTTP-Domänen abgerufen, aber das ist ein weiteres Problem für einen anderen Tag.)

Sicher, ich könnte ein SSL kaufen und das Debuggen von zwei Drittanbietern sowie das Durchsuchen und Ersetzen unserer gesamten Datenbank (oder eines .htaccess-Dateihacks, aber ich schweife ab) durchführen, um HTTP-Ressourcen zu korrigieren Links, nur um in der Lage zu sein, eine Nachricht in der Kopfzeile zu haben, sagen Sie "Welcome 'YourName'", aber das scheint nur übertrieben.

Hier ist eine einfache Javascript-Lösung, die ich mir ausgedacht habe und die ein website-weites, unsicheres Cookie setzt, das auf den bereits gesetzten sicheren Cookies basiert.

Zuerst Ich habe mir einige Javascript-Cookie-Funktionen geholt . Fügen Sie den folgenden Code in den sicheren Bereich Ihrer Website ein:

function readCookie(name) {
    var nameEQ = name + "=";
    var ca = document.cookie.split(';');
    for(var i=0;i < ca.length;i++) {
        var c = ca[i];
        while (c.charAt(0)===' ') { 
            c = c.substring(1,c.length);
        }
        if (c.indexOf(nameEQ) === 0) {
            return c.substring(nameEQ.length,c.length);
        }
    }
    return null;
 }
 function setCookie(cname, cvalue, exdays) {
    var d = new Date();
    d.setTime(d.getTime() + (exdays*24*60*60*1000));
    var expires = "expires="+d.toUTCString();

    /* Note, the W3 documents where I got this code didn't include the
    option to set the domain. I added this and it allows the cookie 
    to be shared across sub-domains. Be sure not to add "www" */
    document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com";
 }
 /*Now we check our cookies on our secure server to find out if the user is
 logged in or not. In my case, the First Name is stored as a cookie. */
 var firstNameCookie = readCookie("the-secure-cookie-name");
 //
 if(!firstNameCookie){
    /* If the cookie doesn't exist, then the person isn't logged in. Add 
    conditional logic here if you'd like (such as deleting any current 
    logged in cookies from the HTTP portion of the site) */
 }
 else {
    /* otherwise, we have a successful login. By grabbing the cookie via 
    this javascript resting on the secure server, we haven't compromised our 
    security. However, if we set a cookie with javascript right now, it 
    won't be a secure cookie by default and we'll have access to it with 
    HTTP on the subdomain */
    setCookie("HTTPfirstName", firstNameCookie, 1.5);
 }

 */The clients first name is now accessible across subdomains in the cookie
  entitled "HTTPfirstName" */

In diesem Fall haben wir nur den Vornamen des Clients an unseren HTTP-Server weitergegeben. Wenn Sie jedoch noch mehr Sicherheit wünschen, können Sie Ihre Servereinstellungen so einstellen, dass nur bestimmte Cookies (z. B. "firstNameCookie") von einer HTTP-Anforderung abgerufen werden können, und dies fügt eine zusätzliche Schutzebene hinzu. Das können Sie lernen wie geht das hier

Sicher, das ist nicht die idealste Lösung. In Zukunft plane ich die Implementierung von SSL auf der gesamten Website, aber es ist sicher gut, wenn ich in der Zwischenzeit eine einfache Javascript-Funktion habe, um sie zu ersetzen.

1
Lucas