Wie sollten Anmeldeformular-Fehlerantworten angezeigt werden?

Ich habe eine abonnementbasierte Anwendung, die mit MERN erstellt wurde. Ich habe den Antrag kürzlich zum Sicherheitstest eingereicht und eine der Antworten, die ich erhalten habe, war, dass der Antrag dem Benutzer nicht ausdrücklich mitteilen sollte, warum sein Registrierungsantrag für alle Fälle abgelehnt wurde. Wenn sie beispielsweise einen bereits registrierten Benutzernamen oder eine bereits registrierte E-Mail-Adresse eingeben, sollte ich keine Fehlermeldung zurückgeben, die besagt: „Entschuldigung, dieser Benutzername ist bereits registriert", da dies dem Benutzer ermöglichen würde, eine Liste mit Benutzern und E-Mails zu erstellen die sich auf unserer Seite registriert haben.

Ich verstehe, warum wir dies verhindern müssen, aber ich verstehe nicht, wie ich dem Benutzer mitteilen kann, warum die Anmeldung fehlgeschlagen ist, ohne ihm mitzuteilen, dass dies daran liegt, dass diese E-Mail bereits registriert wurde. Es scheint sinnlos, ihr Anmeldeformular abzulehnen, ohne ihnen einen bestimmten Grund zu nennen. Weiß jemand, was hier am besten zu tun ist?

Lösung des Problems

Ich habe eine abonnementbasierte Anwendung, die mit MERN erstellt wurde

Die Tatsache, dass Sie MongoDB, Express, React und NodeJS verwenden, ist irrelevant dafür, wie Ihre Endbenutzer und Besucher Ihr Produkt verwenden.

Ich habe kürzlich den Antrag auf Sicherheitsprüfung gestellt...

Achtung - die meisten "Sicherheitsberater", denen ich begegnet bin, die anbieten, "Analysen" durchzuführen, führen einfach einige Standardskripte und Schwachstellen-Scanner gegen eine Website aus und retuschieren dann die generierten Berichte leicht, damit sie handgeschrieben aussehen.

Eine der Antworten, die ich erhielt, war, dass die Anwendung dem Benutzer nicht ausdrücklich mitteilen sollte, warum sein Registrierungsantrag für alle Fälle abgelehnt wurde

Hnnnng - nicht in "allen" Fällen, ja - aber leider sind Benutzerfreundlichkeit und Sicherheit tendenziell entgegengesetzte Enden einer Wippe, die Sie sorgfältig ausbalancieren müssen.

Wenn Sie kein Experte oder anderweitig unerfahren sind, würde ich Ihren Sicherheitsberater um eine vollständige Liste der Fälle bitten, in denen er die Offenlegung schädlicher Informationen für möglich hält, und Sie sollten diese Liste dann von Ihrem UX-Team (und Ihrem Rechtsteam), um sie wiegen zu lassen.

Ich möchte hinzufügen (wenn nicht sogar betonen), dass die Sicherheitsszene für Webanwendungen voll von Sicherheitstheater- und Cargo-Kult-Programmierungspraktiken ist und schlechte und veraltete Ratschläge zu lange in den Köpfen der Leute bleiben (z darauf zu bestehen, alle ~90 Tage Ihr Passwort zu ändern?

Wenn sie beispielsweise einen bereits registrierten Benutzernamen oder eine bereits registrierte E-Mail-Adresse eingeben, sollte ich keine Fehlermeldung zurückgeben, die besagt: „Entschuldigung, dieser Benutzername ist bereits registriert", da dies dem Benutzer ermöglichen würde, eine Liste mit Benutzern und E-Mails zu erstellen die sich auf unserer Seite registriert haben.

Bevor Sie bestimmte Szenarien in Betracht ziehen, überlegen Sie sich zunächst die Art Ihrer Webanwendung und Ihr Bedrohungsmodell und fragen Sie sich, ob der Schaden für die Endbenutzererfahrung durch die Sicherheitsgewinne gerechtfertigt ist oder ob überhaupt ein tatsächlicher Sicherheitsgewinn vorliegt.

Zum Beispiel und unter besonderer Berücksichtigung dieses Problems (dh Benutzer auf der Registrierungsseite nicht zu informieren, wenn ein Benutzername und/oder eine E-Mail-Adresse bereits verwendet werden) würde ich argumentieren, dass dies für eine öffentliche Internet-Website mit einem allgemeinen Publikum der Fall ist Benutzernamen (dh Login-Namen, Bildschirmnamen usw.) sind nicht besonders sensibel und normalerweise veränderbar, sodass dem Endbenutzer kein wirklicher Schaden entsteht, wenn offengelegt wird, ob ein Benutzername bereits vergeben ist oder nicht.

...aber die Existenz oder Einzelheiten einer E-Mail-Adresse in Ihrer Benutzerkontendatenbank sollten im Allgemeinen nicht an nicht authentifizierte Besucher weitergegeben werden. Ich glaube jedoch nicht, dass dies wirklich vor Besuchern verborgen werden kann: Wenn jemand Ihr Registrierungsformular mit vollständig gültigen Daten ausfüllt (mit Ausnahme einer bereits verwendeten E-Mail-Adresse) und die Website den Registrierungsversuch mit einem vagen oder ablehnt völlig nutzlose Fehlermeldung, dann wird ein unerfahrener Benutzer frustriert sein und aufgeben (und denken, dass Ihre Website einfach kaputt ist), während ein böswilliger Benutzer (mit sogar Grundkenntnissen über die Funktionsweise von Webanwendungen) sofort erkennen wird, dass die E-Mail-Adresse verwendet wird, da sie funktioniert, wenn er eine andere E-Mail-Adresse eingibt - ergo: Sie haben keinen wirklichen Sicherheitsvorteil gewonnen und gleichzeitig Geschäfte verloren, weil Ihr Registrierungsprozess schmerzhaft erschwert wird.

Betrachten Sie jedoch alternative Ansätze:

Ein möglicher alternativer Ansatz speziell für dieses Problem besteht darin, den Anschein zu erwecken, dass die Registrierung erfolgreich war, den böswilligen Benutzer jedoch nicht hereinzulassen, bis er die E-Mail-Adresse über einen per E-Mail gesendeten Link bestätigt hat (was er nicht tun kann, wenn dies der Fall ist ist nicht ihre Adresse), und wenn es sich nur um einen Neuling handelt, der bereits registriert ist und es nicht bemerkt hat, senden Sie ihm einfach eine E-Mail, um ihn daran zu erinnern. Dieser Ansatz ist möglicherweise auf einer Social-Media-Website vorzuziehen, wo es wichtig ist, nichts in Bezug auf die PII anderer Benutzer offenzulegen – aber dieser Ansatz wäre wahrscheinlich nicht für ein Branchensystem geeignet.

Ein weiterer alternativer Ansatz: Verwenden Sie kein eigenes Registrierungssystem: Verwenden Sie einfach OIDC und lassen Sie Benutzer sich über Google, Facebook, Apple usw. authentifizieren und registrieren. Dies erspart Ihren Benutzern auch, sich ein weiteres Passwort zu merken.

Was das Risiko des Sammelns von Informationen angeht: Ich schätze, dass Bots, die große Mengen an Formulareinreichungen brutal erzwingen, wie eine gute Kombination klingen, um niemals Informationen preiszugeben. Eine bessere Lösung besteht darin, einfach ein CAPTCHA hinzuzufügen und Clients zu begrenzen (beide B. durch Begrenzung der Gesamtanforderungen pro Stunde sowie durch künstliche Verzögerungen bei der Verarbeitung der Benutzerregistrierung (z. B. ist es Menschen im Allgemeinen egal, ob ein Registrierungsformular POST 500 ms oder 1500 ms dauert, aber dieser Unterschied von 1000 ms wirkt sich drastisch auf Bots aus.

In all meiner Zeit beim Erstellen von Webanwendungen bin ich nie auf ernsthafte Versuche gestoßen, Informationen über automatisierte Registrierungsformulare oder Anmeldeformulare zu sammeln: Es ist immer nur Marketing-Spam, und das Hinzufügen eines CAPTCHA (auch ohne Ratenbegrenzung) war alles war nötig, um dem ein Ende zu bereiten.

(Die „nicht ernsthaften" Versuche, Informationen zu sammeln, die ich gesehen habe, waren Dinge wie menschliche Nicht-Techniker, die sich manuell „brute-forcen", indem sie über ihre Tastatur tippen: Sie alle geben nach ein paar Dutzend Versuchen auf).

Ich verstehe, warum wir dies verhindern müssen, aber ich verstehe nicht, wie ich dem Benutzer mitteilen kann, warum die Anmeldung fehlgeschlagen ist, ohne ihm mitzuteilen, dass dies daran liegt, dass diese E-Mail bereits registriert wurde. Es scheint sinnlos, ihr Anmeldeformular abzulehnen, ohne ihnen einen bestimmten Grund zu nennen. Weiß jemand, was hier am besten zu tun ist?

Ich habe das Gefühl, dass Sie vielleicht von Ihren "Sicherheitsberatern" betrogen wurden, die in ihrem Bericht an Sie übertriebene Risiken erfunden haben - anstatt dass Ihre Webanwendung tatsächlich der Gefahr ausgesetzt ist, ausgenutzt zu werden.