Frage:
Jeder Grund, NICHT alle Cookies so zu setzen, dass sie nur http und sicher sind
user2145893
2018-05-24 23:08:21 UTC
view on stackexchange narkive permalink

Angenommen, eine Site verwendet ständig alle HTTPS (LB leitet Port 80 auf 443 um), gibt es einen Grund, nicht jedes von der Anwendung gesetzte Cookie zu zwingen, BEIDE sicher UND zu verwenden http ?

Derzeit kennzeichnet ein PCI-Scan beispielsweise nur die jsessionid als nicht mit dem Attribut sichere , aber morgen könnte es das andere sein. Also versuche ich, voranzukommen.

Die meiste Zeit soll JS in der Lage sein, Cookies zu lesen, um Informationen ohne zusätzliche http-Verbindungen wie Ajax an den Server weiterzuleiten.
Dies kann auch ohne die document.cookie-API erreicht werden.HttpOnly bietet Schutz gegen das Lesen von Cookies gegen XSS-Angriffe.Es sollte wenn möglich verwendet werden.
Der offensichtliche Grund ist, dass es nicht nur http ist.Zum Beispiel, wenn Sie JavaScript haben, das aus Cookies liest.
Fünf antworten:
Jonathan
2018-05-25 01:48:34 UTC
view on stackexchange narkive permalink

Ja, es gibt Fälle, in denen Sie NUR HTTP oder SICHER nicht möchten.

Nur für HTTP möchten Sie möglicherweise, dass Javascript mit dem Cookie interagiert. Vielleicht verfolgen Sie den Seitenstatus in einem Cookie, schreiben mit JS in das Cookie und lesen aus JS. Außerdem wird CSRF häufig mit einem Nicht-http-only-Cookie implementiert.

Für das sichere Cookie würde ich nicht erwarten, dass Cookies jemals nicht das sichere Attribut haben, außer in diesen beiden Fällen:

  1. Entwicklungsumgebungen haben oder müssen häufig keine TLS-Zertifikate haben (obwohl dies möglicherweise der Fall sein sollte)
  2. , um Aktivitäten zu verfolgen, die von http stammen. Sie können sogar Ihren Load Balancer verwenden, um ein unsicheres Cookie zu setzen, bevor es die Umleitung zurücksendet. Anschließend kann Ihre Anwendungsanalyse nachverfolgen, welche URLs als HTTP eingegeben wurden.
    3. ol>

    Wenn Sie in der Praxis eine https-Site ausführen, setzen Sie immer das sichere Cookie und Wenn Sie die JS-Anforderungen nicht kennen, führen Sie immer einen Fehler auf der Seite mit HTTPONLY-Einstellung aus.

    AKTUALISIERUNG AUF ADRESSKOMMENTARE

    Es wird viel darüber gesprochen, ob Sie TLS in der Produktion verwenden sollten oder nicht. Die Frage wurde hier gestellt:

    Soll ich mit ein- oder ausgeschaltetem TLS entwickeln?

`Entwicklungsumgebungen haben oder brauchen oft keine TLS-Zertifikate` <- sollten es aber.Sie können ein selbstsigniertes Zertifikat oder sogar ein mit Lets Encrypt erstelltes Zertifikat verwenden.
Oh, ein weiterer Punkt, um https zu verwenden: Woher wissen Sie, dass Ihre Website ordnungsgemäß mit https funktioniert, wenn Sie sie nicht mit https testen, bevor Sie sich darauf verlassen?
@IsmaelMiguel: In einer lokalen Entwicklungsumgebung ist dies buchstäblich nicht erforderlich, und es ist verboten, Daten auf dem Kabel zu untersuchen."Es sollte" ist falsch.Ja, Sie sollten jedoch vor der Bereitstellung einen Test durchführen.
@IsmaelMiguel Sie können eine lokale, nicht über das Internet adressierbare Entwicklerwebsite nicht verschlüsseln. Selbstsignierte Zertifikate sind normalerweise problematisch, insbesondere in Organisationen, die auch Sicherheitsbeschränkungen haben, um den Zugriff auf Websites mit Zertifikatproblemen zu verhindern (da selbstsignierte Zertifikate dies können.)Wenn dies nicht überprüft werden kann, kann niemand auf die Website selbst zugreifen.
@phyrfox Dies ist eine bestimmte Instanz einer Entwicklungsumgebung
@IsmaelMiguel Ja, aber das ist mein Punkt.Wenn ich meine Website nicht dem Internet aussetzen möchte und mich in einem eingeschränkten Unternehmensnetzwerk befinde, ist Ihr Rat bestenfalls nutzlos und möglicherweise sogar schädlich (z. B. aktivieren Sie TLS und verlieren den Zugriff auf Ihre Verwaltungskonsole).Natürlich sollten Sie Sicherheit nicht vorziehen, aber eine pauschale Aussage wie "aber sollte" könnte jemandem irgendwo Kummer bereiten.Zumindest sollte es sich um eine qualifizierte / bedingte Aussage handeln.
@phyrfox Genau!Ich sagte * sollte *, nicht * muss *!Einer ist ein Vorschlag, der andere ist eine Forderung.Grundsätzlich sollten Sie ein Zertifikat verwenden und TLS aktivieren, sind jedoch nicht dazu verpflichtet.Es ist nicht obligatorisch.Sie sollten immer noch einen Weg finden, wenn es machbar ist.
und dies ist der Grund, warum Datenverletzungen, Verunstaltungen und alle Arten von Unfug möglich gemacht werden und ständig passieren.Ihre Entwicklungsumgebung sollte so nah wie möglich an Ihrer Bereitstellungsumgebung sein, da Sie sonst immer technische Schulden anhäufen oder sich auf eine Weise entwickeln, die schwierig oder unmöglich zu sichern ist oder noch schlimmer.
Beachten Sie auch, dass die Schicht, die die SSL-Beendigung ausführt, nicht die Schicht sein muss, die die Anforderung tatsächlich bedient.Das Entkoppeln dieser Schichten kann Entwicklungsschmerzen erheblich lindern.Im Idealfall erfolgt die TLS-Beendigung natürlich auf demselben Computer wie die Anwendungslogik oder zumindest innerhalb desselben vertrauenswürdigen Netzwerksegments.Andernfalls benötigen Sie eine neue TLS-Sitzung, und jetzt haben Sie zwei Probleme.
@LightnessRacesinOrbit Aber diese Frage zeigt, wie dringend es ist, sich in TLS zu entwickeln!OP ist genau Ihrem Weg gefolgt: Das System ist offen entwickelt, niemand hat Erfahrung damit, wie "sicher" funktioniert, und nachdem die Entwickler fertig sind, wird TLS wie ein magischer Talisman darauf geschlagen.Das genaue Gegenteil ist der Fall: "Es besteht buchstäblich keine Notwendigkeit, sich in einer lokalen Entwicklungsumgebung mit offenen Verbindungen zu befassen, außer in Fällen, in denen Kabel untersucht werden."Dies gibt jedem ein Verständnis dafür, wie TLS funktioniert und wie es sich von offenen Verbindungen unterscheidet.Übrigens können Sie Draht mit MitM untersuchen, das auch Certpinning lehrt.Sicherheit geht vor.
Neue Frage gestellt: Soll ich mit ein- oder ausgeschaltetem TLS entwickeln?https://security.stackexchange.com/questions/186796/should-i-develop-with-tls-on-or-off
Nur ein Trottel: SSL in Ihrer Entwickler- / internen Umgebung zu haben * IST * eine gute Praxis und verhindert * NICHT *, dass Sie den Datenverkehr auf dem Kabel anzeigen.Dafür ist ein einfacher SSL-Proxy gedacht.
@AngeloSchilling sogar Chrome Dev Tools zeigen Ihnen auf der Registerkarte Netzwerk viel von dem, was Sie brauchen.
Steffen Ullrich
2018-05-24 23:28:44 UTC
view on stackexchange narkive permalink

In Bezug auf httponly fragen Sie im Wesentlichen, ob es sich um Anwendungsfälle handelt, in denen ein Cookie von Javascript gelesen oder gesetzt werden muss. In der Regel bleiben einige Einstellungen der Benutzeroberfläche (Wahl der Sprache ...) auf diese Weise erhalten, die bei einem Cookie von httponly nicht mehr funktionieren.

Was sicher betrifft: Da die Website Ihrer Beschreibung nach ständig https verwendet, schadet es nicht, wenn alle Cookies sicher sind.

Tony Thomas
2018-05-25 00:45:53 UTC
view on stackexchange narkive permalink

Sicheres Flag

Angesichts der Tatsache, dass die Anwendung über HTTPS ausgeführt wird, dh LB den gesamten Port 80-Verkehr auf 443 umleitet, ist es weiterhin erforderlich, das sichere Flag im Lichte des zu aktivieren folgendes Szenario.

  1. Angenommen, es liegt ein Entwicklungsfehler vor, aufgrund dessen ein Hyperlink das HTTP enthält (z. B. http://example.com/some_page.php) Link anstelle des HTTPS-Links (z. B. https://example.com/some_page.php).
  2. Der Browser fordert die Webressource über HTTP an und sendet das Cookie zusammen mit dem Fehlen des sicheren Flags.
  3. Die Anforderung erreicht die LB, die den Datenverkehr an Port 443 umleitet, dh über HTTPS.
  4. Der Browser initiiert die Anforderung jedoch erneut Diesmal über HTTPS mit dem Cookie-Wert.
    5. ol>

    Obwohl die LB so konfiguriert ist, dass sie den unsicheren Verkehr von Port 80 auf den sicheren Verkehr von Port 443 umleitet, könnte ein erfolgreicher MiTM-Angriff unter stattfinden Schritt 2 führt zum Identitätswechsel eines Benutzers durch Stehlen die sensiblen Cookies. Darüber hinaus ist die Überprüfung, ob die Hyperlinks und Weiterleitungen ordnungsgemäß codiert sind, vergleichsweise anstrengender als das Aktivieren des sicheren Flags für vertrauliche Cookies. Obwohl eine Umleitung auf LB-Ebene eingerichtet ist, kann es zu möglichen Szenarien kommen, in denen ein fruchtbarer MiTM ausgeführt werden kann, weil das sichere Flag fehlt.

    httponly Flag

    Dies ist ein Flag, dessen Bedeutung unabhängig von der Transport Layer Security (SSL / TLS) bleibt. Das httponly-Flag wird verwendet, um zu verhindern, dass Javascript im Falle eines erfolgreichen XSS-Angriffs (Cross-Site Scripting) auf vertrauliche Cookies wie die Sitzungscookies zugreift. Wenn das httponly-Flag nicht auf den Cookie-Wert gesetzt ist, kann das böswillige Javascript, das aufgrund eines Fehlers auf Anwendungsebene in die Anwendung injiziert wird, die Vertraulichkeit, Integrität und Verfügbarkeit von Benutzerkonten sabotieren, indem beispielsweise Sitzungscookies gelesen und an Remoteserver gesendet werden Dadurch sollte das httponly-Flag immer für alle Cookies oder zumindest für die sensiblen gesetzt werden.

Wenn es sich bei der fraglichen Site um ein SPA handelt, möchten Sie normalerweise nicht httponly, aber Sie müssen auch CSP und andere Sicherheitsmaßnahmen verwenden, um zu verhindern, dass unerwünschte Skripte Sitzungsdaten stehlen.
Ich stimme @phyrfox voll und ganz zu. Es gibt immer die Möglichkeit, CSP zu verwenden, um zu verhindern, dass betrügerische Skripte Sitzungsdaten stehlen.Betrachten wir aber auch die Tatsache, dass httponly im Vergleich zu CSPs eine größere Browserunterstützung bietet. Quelle: http://www.browserscope.org/?category=security
Tschallacka
2018-05-25 14:25:48 UTC
view on stackexchange narkive permalink

Ich gebe Ihnen ein praktisches Beispiel für ein Cookie, das nicht nur http ist.

Wenn ein Besucher auf meine Website kommt, werden ihm zwei Cookies in den Hals geschoben. 

  phpsession -> sichere httponly samesite: laxcookie_law -> sichere samesite: lax

Die cookie_law enthält ein base64-codiertes json-codiertes Cookie-Objekt, in dem die Cookie-Einstellungen gespeichert sind.

Mein Javascript liest diese Cookies, um zu bestimmen, ob Analysen und AdWords geladen werden sollen, die von der Berechtigung oder dem Status abhängen.
Mein Javascript verwendet dieses Cookie auch, damit der Editor für Cookie-Einstellungen funktioniert.

Wenn ich das httponly-Flag für die Cookies setze, kann das Javascript es nicht lesen. Und ich kann PHP nicht verwenden, um den Ladestatus beim Rendern der Skripte zu bestimmen, da mehrere Ebenen des Cachings vorhanden sind. Deshalb habe ich mich entschieden, den httponly von diesem Cookie zu lassen.

Das Javascript benötigt Zugriff, um es lesen zu können.

David Spillett
2018-05-25 19:10:32 UTC
view on stackexchange narkive permalink

Nur http: Manchmal werden Benutzereinstellungen (Schriftgröße, Thema, Sprache, ...) auf der Clientseite festgelegt und ausgeführt. Dies ist der häufigste Fall, wenn sie nicht nur auf http festgelegt werden müssen.

sicher: Da die Site / App auf HTTPS besteht, gibt es keinen Grund, nicht um das sichere Flag zu verwenden. Wenn die Site / App Zugriff über HTTP bieten muss und Sie Details benötigen, um zwischen verschlüsselten / keinen Kontexten zu wechseln (möglicherweise wieder die Anzeigeeinstellungen des Benutzers), müssen Sie dies weglassen.

Während es scheint Unabhängig davon, wie Sie derzeit den HTTPS-Zugriff erzwingen, sollten Sie Fehler berücksichtigen: Ihre App wird möglicherweise mit falschen Einstellungen erneut bereitgestellt, oder Ihre Benutzer sind möglicherweise einem MItM (entweder einem böswilligen oder einem schlecht konfigurierten Proxy) mit einem ähnlichen Proxy ausgesetzt Effekt und mit diesem Flag setzen versagen die Dinge sicher (aus Sicherheitsgründen), indem sie nicht mehr arbeiten, sondern unsicher arbeiten.

Allgemein: Da es sich um Sicherheitsmaßnahmen handelt, wie gering sie auch sein mögen Möglicherweise scheinen Sie immer beide zu setzen, es sei denn, Sie haben einen bestimmten Grund, dies nicht zu tun, anstatt sie standardmäßig auszulassen, es sei denn, Sie glauben, dass sie benötigt werden.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...