In MVC-Umgebung bei JS-Validierung auf Datenbank zugreifen

[Rolf B]

Hallo T-Rex,

diesen Hacking-Versuch kannst Du genausogut mit dem POST des Signup-Forms fahren. Denn das muss ja auch maulen, wenn man einen existierenden User oder eine existierende Mailadresse registrieren will.

Deswegen muss man beides gegen Böse Spionagebots absichern.

Verteidigungslinie 1

Beim Programmieren der Seite darauf achten, den Ajax-Service nicht zu oft aufzurufen. Wenn nach jedem Tastendruck geprüft wird, ob der User schon existiert, ist das zu viel. Höchstens nach dem Verlassen des Username-Eingabefeldes (blur-Event). Zu häufige Aufrufe machen der Linie 2 und 4 das Leben schwerer.

Verteidigungslinie 2

Life-Analyse der eingehenden Requests auf Hochfrequenz-Abrufe. Ich bin kein Experte an dieser Stelle - aber es gibt bspw. Tools, die die Apache-Logs analysieren und bei bestimmten Mustern die IP sperren, die unangenehm auffällt. Das hilft aber nur gegen einzelne Angreifer. Eine verteilte Attacke aus einem Botnetz ist schwerer zu erkennen. Dies in PHP umzusetzen ist auch möglich, aber eigentlich gehören solche Erkennungen auf die Webserver-Ebene.

Verteidigungslinie 3:

Cross Site Request Forgery Abwehrmaßnahmen. Mit getrennten XSRF-Tokens für POST und AJAX-Call.

Verteidigungslinie 4:

Mitzählen im AJAX-Service. Dein Bot könnte die Browsermütze aufsetzen, per GET die Signup-Seite abrufen und sich so das XSRF-Token sowie die Session-ID beschaffen. Damit kann er dann fleißig User-IDs überprüfen. Um das zu verhindern, darf das XSRF-Token nur für eine bestimmte, kleine Anzahl von Aufrufen gültig sein. Ist diese überschritten, meldet der AJAX-Call einfach immer nur "Kenn ich nicht".

Natürlich kann man das durch Erstellen einer neuen Session aushebeln. Aber das ist dann (a) mehr Arbeit für den Bot und (b) fällt er dann noch eher der Verteidigungslinie 2 auf.

Ein regulärer User kann natürlich diese Schwelle ebenfalls überschreiten. Aber das macht nichts. Der offizielle POST des Signup-Formulars muss die gleiche Prüfung ohnehin auch noch mal machen, und weist die User-ID oder Mailadresse zurück.

Verteidigungslinie 5:

▪️ Bei einem Fehl-Login nicht mitteilen, ob User oder Passwort falsch war

▪️ Zu viele Fehl-Logins für einen bekannten User: den User sperren oder zum Lösen eines Captchas verdammen

▪️ Zu viele Login-Versuche einer IP mit unbekannten User-IDs: IP für 24h bannen

Andererseits - Komfort und Security passen nicht wirklich zusammen. Die Life-Überprüfung ist Komfort und vielleicht nice-to-have, aber nicht nötig. Eine sofortige Bestätigung des Signup ist ebenfalls Komfort und nicht unbedingt nötig. Beides bietet Schnüfflern Angriffspunkte.

Eine Absicherung gegen Schnüffler erreicht man auch, indem man überhaupt nicht live antwortet, sondern grundsätzlich und immer mitteilt, dass man unter der angegebenen Mailadresse eine Mail mit einer Beschreibung der weiteren Schritte vorfinden würde. Damit ist das Raten von Mailadressen schonmal beseitigt. Das Raten von Usernamen via Signup bedeutet nun, dass der Bot nicht nur HTTP sprechen, sondern auch noch die Antwortmails analysieren muss. Kann man machen, sicher, ist aber eine Schwelle mehr. Möchte man sich auch dagegen absichern, könnte man wieder zu Frequenzanalysen greifen und die Anzahl von Signup-Versuchen von einer IP oder die Anzahl von Registrierungsmails an eine Adresse tracken. Ein Angreifer müsste das mit einem Botnetz sowie einer größeren Menge von Postfächern, vorzugsweise bei unterschiedlichen Anbietern, kontern. Und damit kommt man in den Bereich, wo eine Attacke auf die Seite einfach nicht mehr lohnt. Seiten, bei denen es sich dennoch lohnt, sollten ohnehin keinen automatischen Signup-Prozess haben.

Die Anzahl von Registrierungsmails muss man eh tracken, zumindest pro Mailserver, andernfalls kann man durch einen solchen Schnüffelangriff auf die Spam-Liste befördert werden.

Rolf