https URL mit Token Parameter: Wie sicher ist es?

86

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

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

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

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

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

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

Flackou
quelle

Antworten:

97

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 übertragen werden, bevor sie an ihr Ziel gelangt.

Abhängig von Ihrem Webserver wird möglicherweise auch die vollständige URL in den Protokolldateien protokolliert. Abhängig davon, wie sensibel die Daten sind, möchten Sie möglicherweise nicht, dass Ihre IT-Mitarbeiter Zugriff auf alle Token haben.

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

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

Meiner Meinung nach ist das eine schlechte Idee.

JoshBerke
quelle
1
Ich hatte nicht über das HTTP-Referer-Problem nachgedacht, aber der URL-Link würde zur Ergebnisseite umleiten, es wäre keine richtige Seite (keine Google Analytics oder andere Skripte von Drittanbietern).
Flackou
5
Entfernen die meisten Browser den Referrer nicht, wenn sie von HTTPS zu HTTP wechseln?
Kevin Mark
2
Dies ähnelt dem Link zur Benutzeraktivierung (oder zum Zurücksetzen des Passworts), oder? Wie soll dieser Fall dann behandelt werden? Viele Websites senden zurückgesetzte URLs an E-Mails. POST ist keine Option, da es anklickbar sein sollte. Danke dir.
Pinkpanther
2
Was ist die Lösung?
RT
1
Was ist, wenn das Token in der URL nicht mit dem für API-Anfragen verwendeten Token übereinstimmt und nur eine Stunde dauert? Was wäre dann der Schaden?
user1709076
13

Ich würde dafür einen Cookie 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, erkennt 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 eine Schaltfläche "Übertragen" 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.

Aaron Digulla
quelle
4

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

Unabhängig davon besteht eine Möglichkeit, einen Angreifer, der dieses URL-Token wiederverwendet, zu verringern, 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 es jedoch nur für jemanden mit dem Cookie.

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

Eli
quelle
10
Die SSL-Verbindung wird gesichert, bevor die URL übertragen wird.
David
1

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

Jason Punyon
quelle
Genau, aber viele, viele Websites kümmern sich nicht darum und senden Login / Passwörter per Mail. Aber es ist kein Grund, sie nachzuahmen ...
Flackou
Ich bin damit einverstanden, dass es keinen Grund gibt, sie zu imitieren, aber normalerweise werden Sie aufgefordert, das Passwort zu ändern, nachdem Sie sich das erste Mal angemeldet haben.
Jason Punyon
1

Nun, das Token ist sicher, wenn es über SSL übertragen wird. Das Problem, das Sie haben werden, ist, dass es für Personen (diejenigen, 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 komprimiert ist, wird es in Frage gestellt, wessen Schuld es wirklich ist. Je sicherer Sie sind, desto besser sind Sie vom CYA-Standpunkt aus.

kemiller2002
quelle
1
Sie haben Recht: Die URL würde zum Beispiel im Browserverlauf bleiben
Flackou
0

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

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

Chaos
quelle
Sie haben Recht mit dem Risiko von Brute-Force-Angriffen. Ich sehe nicht ein, wie wir Bots von dieser Art von Angriff abhalten könnten. Das Verbot "bestehender" IPs wäre kein ausreichender Schutz. Hätten Sie Ideen zu diesem Thema?
Flackou
Mit der Art des Schlüsselraums, von dem wir sprechen, setzen Sie einen if (this_ip_number_has_requested_an_invalid_token_today ()) sleep (5); In Ihrem load_simulation-Skript wäre der Schutz vollkommen ausreichend. (Ratenbegrenzung ist eines dieser Merkmale guter Authentifizierungsmechanismen.)
Chaos
Danke für deine Antwort. Aber ich dachte, dass ein und derselbe Bot leicht verschiedene IPs annehmen könnte, was die IP-Ratenbegrenzung nicht ausreichend machte. Liege ich falsch?
Flackou
Alles, was sie bekommt, ist ein unverzögerter Versuch pro IP. Der IP-Adressraum ist nicht so leicht verfügbar, dass dies hilfreich ist.
Chaos
0

So wie es ist, wäre es eine schlechte Idee. Sie werden die Sicherheit durch einfache Bedienung verbessern. Wie bereits erwähnt, schützt SSL nur die Übertragung von Informationen zwischen Server und 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 $ _SERVER ['HTTP_USER_AGENT'] generieren, um die Wahrscheinlichkeit eines Angriffs zu begrenzen. Speichern Sie so viele nicht sensible Informationen über den Client im Cookie, dass Sie sie überprüfen können.

Der Schlüsselbegriff kann zur einfachen Verwendung im Cookie gespeichert werden. Beachten Sie jedoch, dass auch Cookies gestohlen werden können = (.

Lassen Sie den Kunden besser die von ihm angegebene Schlüsselphrase eingeben, die zusammen mit seinen Daten auch in der Datenbank gespeichert ist.

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 einfach das Cookie übersieht. 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 ;)


quelle
-1

Sie wissen, dass, wenn ein Hacker Zugriff auf Ihre Datenbank erhält, viele persönliche Informationen frei gegeben werden können?

Danach würde ich sagen, dass dies als Idee nicht schlecht ist. Ich würde MD5 oder SHA1 nicht verwenden, da sie für das Hashing nicht sehr sicher sind. Sie können ganz einfach "entschlüsselt" werden (ich weiß, dass es keine Verschlüsselung ist).

Andernfalls würde ich möglicherweise eine zweite Information verwenden, die nicht per E-Mail gesendet wird. Der Grund ist ganz einfach: Wenn jemand Zugriff auf die E-Mail des Benutzers erhält (ganz einfach mit Hotmail, wenn Sie Ihre Sitzung nicht beenden), hat er Zugriff auf alle Informationen, die der Benutzer gesendet hat.

Beachten Sie, dass das HTTPS Daten schützt und verschlüsselt, die von Ihrer Site an den Endbenutzer gesendet werden. Nichts anderes, nimm es als sicheren Tunnel. Nichts mehr, nicht weniger.

Erick
quelle
Wie genau wird ein gesalzener SHA1-Hash im wahrsten Sinne des Wortes entschlüsselt?
Eli
"Sie wissen, dass, wenn ein Hacker Zugriff auf Ihre Datenbank erhält, viele persönliche Informationen frei gegeben werden können?" Ja, aber ist das nicht ein Problem für alle Websites?
Flackou
@Flackou yep, aber wenn Sie Zugriff auf die Datenbank von Paypal erhalten, werden Sie keine klar gespeicherten Kreditkarteninformationen finden, alles ist verschlüsselt. @Eli: theregister.co.uk/2005/02/17/sha1_hashing_broken
Erick
-1

Nach meinem Verständnis Ihrer Idee könnte theoretisch jemand eine zufällige 40-Zeichenfolge oder einen MD5-Hash eingeben und andere Details abrufen. Dies ist zwar höchst unwahrscheinlich, muss aber nur einmal geschehen.

Eine bessere Lösung könnte darin bestehen, dem Benutzer ein Token zu senden und ihn dann aufzufordern, einige Details wie Name, Postleitzahl, SSN oder eine Kombination davon einzugeben.

Richard Slater
quelle
5
SSN? Sind Sie im Ernst? Wie auch immer, ich schlage vor, Sie rechnen nach, wie viele zufällige Zeichenfolgen mit 40 Zeichen vorhanden sind. Es ist mehr als nur "höchst unwahrscheinlich"
Eli
Sie haben Recht, wir sollten wahrscheinlich einen weiteren Parameter in die URL einfügen, wie z. B. die E-Mail (auch wenn a..z + A..Z + 0..9 = 62 Zeichen und 62 ^ 40 eine ziemlich große Zahl ist).
Flackou
Leute, 62 ^ 40 ist erheblich mehr als die Anzahl der Atome im Universum. Es ist buchstäblich nicht zu erraten.
Eli
1
Ich bin überrascht, wie viele Leute die Skala dieser Zahlen nicht erfassen können. Wenn Sie eine MILLION Token pro Sekunde erraten haben, ist es weitaus wahrscheinlicher, dass die Sonne ausbrennt, bevor Sie einen Treffer erhalten
Eli
4
Richard, es hört sich so an, als würden Sie darauf hinweisen, was normalerweise als Geburtstagsparadox bezeichnet wird. Es kommt nicht nur auf die Anzahl der möglichen Kombinationen an, sondern auch darauf, wie viele davon verwendet werden. Nun, in diesem Fall müssen Sie ungefähr 2 ^ 119 der 62 ^ 40-Kombinationen verwenden, bevor die Chance signifikant wird.
Erickson