it-swarm.com.de

Input-Desinfektion vs. Output-Desinfektion

In den Bits, die ich darüber gesucht habe, habe ich einige Leute gesehen, die als Wort Gottes erklärt haben, dass Sie nur Ausgaben und keine Eingaben bereinigen sollten. Warum? Wäre es nicht sicherer, beide Enden abzudecken?

21
Todd Schwine

Wenn Sie Eingaben bereinigen, besteht die Gefahr, dass Sie die Daten so ändern, dass sie möglicherweise unbrauchbar werden. Daher wird die Bereinigung von Eingaben in Fällen vermieden, in denen die Art der Daten unbekannt ist. Zum Beispiel haben einige Sonderzeichen möglicherweise eine Bedeutung in den Daten, und wenn sie entfernt werden, wird diese Bedeutung zerstört.

Ein solches Szenario kann sein, dass Ihr System Daten speichert, die später in ein System eines Drittanbieters gezogen werden, und in diesem System haben diese Zeichen eine Bedeutung. Indem Sie sie entfernen, haben Sie die Daten erheblich verändert. Beispielsweise wird die Zeichenfolge möglicherweise als Schlüssel zum Nachschlagen eines Datensatzes im System eines Drittanbieters verwendet. Durch Entfernen des Symbols ändern Sie den Schlüssel so, dass der Datensatz nicht gefunden werden kann.

Die Eingabesanierung kann verwendet werden, wenn diese Art der Daten bekannt ist und die Bereinigung die Daten ohnehin nicht beeinträchtigt.

Ihre Entscheidung, Eingabedaten zu bereinigen, ist teilweise eine Geschäftsentscheidung. Wird das System eines Drittanbieters von der Eingabe genau so abhängen, wie sie bereitgestellt wird? Wenn ja, ist es wahrscheinlich keine gute Idee. Möglicherweise können Sie die Erwartungen jedoch so gestalten, dass die Dritten verstehen, dass Sie Eingabedaten anhand eines bestimmten Kriteriums bereinigen, das Sie mit ihnen teilen.

29
saghaulor

Gee ... "Ausgabe bereinigen." Ich habe diesen Begriff noch nie gehört. Ich habe das getan, oh, ich weiß es nicht. Zumindest über ein Jahrzehnt. Sie "bereinigen Ihre Ausgabe nicht" Sie codieren sie für den richtigen Kontext innerhalb der Anwendung, die sie präsentiert. Sie codieren die Ausgabe für HTML, HTML-Attribut, URL, JavaScript ... Ich habe noch nie jemanden gesehen oder gehört, der behauptet, dass Sie Ihre Ausgabe "bereinigen" ... meinen Sie Leute im Sinne von Whitelisting oder Blacklisting Welche bestimmten Zeichenketten können beispielsweise über die Leitung an den Browser gesendet werden? Niemand macht das. Sie sollten es aus den oben genannten Gründen sowieso nicht tun - Sie wissen nicht, was die legitime Verwendung bestimmter Daten für eine bestimmte Anwendung sein kann ... einige Websites (wie zum Beispiel diese) müssen) Ermöglicht das Hochladen von Code und das Rendern als Code im Anforderungs-Antwort-Lebenszyklus. Wie könnten Beispiele für Code auf Code-Sharing-Sites ausgetauscht werden, wenn beispielsweise die Verwendung eines Skript-Tags nicht zugelassen wird?

Übrigens "Sie können niemals im Nachhinein durch die Datenbank gehen und sehen, wie viele der Beiträge böswillig waren." ist einfach nicht wahr. Es stehen Scrubber zur Verfügung, mit denen Sie eine Datenbank durchsuchen und schädlichen Code "scrubben" können. Ich weiß, ich habe es letztes Jahr für ein großes Finanzdienstleistungsunternehmen gemacht.

12
RatboySTL

Es besteht das Risiko, dass XSS-Inhalte in Ihrer Datenbank enthalten sind. Datenbanken sollen von Anwendungen gemeinsam genutzt werden und sind im Vergleich zu Web-Frontends langlebig.

Beispiel: Der neue Praktikant beginnt mit der Arbeit an einer neuen Web-App für die Datenbank, zeigt seinem Chef und bam, sein Login-Cookie befindet sich in St. Petersburg.

Sie möchten nicht ändern Benutzereingaben, Sie möchten validieren Benutzereingaben und ablehnen es, wenn es mögliche XSS enthält. Dies ist mit einem richtigen HTML-Parser wie JSoup ziemlich einfach und schnell. Es ist in Hibernate Validator integriert.

Ich sage nicht, dass Sie Benutzereingaben bei der Ausgabe nicht entgehen sollten. Bei der Anzahl der XSS-Probleme ist es jedoch offensichtlich leicht, einige zu übersehen.

4
Neil McGuigan

Ich würde empfehlen, die Eingabe zu validieren und die Ausgabe zu bereinigen. Auf diese Weise können Sie sicherstellen, dass gültige Daten in der Datenbank gespeichert werden und harmlose Daten vom Benutzer verbraucht werden.

Wenn ein Feld ein Datum erwartet, stellen Sie sicher, dass Sie ein Datum erhalten. Sie können Daten, Nummern, E-Mails, Postleitzahlen, Telefonnummern und viele Felder einfach überprüfen. Also mach es.

Tun Sie es auf Javascript, auf der Clientseite und erneut auf der Serverseite. Wenn Sie auf der Clientseite validieren, können Sie eine Fehlermeldung viel schneller generieren, als bis zum Server zu warten, validiert und zurückgesendet zu werden. Wiederholen Sie dies auf dem Server, denn wenn jemand die clientseitige Validierung deaktiviert, sind Sie weiterhin abgesichert.

Bereinigen Sie vor dem Speichern der Daten - Sie möchten nicht von einer SQL-Injektion getroffen werden. Verwenden Sie nach Möglichkeit vorbereitete Anweisungen und entkommen Sie allen Steuerzeichen, wenn dies nicht möglich ist.

Codieren Sie die Daten auf der Ausgabeseite so, dass sie im Backend-Format harmlos sind. Wenn Sie HTML ausgeben, maskieren Sie alle speziellen HTML-Zeichen. Wenn Sie json oder XML ausgeben, führen Sie die Codierung entsprechend durch.

Wie bereits erwähnt, werden durch Filtern und Codieren der Daten nach der Eingabegröße die Daten zerstört und Teile von Daten gelöscht, die in bestimmten Kontexten harmlos wären, oder gefährliche Daten gespeichert. Die Validierung der Eingabe und die Codierung der Ausgabe wäre der beste Ansatz.

3
ThoriumBR