wake-up-neo.com

https-URL mit Token-Parameter: Wie sicher ist sie?

Auf unserer Website bieten wir den Benutzern eine Simulation auf der Grundlage ihrer privaten Informationen (über ein Formular angegeben). Wir möchten ihnen erlauben, später auf ihre Simulationsergebnisse zurückzugreifen, ohne sie zu zwingen, ein Login/Passwort-Konto zu erstellen.

Wir haben uns überlegt, ihnen eine E-Mail mit einem Link zu senden, über den sie ihre Ergebnisse zurückerhalten können. Natürlich müssen wir diese URL sichern, da es um private Daten geht.

Wir beabsichtigen daher, ein Token (wie eine 40-stellige Kombination aus Buchstaben und Ziffern oder ein MD5-Hash) in der URL zu übergeben und SSL zu verwenden.

Schließlich würden sie eine E-Mail wie folgt erhalten:

Hallo,
Erhalten Sie Ihre Ergebnisse zurück am https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Was denkst du darüber? Ist es sicher genug? Was würdest du mir für die Token-Generation raten? Wie sieht es mit der Übergabe von URL-Parametern in einer https-Anfrage aus?

76
Flackou

SSL schützt die Abfrageparameter während der Übertragung. Die E-Mail selbst ist jedoch nicht sicher, und die E-Mail kann auf einer beliebigen Anzahl von Servern abprallen, bevor sie an ihr Ziel gelangt.

Abhängig von Ihrem Webserver wird möglicherweise auch die vollständige URL in den Protokolldateien protokolliert. Je nachdem, wie vertraulich die Daten sind, möchten Sie möglicherweise nicht, dass Ihre IT-Mitarbeiter auf alle Token zugreifen können.

Außerdem wird die URL mit der Abfragezeichenfolge im Verlauf Ihres Benutzers gespeichert, sodass andere Benutzer desselben Computers auf die URL zugreifen können.

Schließlich und was dies sehr unsicher macht, wird die URL im Referer-Header aller Anforderungen für Ressourcen, auch für Ressourcen von Drittanbietern, gesendet. Wenn Sie beispielsweise Google Analytics verwenden, senden Sie Google das URL-Token und alle an diese.

Meiner Meinung nach ist das eine schlechte Idee.

87
JoshBerke

Ich würde dafür einen Keks verwenden. Der Workflow sollte folgendermaßen aussehen:

  1. Der Benutzer kommt zum ersten Mal auf Ihre Website.
  2. Site setzt ein Cookie
  3. Benutzer gibt Daten ein. Daten werden in der Datenbank mit einem Schlüssel gespeichert, der im Cookie gespeichert ist.
  4. Wenn der Benutzer das Unternehmen verlässt, senden Sie ihm eine E-Mail mit einem https: -Link
  5. Wenn der Benutzer zurückkommt, entdeckt die Site das Cookie und kann dem Benutzer die alten Daten präsentieren.

Jetzt möchte der Benutzer einen anderen Browser auf einem anderen Computer verwenden. Bieten Sie in diesem Fall einen "Transfer" -Button an. Wenn der Benutzer auf diese Schaltfläche klickt, erhält er einen "Token". Sie kann dieses Token auf einem anderen Computer verwenden, um das Cookie zurückzusetzen. Auf diese Weise entscheidet der Benutzer, wie sicher er das Token übertragen möchte.

12
Aaron Digulla

SSL sichert den Inhalt der Daten während der Übertragung, aber ich bin mir nicht sicher über die URL.

Unabhängig davon besteht eine Möglichkeit, einen Angreifer bei der Wiederverwendung dieses URL-Tokens zu entschärfen, darin, sicherzustellen, dass jedes Token nur einmal verwendet werden kann. Sie können sogar ein Cookie setzen, damit der legitime Benutzer den Link weiterhin verwenden kann. Nach dem ersten Zugriff funktioniert dies jedoch nur für jemanden mit dem Cookie.

Wenn die E-Mail des Benutzers kompromittiert wird und ein Angreifer zuerst den Link erhält, sind Sie erledigt. Der Benutzer hat aber auch größere Probleme.

4
Eli

E-Mail ist von Natur aus unsicher. Wenn irgendjemand auf diesen Link klicken kann, um zu den Daten zu gelangen, schützen Sie sie nicht wirklich.

1
Jason Punyon

Nun, das Token ist sicher, wenn es über SSL übertragen wird. Das Problem, das Sie haben werden, ist, dass es für Leute (für die es nicht bestimmt ist) verfügbar ist, indem Sie die URL anzeigen können.

Wenn es sich um private Informationen wie SSN handelt, würde ich wahrscheinlich keine URL per E-Mail senden. Ich möchte lieber, dass sie einen Benutzernamen und ein Passwort für die Site erstellen. Es ist zu einfach, eine E-Mail mit solchen Informationen zu kompromittieren, die für Sie und für sie auf dem Spiel stehen. Wenn jemandes Konto kompromittiert wird, kommt es zu einer Frage, wessen Schuld es wirklich ist. Je sicherer Sie sind, desto besser sind Sie aus CYA-Sicht.

1
kemiller2002

Ich würde das wirklich nicht für sicher genug halten für eine Situation, in der es ernsthafte Datenschutzprobleme gibt. Die Tatsache, dass Sie die URL in einer (vermutlich unverschlüsselten) E-Mail senden, ist bei weitem das schwächste Glied. Danach besteht die Gefahr von Brute-Force-Angriffen auf die Token, die (ohne die Struktur eines echten Authentifizierungsmechanismus) anfälliger sind als eine gut konstruierte Einrichtung von Benutzernamen und Passwort.

Es gibt übrigens überhaupt keine Probleme mit den Parametern in einer https-Anfrage.

0
chaos

So wie es ist, wäre es eine schlechte Idee. Sie werden die Sicherheit durch einfache Bedienung erhöhen. Wie bereits erwähnt, schützt SSL nur die Übertragung von Informationen zwischen dem Server und dem Client-Browser und verhindert nur den Middle-Man-Angriff. E-Mails sind sehr riskant und unsicher.

Am besten wäre eine Authentifizierung mit Benutzername und Passwort, um auf die Informationen zuzugreifen.

Ich mag die Cookie-Idee mehr oder weniger. Sie sollten auch die Cookie-Informationen verschlüsseln. Sie sollten das Token auch mit Salt und Schlüsselphrase sowie dem $ _SERVER ['HTTP_USER_AGENT'] generieren, um die Wahrscheinlichkeit eines Angriffs zu begrenzen. Speichern Sie so viele unsensible Informationen über den Client in dem Cookie, um sie zu überprüfen.

Die Schlüsselphrase könnte zur einfachen Verwendung im Cookie gespeichert werden, aber denken Sie daran, dass auch Cookies gestohlen werden können = (.

Lassen Sie den Kunden den von ihm angegebenen Schlüsselbegriff eingeben, der zusammen mit seinen Daten auch in der Datenbank gespeichert wird.

Der Schlüssel kann auch verwendet werden, wenn die Person einen anderen Computer verwendet, der sich in den Parametern $ _SERVER ['HTTP_USER_AGENT'] unterscheidet, oder das Cookie einfach nicht verwendet wird. So kann der Cookie übertragen oder gesetzt werden.

Stellen Sie außerdem sicher, dass vertrauliche Daten in der Datenbank verschlüsselt sind. Man weiß nie ;)

0