2016-05-27 2 views
0

Ich bin ein wenig verwirrt, wie Cross-Site-Fälschungen zu verhindern. Immer noch. Ich weiß, dass es eine Fülle von Informationen gibt, aber ich bin verwirrt.Cross-Site-Fälschung auf AJAX-Service

In Steven Anderson's post er beschreibt eine Form wie folgt aus:

<body onload="document.getElementById('fm1').submit()"> 
    <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post"> 
     <input name="email" value="[email protected]" /> 
     <input name="hobby" value="Defacing websites" /> 
    </form> 
</body> 

auf einem fremden Ort.

Die angegebene Lösung ist ein "Anti-Fälschungs" -Token, das vom Server generiert wird und an das in versteckter Form alle Anfragen zurückgeschickt werden. Das ist cool, aber was soll den Hacker daran hindern, nur die Formularseite herunterzuladen, das Token zu extrahieren und es zu POSTIEREN?

Meine Bewerbung dafür lautet: Bei der Anmeldung für meine Website möchte ich eine AJAX-Funktion, die den aktuell eingegebenen Benutzernamen an den Server sendet, der "True/False" antworten soll, wenn er verfügbar ist oder nicht. Dies geschieht onKey, so dass der Benutzer einen Benutzernamen auswählen kann, der noch nicht verwendet wurde. Die Schaltfläche Senden wird aktiviert, wenn alle Bedingungen für "neuer Benutzer" erfüllt sind.

Offensichtlich ist dies eine Gelegenheit für einen Hacker, den Dienst zu verwenden, um viele Benutzernamen zu "prüfen", um zu sehen, ob sie verfügbar sind - ich weiß, es ist nicht genau Internet-Banking-Ebene Art von Risiko, aber ich möchte immer noch bedienen nur Anfragen von meiner Anwendung, kein Hacker.

Irgendwelche Ideen wie über diese Fragen?

UPDATE:

Also in meinem Szenario. Ich erzeuge ein Token (sagen wir einen Hash-Wert der IP-Adresse des Clients) und der Dienst erwartet, diese zurück zu erhalten, wenn es die Information gibt, ob der Benutzername verfügbar ist oder nicht.

- Das Problem bleibt, jemand aus der Domäne ruft einfach den Dienst an, z.B. /generateToken Dies sieht auf die IP des Kunden ... könnte ein Hacker sein, der weiß.

Returns

{ token: 4uru32br } 

die dann an den/isUsernameAvailable vorgelegt wird? Token = 4uru32br & partialUsername = usernam

Wo das mir bekommt?

+0

"aber was soll der Hacker stoppen, indem er einfach die Formularseite herunterlädt, das Token extrahiert und es postet?" Ein Hacker wird seinen eigenen Token statt des Opfers abschreiben. – PeeHaa

+1

Beachten Sie auch, dass ein CSRF-Token keine Anmeldeversuche einschränkt, da dies ein völlig anderes Problem ist als die Anfragefälschung. – PeeHaa

Antwort

-1

Das Anti-Fälschungs-Token ist kein zufälliger Code. Noch ein wiederverwendetes Token für mehrere Anfragen.

Stattdessen koppelt der Server das Token mit der IP-Adresse oder Sitzung des Anrufers, zum Beispiel durch Verschlüsselung des ip + salt mit einem Serverschlüssel.

Wenn also der Angreifer versucht, die Token von der Website herunterladen, wird es durch die reale Client nicht verwendet wird

+0

"Das Anti-Fälschungs-Token ist kein zufälliger Code". Warum nicht? – PeeHaa

+0

Da, wenn der Server alle Token zusammen mit den Clients IP speichern musste, wäre es eine Menge zu speichern, denke ich. Vor allem, wenn Backup und Reposting erlaubt sein sollten. Günstiger, um einen verschlüsselten Status an den Client zu senden. –

+0

Nun, das ist auf der falschen Annahme imo ... – PeeHaa

0

was den Hacker zu stoppen, ist einfach das Formular Seite herunterladen, das Token zu extrahieren und POST es?

Die same-origin policy, das ist was.

Ich möchte eine AJAX-Funktion, die den aktuell eingegebenen Benutzernamen an den Server sendet, der "True/False" antworten sollte, wenn es verfügbar ist oder nicht.

Das ist eine Benutzer-Enumeration Schwachstelle genau dort.

Irgendwelche Ideen wie über diese Fragen?

Hier ist Ihr neuer Prozess:

  1. Verwenden E-Mail-Adressen für Benutzernamen.

  2. Verwenden Sie CAPTCHA, um die Automatisierung von Registrierungsformularen zu verhindern.

E-Mail Benutzername existiert nicht:

Show "Erfolg" -Meldung. Senden Sie eine E-Mail an eine Adresse mit einem einmaligen Link. Registrieren Sie Benutzer nach der Rückkehr zu Ihrer Website mit diesem Link.

E-Mail Benutzername existiert:

Show "Erfolg" -Meldung. Senden Sie eine E-Mail an diese Adresse mit der Nachricht "Jemand versucht, ein Konto mit dieser Adresse zu erstellen, aber es existiert bereits".

0

Sie vermischen CSRF und user enumeration.

Die Lösung gegeben ist, ein „Fälschungs“ Token vom Server generierte, die POST-ed zurück auf alle Anfragen mit in einer versteckten Form vorliegt. Das ist cool, aber was ist zu stoppen der Hacker nur das Herunterladen der Formularseite, Extrahieren des Tokens und POSTing es?

Say Bob ist ein normaler Benutzer auf Ihrer Website.

Chuck ist ein böser Angreifer.

Bob geht auf Ihre Website und sendet das Kommentarformular (in Ihrem Codebeispiel). Wenn es CSRF-Schutz ist, wird ein Token auch in dieser Form enthält:

<input type="hidden" name="csrf_token" value="zxcvbnnmm1235152" /> 

Bob Session-Token zxcvbnnmm1235152 für ihn serverseitige gespeichert hat.

Chuck hat auch einen Login zu Ihrer Seite, weil er sich registriert hat.

Doch als er auf dieser Seite geht bekommt er dieses Token statt:

<input type="hidden" name="csrf_token" value="lklkljlk898977" /> 

Wenn Chuck die Seite herunterlädt, Bob bekommt irgendwie (zB sendet ihm eine E-Mail), um diese Seite auf Chuck-Server zugreifen zu können, weil die csrf_token passt nicht zu Bobs, Chuck kann die Nachricht nicht als Bob posten.

Bob kann gut weitermachen, weil das Token im Formular mit dem seiner Sitzung übereinstimmt.

Bei CSRF geht es darum, Chuck davon abzuhalten, als Bob Bobs Surf-Session zu verwenden.

für diese Meine Anwendung ist: Auf der Anmeldung für ich auf meiner Website möchte eine AJAX-Funktion, die die aktuell eingegebenen Benutzernamen an den Server sendet die „Wahr/Falsch“ antworten sollte, wenn es verfügbar oder nicht. Dies geschieht onKey, so dass der Benutzer einen Benutzernamen auswählen kann, der nicht bereits verwendet wurde. Die Schaltfläche Senden wird aktiviert, wenn alle Bedingungen für "neuer Benutzer" erfüllt sind.

Natürlich ist dies eine Chance für einen Hacker den Dienst „test“ viele Benutzername zu verwenden, um zu sehen, wenn sie zur Verfügung - ich weiß, es ist nicht genau Internet-Banking-Niveau Art von Risiko, aber ich würde immer noch gerne zu nur Anfragen von meiner Anwendung, kein Hacker.

Ja, dies ist Ihre Sicherheitsanfälligkeit durch Benutzerauflistung.

Haben Sie Benutzername als E-Mail, und folgen Sie this answer, um dies zu sichern.

Verwandte Themen