Warum ist die clientseitige Validierung ein Sicherheitsrisiko im Gegensatz zur serverseitigen Validierung?

Im Idealfall würden Sie sowohl die Client- als auch die Server-Seite und niemals das eine oder das andere tun. Wenn wir uns diese drei Szenarien ansehen, ist beides der einzige sichere und benutzerfreundliche Weg, dies zu tun:

Nur Client-Seite: Wie bereits erwähnt, braucht es nicht viel, um diese Validierungen zu umgehen, wenn jemand fehlerhafte Daten an Ihren Server senden möchte (z. B. SQL-Injektion). NoScript wird den JavaScript-Validierungscode nicht ausführen, und einige Browser erlauben es dem Benutzer, alle geladenen JavaScript- und HTML-Dateien aktiv zu ändern, sodass ein Benutzer das Validierungs-JavaScript von den Steuerelementen entfernen kann.

Server Side Only: Dieser Server ist zwar sicherer als Client-Only, reduziert aber die Benutzerfreundlichkeit. Sie müssen ihr Formular an den Server senden, es validieren lassen und die Fehlermeldung zurück erhalten, dass ein bestimmtes Feld ungültig ist. Was ist ärgerlich ist, dass, wenn eines dieser Felder Passwortfelder waren, ihre Werte nicht standardmäßig neu gefüllt werden. Angenommen, der Benutzer hat eine Telefonnummer in einem Kontoerstellungsformular nicht korrekt eingegeben. Wenn der Server die Seite darüber spuckt, wie die Telefonnummer falsch ist, wird der Benutzer sehen, dass die Telefonnummer korrigiert wird und erneut auf Senden geklickt wird, nur um eine weitere Fehlerseite über die fehlende Eingabe eines Passworts zu erhalten Textbox), obwohl das nicht das anfängliche Problem war.

Client- und Server-Seite: Sie erhalten die Sicherheit der serverseitigen Validierung, etwas, das dem Benutzer schwerfällt, zu stören, und die Benutzerfreundlichkeit der Eingabevalidierung, ohne die Seite einreichen zu müssen (ob Sie über rein lokal validieren) Javascript oder AJAX).

Wenn Sie unbedingt einen auswählen müssten, wäre die Server-Seite der richtige Weg. Aber du solltest dich nie entscheiden müssen.

Mit verschiedenen Werkzeugen wie Fiddler , Noscript , Web Developer usw., ich könnte das clientseitige JavaScript deaktivieren Validierung und ändern Sie die Daten, die an Ihren Server gesendet werden. Abhängig von der Art der Daten und was der Server damit macht, könnte man einen SQL-Injection-Angriff starten, versuchen, die Serversicherheit zu gefährden oder einfach gefälschte Daten zu speichern.

Ein leichtgewichtiges Beispiel: Angenommen, Sie haben eine clientseitige Validierung, um sicherzustellen, dass eine Postleitzahl aus 5 oder 5 + 4 Ziffern besteht. Wenn ich das clientseitige Skript deaktiviere, könnte ich meinen 24-stelligen Wert beibehalten. Wenn Ihr Server den Wert nicht weiter überprüft und die Datenbank alle 24 Ziffern speichern kann, habe ich die gefälschten Daten gespeichert.

Wenn Sie die Validierung nur auf der Client-Seite durchführen, kann jemand JavaScript deaktivieren (oder den js-Code ändern, zum Beispiel mit Firebug). Daher sind alle in js durchgeführten Validierungen nutzlos und Benutzer können ungültige Daten in Ihr System einfügen.

Ich nehme an, Sie sprechen von einem Webszenario?

Wenn Sie eine clientseitige Validierung mit Javascript durchführen, was passiert, wenn der Benutzer Javascript deaktiviert hat? Dann können sie Daten an den Server senden, der nicht validiert wurde.

Wenn sie hinterhältig wären, könnten sie sogar Daten direkt auf Ihren Server hochladen (indem Sie Ihre Seite komplett umgehen).

Wenn Sie zusätzlich zur Client-seitigen Validierung eine serverseitige Validierung durchführen, haben Sie zusätzlich die Möglichkeit, sich gegen diese Szenarien zu wehren.

Tatsächlich gibt es einen großen Sicherheitsvorteil bei der clientseitigen Validierung (in Kombination mit serverseitiger Validierung). Wenn Sie auf dem Client sorgfältig überprüfen, sollte der gesamte auf den Server eingehende Datenverkehr sauber sein. Außer den Angreifern. Dies ermöglicht eine viel bessere serverseitige Angriffserkennung. In dem großen Plan der Dinge ist das wahrscheinlich das Wichtigste, was Sie tun könnten, um Ihre Anwendungen zu schützen. Weitere Informationen hierzu finden Sie im OWASP ESAPI Intrusion Detector oder im OWASP AppSensor.

Oh, und natürlich, wenn der Angriff im Client startet und endet, wie DOM-basiertes XSS, dann müssen Sie auf der Client-Seite validieren und kodieren.