bei folgendem Szenario: Wir haben ein HTML-Formular zum Ändern eines Kontopassworts. Es sieht so aus:
%Vor%Wir möchten diese Anfrage über einen Ajax-Aufruf senden. Wenn wir es senden und wir unseren Computer verlassen (ohne sich abzumelden und auf der gleichen Seite zu bleiben), könnte jemand den Webkit-Inspector (oder Firebug) öffnen und so etwas sehen:
Was wäre Ihre Lösung, um das sicherer zu machen? Ist es sogar möglich, hier einen Ajax-Aufruf zu verwenden, oder wäre es besser, ein "normales" HTML-Formular zu verwenden, das nach dem Senden die gesamte Seite neu lädt?
Der Autor ist hier nicht an verschlüsselten Verbindungen interessiert. Er könnte das auch schon tun. Er möchte das Passwort (und den Benutzernamen) vor jedem verstecken, der Zugriff auf den Computer hat, und kann die Inspektor-Tools öffnen, um das Netzwerk auf der Seite anzuzeigen.
Eines der einfachsten Dinge, die Sie tun könnten, ist, die Seite zu aktualisieren, falls die Authentifizierung erfolgreich war.
Sie sollten die Seite aktualisieren, wenn der Benutzer auf "Abmelden" klickt. Dies sollte alle vorherigen Netzwerkdaten löschen.
Die weniger guten Optionen sind das Verschlüsseln, Verschleiern und Hashing des Passworts vor dem Senden.
Es ist nicht ideal, das Passwort auf der Client-Seite zu hacken, da dies die Verwendung von Hash-Passwörtern mit Schlüsseln auf der Serverseite verhindert (denke HMAC). HMAC'd-Passwörter sind die besten, da der Schlüssel im Dateisystem verbleibt, während das Salz in der Datenbank gespeichert wird. Das Cracken des Passwort-Hashes erfordert einen recht soliden Zugriff auf das System.
Das Verschleiern und Verschlüsseln des Passworts kann umgekehrt werden. Wenn jemand im Webkit-Inspektor eine Anmeldeanforderung sieht, ist er möglicherweise sehr daran interessiert, die Zeit für das Ausziehen der Abwehr zu nutzen.
Ich empfehle dringend, die Seite irgendwann zu aktualisieren, um das Problem vollständig zu vermeiden. Andere Optionen scheinen nicht so gut.
Die Verwendung eines "normalen" HTML-Formulars hat das gleiche Problem, da Paket-Sniffing die gleichen Daten in einem POST- oder GET-Header ebenso leicht aufdecken kann.
Die beste Lösung, die mir einfällt, ist die Verschlüsselung des Passworts auf der Benutzerseite über Javascript. Sie müssen sich nicht wirklich Sorgen machen über das "Was ist, wenn der Benutzer JavaScript deaktiviert hat?" Fall, da in diesem Fall auch die AJAX-Anfrage nicht durchlaufen wird. Offensichtlich kann dies Auswirkungen auf die Speicherung des Passworts haben, aber Sie können weiterhin AJAX-Anfragen für das Passwort-Update verwenden.
Um dies ohne Verwendung von SSL zu gewährleisten, sollten Sie die Passwörter auf dem Client mithilfe von SHA-2 hashen >. Während dies das Passwort selbst schützt, schützt es niemanden davor, das hashed Passwort zu schnüffeln. Sie können sich also auch nicht einfach mit dem Hash-Passwort authentifizieren.
Eine Möglichkeit, dies zu tun, ist die Verwendung eines vom Server generierten Zufallssalzes bei der Authentifizierung. Um sich zu authentifizieren, fordert der Client das Salt vom Server an, hasht das Passwort dann einmal (um die auf dem Server gespeicherte Hash-Version abzugleichen), Hashes erneut mit dem vom Server empfangenen Salt und authentifiziert sich schließlich mit einem zweiten Ajax Abfrage mit dem gesalzenen Hash-Passwort.
Der Server authentifiziert sich nur dann, wenn dies mit seinem eigenen gespeicherten Hash-Passwort übereinstimmt, das mit dem gleichen Salto-Hash-Wert wie der Client behandelt wurde.
Auf diese Weise ist es für jemanden unmöglich, sich mit der einfachen Hash-Version des Passworts zu authentifizieren. Da jedes von dem Server bereitgestellte Salz nur einmal gültig ist, ist es im Wesentlichen unmöglich für jemanden, es abzufangen und zu authentifizieren. (Sie müssten die Salzanforderung abfangen und dann versuchen, sich zu authentifizieren, bevor der legitime Client die Sitzung verfälschen könnte).
Dies schützt die Benutzerkennwörter ohne Verwendung von SSL, verhindert die Anmeldung mit Daten, die während der Authentifizierung des berechtigten Benutzers abgefangen werden, und ist relativ einfach zu implementieren. Natürlich gibt es keinen Ersatz für SSL, was den Schutz der tatsächlichen Daten auf Ihrer Website betrifft, aber für viele typische Websites, auf denen es wirklich keine sensiblen Informationen gibt, sollten Sie sich mehr Gedanken darüber machen, den Diebstahl von Passwörtern Ihrer Benutzer zu verhindern benutze das selbe Passwort so oft. Dies adressiert dieses Problem.
Beachten Sie, dass dies auch nicht dazu beiträgt, Session-Hijacking zu verhindern, aber Sie können das Risiko und den Schaden minimieren, indem Sie z. B. browserspezifische Informationen in die Sitzung des Benutzers aufnehmen und nur eine aktive Sitzung auf einmal zulassen Neuauthentifizierung, um die E-Mail-Adresse oder das Passwort zu ändern.
Abhängig von der Sicherheitsstufe, die Sie benötigen, können Sie RSA und die Kryptographie mit öffentlichen Schlüsseln verwenden, um das Kennwort zu verschlüsseln der Browser vor dem Senden der Ajax-Anfrage. Auf der Serverseite würden Sie die Kennwörter entschlüsseln und wie gewohnt verarbeiten.
Natürlich müssen Sie auch sorgfältig alle Variablen löschen, die zum Speichern der eingegebenen Passwörter verwendet werden, und ich bin mir sicher, dass es andere Sicherheitslücken gibt, aber die Verschlüsselung bietet Ihnen zumindest einen gewissen Schutz davor Art von Angriff.
Hier ist eine Bibliothek, die ich gefunden habe mit einer schnellen Suche. (Disclaimer: Ich habe das nicht getestet, aber es sieht ziemlich gut aus)
Zum Schluss empfehle ich Ihnen dringend, alle Anmeldeinformationen über SSL zu übermitteln. Dies fügt eine zusätzliche Sicherheitsebene über die gesamte Browsersitzung zwischen dem Browser und Ihrem Server hinzu.
Tags und Links javascript html security ajax