Welche Angriffe können auf eine Registrierungsseite gerichtet werden

Question

Ich habe eine Website-Registrierungsseite, und ich versuche, eine Liste von dem, was ich tun muss, um es zu schützen, zu kompilieren. Wenn Sie einen Angriff kennen, nennen Sie ihn bitte und beschreiben Sie ihn am besten mit einer kurzen Beschreibung seiner Lösung. Alle hilfreichen Antworten/Kommentare erhalten eine Stimmenmehrheit.

Hier ist, was ich im Sinn habe bisher: (und das Hinzufügen, was andere darauf hindeutet, Puh, das Hinzufügen anderer Eingang viel Arbeit entpuppte, aber bitte immer wieder kommen sie, die ich hier werde weiter hinzuzufügen.)

• SQL-Injektionen: vom Benutzer Eingabedatum. Lösung: vorbereitete Aussagen.

• [AviD] "Stored Procedures auch zusätzliche Vorteile (oben Prepared Statements), wie die Fähigkeit der geringsten Rechte auf dem DB"

  • Guter Punkt, bitte erläutern. Ich dachte, gespeicherte Prozeduren wären die gleichen wie vorbereitete Aussagen. Was ich meine diese Anweisungen waren Sie bindParam die Variablen. Sind sie anders?

• Das Passwort vor der Eingabe von db nicht hashen. Lösung: Hash-Passwörter.

• [AviD] "Re Hashing, das Passwort benötigt ein Salz (zufälliger Wert vor dem Hashing zum Passwort hinzugefügt), um Rainbow Table-Angriffe und Angriffe mit demselben Passwort zu verhindern."
• "das verwendete Salz sollte für jeden Benutzer unterschiedlich sein."
• Guten Punkt, ich habe eine Frage dazu: Ich weiß Salz sollte zufällig sein, sondern auch einzigartig. Wie stellen wir den eindeutigen Teil her, um dem Angriff mit dem gleichen Passwort entgegenzuwirken? Ich habe darüber gelesen, aber noch keine klare Antwort darauf bekommen.

[Inshallah] "wenn Sie eine lange Salz, wie 16 Zeichen für SHA-256 ($ 5 $) verwenden, dann brauchen Sie nicht wirklich seine Einzigartigkeit zu verifizieren"

[Inshallah] „Eigentlich Ich denke, es spielt keine Rolle, ob es Konflikte gibt oder nicht, das Salz dient lediglich der Vermeidung von Tabellen-Lookups, so dass selbst ein 2-Char-Salz ein (kleiner) Gewinn ist, selbst wenn es Konflikte gibt über eine kryptografische nonce hier, die absolut nicht wiederholen müssen. Aber ich bin kein cryptianalyst "

• Guter Punkt, aber hat jemand Disclaimer in diesem Punkt?

Dos Angriffe ?! (Ich schätze, das gilt auch für Anmeldeformulare)

[Pascal Thivent] "Verwenden Sie HTTPs, wenn Sie sensible Daten wie ein Passwort eingeben." "für Man-in-the-Middle-Attacken, vorausgesetzt, dass geeignete Cipher Suites verwendet werden"

• Was sind die "angemessenen Cipher Suites", auf die hier Bezug genommen wird?

• [Koosha] "Verwenden Sie HTTPs oder verschlüsseln Sie Passwörter vor der Einreichung mit MD5 und Javascript auf der Clientseite."

  • ich MD5 nicht einverstanden und weiß nicht, wie auf Client-Seite verschlüsselt, überhaupt keinen Sinn für mich macht. Aber andere Eingang willkommen.

• [Dan Atkinson] Ausschließen bestimmte Benutzernamen, um Konflikte mit bestehenden Seiten zu verhindern, die den gleichen Namen haben (siehe Originalbeitrag für vollständige Antwort und Erklärung)

• [Koosha] "zulässige Zeichen für Benutzername.für zB Alphabet und Zahlen, Strich (-) und Punkt (.) "
  • Bitte genau erklären warum?
• [Stu42] „Use-Check Captcha so dass ein Bot nicht automatisch mehr Konten erstellen kann“
• [AviD] „Es gibt bessere Lösungen als Captcha, aber für eine Website mit niedrigem Wert kann es gut genug sein.“
  • @AviD, bitte erwähnen Sie ein Beispiel?

• [rasputin] "Verwendung E-Mail-Überprüfung"

• [Andrew und epochwolf] XSS-Angriffe

  • Obwohl ich einfach nicht mit Andrew und epochwolf einverstanden < filtern und > oder < in &tl; und> in > umwandeln. Die meisten Meinungen schlagen eine Bibliothek wie HTML Purifier vor. Irgendwelche Eingaben dazu?

Answer 1

HTTPS verwenden, das heißt eine Kombination von HTTP und SSL bieten Verschlüsselung und sichere Identifikation des Servers erstellen kann, wenn wie ein Passwort sensible Daten einreichen. Die Grundidee von HTTPS besteht darin, einen sicheren Kanal über ein unsicheres Netzwerk zu erstellen. Dies stellt einen angemessenen Schutz vor Lauschangriffen und Man-in-the-Middle-Angriffen sicher, vorausgesetzt, dass geeignete Cipher Suites verwendet werden und das Serverzertifikat verifiziert und vertrauenswürdig ist.

Answer 2

Ich denke, man sollte ein Salz verwenden, wenn die Passwörter Hashing.

Answer 3

Verwenden Check Captcha so dass ein Bot nicht automatisch mehrere Konten

Answer 4

Filter Benutzerdaten entfernen '<', '>' - einfach HTML-Tags. Wenn jemand das Profil des Benutzers sehen kann, gibt es mögliche XSS-Angriffe durch Daten.

Answer 5

1. HTTPS verwenden
2. Verwenden Captcha.
3. Begrenzen Sie die zulässigen Zeichen für den Benutzernamen auf der Serverseite. zum Beispiel Alphabet und Zahlen, Bindestrich (-) und Punkt (.).

PS. Clientseitige Verschlüsselung ist keine sichere Methode. Wenn Sie jedoch keine HTTPs verwenden können, ist die clientseitige Verschlüsselung besser als nichts.

Begrenzende Zeichen, es ist eine einfache Möglichkeit, Ihre Software vor Injektionen zu schützen (SQL/XSS).

Answer 6

Sie sollten E-Mail-Überprüfung

und neben Koosha Antwort benutzen: wenn Sie Benutzernamen, einschließlich solcher Zeichen lassen „? # & /“ und Benutzerseiten wie diese site.com/user?me & erstellen Sie/Es kann ein ernstes Problem in Browsern sein. Bitte denken Sie daran in der Adressleiste der Browser.

Answer 7

Wenn die Routen auf Ihrer Website auf eine bestimmte Art und Weise festgelegt sind (dh mit dem Benutzernamen statt ihrer ID), könnte ein Benutzername wie "admin" Probleme verursachen. Sie sollten wahrscheinlich eine Ausschlussliste möglicher Benutzernamen haben.

Dies verursachte Probleme in der Vergangenheit mit MySpace, und Leute mit Benutzernamen wie Login, und dann schmücken ihre Seite mit einem Phishing-Formular.

Edit:

Wie in den Kommentaren von AviD und Peter Boughton erwähnt worden ist, ist es auch eine Möglichkeit, Nutzer irreführend. Nehmen wir an, ein Benutzer hat den Benutzernamen 'admin'. Dann in ihren Benutzerinformationen Seite (unter der Annahme, dass sie jeweils eine, die für alle zugänglich ist, wie SO), haben sie einige Links in ihrem über Abschnitt, der sagt, wie

Für weitere Informationen besuchen Sie unsere dev Blog bei mysite.cn/loginpage

Jemand vielleicht sieht, 'mysite' in der uRL, aber sieht nicht wirklich an der TLD, die China würde (sorry China!), anstatt die .com TLD Ihre Website wird gehostet. Also klicken sie sich durch und nehmen an, dass es in Ordnung ist (sie kamen schließlich von der Admin-Benutzerseite), und diese Seite sieht genauso aus wie deine, hat aber eine Login-Seite. Sie geben Ihre Daten also erneut ein, aber nichts passiert. Oder es leitet dich woanders hin.

Dies ist oft die Taktik von Bankbetrügern, die Kunden ansprechen möchten und sie auffordern, ihre Website aufzurufen, um ein Banking-Passwort erneut einzugeben.

Dies ist nur eine weitere Form einer Art von Sicherheit als ‚Social Engineering‘ bekannt.

Answer 8

Verwenden recaptcha oder asirra automatische Übermittlung zu vermeiden. Das sollte die Bots und Script Kiddies stoppen.

Um Horden von Menschen daran zu hindern, Spam zu verschicken (über mechanischen Türken oder ähnliches), protokollieren Sie jeden Versuch in memcached und blockieren Sie diese IP, sobald Sie eine maximale Anzahl von Einreichungen von derselben IP in einem bestimmten Zeitraum erreichen für ein paar Minuten (oder Stunden, Tage, was auch immer ...).