it-swarm.com.de

Ist ein Cookie sicherer als ein einfacher HTTP-Header?

Mir wurde kürzlich gesagt, dass ein Cookie "sicherer" ist als ein normaler alter HTTP-Header, der sicherer als ein URL-Parameter ist, insbesondere wenn Zugriffstoken weitergegeben werden. Was ist der Grund dafür, dass ein Cookie sicherer ist als ein HTTP-Header?

Ich bin mir auch ziemlich sicher, dass ich verstehe, warum ein URL-Parameter unsicher ist: weil er ständig sichtbar ist und leicht abgerufen werden kann. Ist das korrekt?

15
mergesort

Cookies are HTTP-Header. Der Header heißt Cookie:, und es enthält Ihren Cookie.

Cookies sind jedoch sicherer als URL-Parameter, da Cookies niemals an andere Domains gesendet werden. URL-Parameter hingegen landen im Referer: Header einer Site, die Sie direkt von der Site mit dem URL-Parameter aus besuchen.

23
tylerl

Es gibt drei Standardmethoden zum Übergeben von Daten vom Browser: GET, POST und Cookies (die sowohl für GET als auch für POST Anforderungen gesendet werden). Hier ist eine Beispielanforderung, die an einen Server gesendet wird, wenn Sie nach www.example.org/spec.html?secret=foo gefragt haben:

GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*

Durch das Einfügen von Sitzungsinformationen in die URL kann sie vom Benutzer des Browsers kopiert werden. Aus Sicht der Sichtbarkeit des Kabels macht dies jedoch keinen Unterschied. Aus diesem Grund werden vertrauliche Daten häufig POSTed. Unabhängig davon, wie Sie eine Anfrage stellen, denken Sie daran, dass diese wahrscheinlich vor CSRF geschützt sein sollte.

Cookies bieten eine Möglichkeit zum Speichern von Daten, die über die Dauer einer Sitzung oder über Browser-Registerkarten hinweg gültig sind.

8
Jeff Ferland

Wenn Sie das Autorisierungstoken über http-Header übergeben, benötigen Sie eine clientseitige Logik, um diese bei jeder Anforderung an den Server zu übergeben. Ein Skimmer kann dies in Ihrem clientseitigen Code suchen und Ihre Benutzersitzung mit Java Skript) entführen.

Wenn dieselben Informationen jedoch über Cookies weitergegeben werden, liegt es in der Verantwortung des Browsers, das Cookie bei jeder Anforderung weiterzugeben (Sie können keine clientseitige Logik schreiben). Dies macht es etwas schwierig (aber nicht unmöglich), den Mechanismus zu identifizieren, in dem das Token übergeben wird.

Wenn das Cookie auf "Nur http" gesetzt ist, wird das Entführen von Sitzungen über JavaScript fast unmöglich (ich habe gelesen, dass einige Browser diese Informationen an JavaScript weitergeben, aber die Unterstützung nimmt zu). Und Cookies haben dieselbe Origin-Richtlinie. Wenn Sie jedoch Tools wie Fiddler verwenden, kann ein entschlossener Hacker auf diese Informationen zugreifen.

Aber der Hacker sollte in der Lage sein, das Netzwerk zu beschnüffeln, um an diese Informationen zu gelangen.

Zusammenfassend ist ein Cookie also definitiv sicherer.

Wenn Sie sich solche Sorgen um die Sicherheit machen, entscheiden Sie sich für SSL-Zertifikate, die die Gefahr des Netzwerkschnüffelns bei einer vergeblichen Aktivität fast beseitigen.

3
Mr.X

Cookies sind Teil des HTTP-Headers , daher können sie nicht sicherer sein als sie selbst. In Cookies sind Sicherheitsflags integriert: HTTPOnly und Secure, wobei letzteres die Übertragung über Nicht-SSL-Verbindungen verhindert.

Parameter als Teil der URL werden häufig von Webdiensten protokolliert, die Sie als Teil von Statistiken oder auf andere Weise ausführen, sodass sie für jeden, der Zugriff erhalten kann, im Klartext gelesen werden können.

3
Ditmar Wendt
  1. URL-Parameter werden im Header Referer an andere Sites gesendet. Dies ist der schlechteste Weg, um vertrauliche Daten zu übergeben.

  2. Die (veraltete) Cookie2 header wird mit einer Nonce verschlüsselt, die von der Site in ihrem Set-Cookie2 Antwortheader. Dies ist daher am wenigsten schlecht, wird aber nicht gut unterstützt.

  3. Andere Anforderungsheader (einschließlich Cookie) liegen irgendwo dazwischen.

Keine dieser Optionen ist "sicher".

Die sichere Option nur ist HTTPS (d. H. SSL) unter Verwendung einer gegenseitig vertrauenswürdigen Zertifizierungsstelle.

2
Nicholas Shanks

Ich denke, sowohl Cookies als auch Header haben Stärken und Schwächen. Da einige Antworten bereits auf die Stärken von Cookies verweisen, werde ich die Stärken von Headern erwähnen. Header müssen programmgesteuert von der js-Anwendung übertragen werden. Sie werden vom Browser beim Zugriff auf eine URL in der jeweiligen Domain niemals automatisch übertragen. Dies führt dazu, dass andere js-Anwendungen oder Snippets den Header nicht automatisch senden können, wodurch eine ganze Reihe von Angriffen in den CSRF- oder Cross-Site-Scripting-Bereichen ausgeschlossen werden. In beiden Fällen ist es natürlich erforderlich, nur HTTPS über TLS zu verwenden und das Downgrade auf HTTP zu deaktivieren.

1
NicuMarasoiu