Das wichtigste Problem bei diesem Ansatz ist, dass in Ihrem Beispiel nur das erste eine syntaktisch gültige E-Mail-Adresse ist. Die drei anderen sind es nicht. Dies bedeutet, dass eine der beiden folgenden Optionen gilt:

1. Die "E-Mail-Adresse" ist lediglich ein Vorschlag. Das System möchte eine eindeutige Anmeldekennung. E-Mail-Adressen sind eine recht gute Kennung, da sich Benutzer an sie erinnern und das E-Mail-System bereits weltweite Einheitlichkeit gewährleistet.

2. Die E-Mail-Adresse sollte eigentlich eine E-Mail-Adresse sein (z. B. zum Senden von E-Mails) an diese Adresse), und das Registrierungssystem kann nicht überprüfen, ob der vom Benutzer eingegebene E-Mail-Adresse ist.

ol>

Im letzteren Fall bedeutet dies, dass E-Mails nicht gesendet werden vermittelt, und auch, dass der Entwickler in Bezug auf die Validierung von Benutzereingaben sehr schlampig war, was im Allgemeinen kein gutes Zeichen für die Sicherheit ist.

Wenn die Bezeichner jedoch Freiform sind, dann was Sie sehen ist das Ergebnis der Kreativität menschlicher Benutzer. Dies ist kein Problem, solange die Anmeldekennungen für das verwendet werden, was sie sind. Leerzeichen, Semikolons ... können schlecht implementierte Skripte oder Anwendungen zerstören. (Versuchen Sie, sich mit einem Kontonamen zu registrieren, der ein einfaches Anführungszeichen enthält, falls eine mögliche SQL-Injection möglich ist.)

Nur die erste E-Mail-Adresse ist tatsächlich eine gültige Adresse. Natürlich ist die E-Mail-Adressvalidierung schwierig, daher ist es nicht sinnvoll, eine perfekte Validierung zu implementieren. Sie können die Validierung maximal approximieren, und aus Gründen der Benutzerfreundlichkeit sollten Sie mit Ihrem Filter nachsichtig umgehen. Aus diesem Grund sollten Sie Ihre Sicherheit nicht auf die Gültigkeit von E-Mail-Adressen stützen.

Wenn Sie jedoch eine E-Mail-Adresse für die Registrierung benötigen, ist es üblich, einen Bestätigungslink an diese Adresse zu senden (um dies zu verhindern) Tippfehler usw .; wenn Sie dies nicht tun, kann dies tatsächlich als Sicherheitsproblem angesehen werden. Dies würde Ihr Szenario unmöglich machen.

In beiden Fällen handelt es sich nicht um ein Sicherheitsproblem. Ihre Authentifizierung sollte mit ähnlichen Namen umgehen können, andernfalls ist sie fehlerhaft .

Ich würde jedoch mit Leerzeichen am Anfang oder Ende vorsichtig sein, da es ziemlich oft vorkommt, dass sie irgendwann abgeschnitten werden, was tatsächlich Probleme verursachen kann.

Davon abgesehen Es gibt nur zwei kleine Probleme:

• Tippfehler: Möglicherweise gibt es einen Benutzer test@example.com: 123456 und einen Benutzer test@example.co : 123456 . Wenn einer von ihnen versehentlich seine Anmeldeinformationen falsch eingibt, landet er möglicherweise auf dem Konto des anderen Benutzers. Dies ist jedoch ein ziemlicher Zufall, und ich würde aus Gründen der Benutzerfreundlichkeit nicht versuchen, mich dagegen zu verteidigen.
• Identifizierung: Sie können E-Mail-Adressen anstelle von Benutzernamen anzeigen, sodass ein Benutzer möglicherweise einen anderen Benutzer imitieren kann . In Ihrem Beispiel sind beispielsweise test@test.com und test@test.com schwer zu unterscheiden. Dies ist jedoch wiederum ein Eckfall, da normalerweise Benutzernamen zur Identifizierung und keine E-Mail-Adressen angezeigt werden.

Alle bis auf die erste sollten abgelehnt werden, nur weil sie keine gültigen E-Mail-Adressen sind.

Wenn Sie &paste wörtlich in Ihren bevorzugten E-Mail-Client kopieren, können sie möglicherweise das tun, was Sie erwarten. aber das wahrscheinlichste Verhalten ist, dass es sie alle gleich interpretiert. Wenn Sie also möchten, dass E-Mail-Adressen Benutzer eindeutig identifizieren, sollten Sie darauf bestehen, eine (genau eine) syntaktisch korrekte E-Mail-Adresse in das Registrierungsformular einzugeben.

Es gibt definitiv ein Sicherheitsproblem, das von einem Anbieter herrührt, der die Registrierung nahezu identischer E-Mail-Adressen ermöglicht. Aber es ist nicht ganz das, was Ihre spezifischen Beispiele testen. Die Auswirkungen sind nicht unbedingt auf Benutzer des E-Mail-Dienstes beschränkt, sondern können sich allgemeiner auf jeden auswirken, der E-Mails von einem Benutzer dieses Dienstes empfängt. Die Gefahr, von der ich spreche, besteht darin, dass sich ein Benutzer des Dienstes an E-Mail-Empfänger ausgibt.

Um zu sehen, was ich meine, lassen Sie uns zunächst die verwirrenden (bereits gut diskutierten) Probleme beiseite legen, was eine gültige E-Mail-Adresse ist und was nicht und ob die ID eines Benutzers tatsächlich mit der externen E-Mail-Adresse des Benutzers übereinstimmt . Schauen wir uns stattdessen das folgende Szenario an:

Angreifer möchten, dass Malware auf Jane Smiths Computer implantiert wird. Der Angreifer kennt die E-Mail-Adresse von Jane Smith, weiß, dass Jane Smith eng mit John Anderson befreundet ist, und weiß, dass John Anderson eine aktive E-Mail-Adresse bei einem Webmail-Anbieter mail.com unter JohnAnderson@mail.com unterhält. Der Angreifer überprüft den Registrierungsprozess von mail.com und stellt erfreut fest, dass der Dienst es ihm ermöglicht, johnanderson@mail.com (ohne Großbuchstaben) als gültige Adresse zu registrieren. Der Angreifer legt seinen "Von" -Namen für das Konto als "John Anderson" fest und beginnt, eine E-Mail zum Speerfischen zu verfassen, die sich an Jane Smith richtet. Der Angreifer findet im Internet ein PDF-Dokument, das wie die Art von Element aussieht, die sowohl John Anderson als auch Jane Smith für beide Seiten interessant finden könnten, und verwendet dann SET, um einen PDF-Exploit und eine böswillige Nutzlast in dieses Dokument einzufügen.

Angreifer sendet die Nachricht. Am Ende von Jane Smith erhält sie eine E-Mail von "John Anderson" an die Adresse johnanderson@mail.com. Die Nachricht ist eine Weiterleitung eines PDF-Artikels mit einer Ein-Satz-Empfehlung von John: "Ich bin gerade damit fertig und denke, Sie werden es als lesenswert empfinden. Ich bin mir nicht sicher, ob ich allen Punkten des Autors zustimme, aber sehr, sehr interessant. "" Und weil mail.com kryptografisch bestätigt, dass die Nachricht tatsächlich von der angeblichen Adresse stammt, hat Jane Smiths E-Mail-Dienst die Nachricht in ihren Posteingang geleitet, anstatt sie in den Spam-Ordner zu werfen (wie es passieren könnte, wenn Attacker die Nachricht einfach fälscht) "von der Adresse).

Rhetorische Frage: Wie hoch ist die Wahrscheinlichkeit, dass Jane Smith diesen PDF-Anhang öffnet?

Antwort: ungefähr so ​​hoch wie für einen Speerfischangriff. (Zumindest ohne Zugang zum E-Mail-System ihres Arbeitgebers zu erhalten und sich als ihr Chef auszugeben, oder so ähnlich.)

Die Wahrscheinlichkeit, dass ein typischer Benutzer erkennt, dass JohnAnderson@mail.com, johnanderson @ mail.com oder sogar JAnderson@mail.com sind nicht die gleichen Absender sind ziemlich niedrig. (Wenn der Benutzer im Allgemeinen sehr sicherheitsbewusst ist, steigen offensichtlich die Erkennungswahrscheinlichkeiten. Ich vermute jedoch nicht so viel, wie manche vermuten.) Wenn die tatsächliche E-Mail-Adresse der realen Person, die der Angreifer zu verkörpern versucht, bereits vorhanden ist Im Adressbuch des Empfängers, bevor die E-Mail des Angreifers eintrifft, kann der Empfänger (möglicherweise), wenn er die Nachricht erhält, feststellen, dass der Absender dieser bestimmten Nachricht nicht dort ist, wie es der Empfänger erwarten würde . Und er oder sie könnte (könnte) das ein wenig verdächtig finden. Andererseits geht er oder sie eher davon aus, dass der Korrespondent aus irgendeinem Grund eine E-Mail von einer neuen, etwas anderen Adresse gesendet hat. Oder dass die Adressbuchfunktion seines E-Mail-Dienstes schwierig war. Oder ...

Sie verstehen: Diese Taktik des Identitätswechsels bei engen E-Mail-Adressen kann bei Phishing- / Speerfischangriffen sehr mächtig sein (wenn sie manchmal übersehen wird).

Was E-Mail-Anbieter tun können und wollen Um zu versuchen, sehr ähnliche Adressregistrierungen zu sperren, ist es eine schwierige Praxis, effektiv zu bekämpfen, selbst wenn ein E-Mail-Anbieter dies wünscht. Und wenn man bedenkt, dass ein bestimmter E-Mail-Anbieter es vorziehen würde, potenzielle Benutzer zu registrieren, "Entschuldigung, diese Adresse / Benutzer-ID ist bereits vergeben." So oft wie möglich (wenn sie diese Nachricht genug erhalten, geben sie möglicherweise einfach auf und prüfen, ob ein anderer E-Mail-Dienst einen ihrer gewünschten Namen frei hat) besteht der Anreiz für E-Mail-Dienste darin, die Registrierung praktisch jeder technisch gültigen E-Mail-Adresse (mit wenigen) zu ermöglichen Ausnahmen).

Stimmen Sie allen anderen zu, dass die erste E-Mail-Adresse die einzig gültige ist. Ich möchte auch darauf hinweisen, dass es eine schlechte Praxis ist, zusätzliche Leerzeichen am Ende eines Anmeldenamens zuzulassen. Wenn ich das richtig verstehe, versuchen Sie, mögliche Ähnlichkeiten bei Benutzer- / Kundenanmeldungen am System herauszustellen.

Als Antwort auf Ihre Frage: "Sollte dies als Sicherheitsproblem angesehen werden?" Meine Antwort wäre "Nein" für diejenigen, die keine zusätzlichen Leerzeichen enthielten. Ansonsten ja ... aber hauptsächlich aus dem Grund unten.

Ihre Frage; "Kann jemand bestimmte Sicherheitsprobleme vorschlagen, zu denen dieses Setup führen könnte?" Auf den ersten Blick gibt es zwar möglicherweise ein paar mehr, als mir derzeit bekannt ist, aber das einzige, was ich in Betracht ziehen würde, ist eine Art Injektionsproblem. Dies hängt jedoch davon ab, wie die zusätzlichen Leerzeichen in Ihrer Codierung definiert sind. Wenn es gut genug verriegelt ist, sollte es kein Problem geben. Andererseits werden alle Arten von Techniken auf immer neue Weise eingesetzt. Also ist nichts wirklich jemals völlig sicher. Man kann also nur auf eine bessere Sicherheit hoffen und versuchen, diese zu erreichen.

Ich entwickle Webanwendungen, um meinen Lebensunterhalt zu verdienen, und das kann ich sagen. Es ist zwar kein "großes" Sicherheitsrisiko, aber es ist sicherlich eine schlampige Entwicklung, jemandem zu erlauben, sich bei test@test.com zu registrieren. und / oder 'test@test.com'.

Einfach, weil der Entwickler nicht die normalerweise minimale Zeit zum Hinzufügen der Eingabevalidierung benötigt hat. Ich meine sogar mit einfachem HTML5, wenn Sie eine

  <input type = "email" / >  

verwendet und eine der beiden zweiten E-Mail-Adressen ausprobiert haben Der Browser selbst würde Ihnen einen Fehler anzeigen, der besagt: "Keine gültige E-Mail-Adresse (zu diesem Zeitpunkt noch nicht getestet, aber ich gehe davon aus, dass HTML5 seit einiger Zeit Mainstream ist).

Aber als Entwickler sind Sie Niemals zulassen, dass sich jemand mit etwas in seiner E-Mail registriert, das nicht vorhanden sein sollte. Wie *, &, ^, $ usw. Es sollte (meiner Meinung nach) eine gültige alphanumerische E-Mail sein, die mit endet an @ Something.com / net / org usw.

Es ist sehr schlecht, die Eingabe von Formularen nicht ordnungsgemäß zu validieren. Dies gilt insbesondere dann, wenn es sich um potenzielle Kundendaten oder Kundendaten, Studentendaten und dergleichen handelt. Für Spam-Bots oder andere Formen böswilliger Bots / Menschen ist es sehr einfach, diesen Fehler zu finden, zu erkennen und die Lücke im Eingabeprozess auszunutzen. Dies kann ein Sicherheitsrisiko darstellen.

Nur meine zwei Cent aber. Hoffe es hilft.