Sanitize HTML vor dem Speichern in der DB oder vor dem Rendern? (AntiXSS-Bibliothek in ASP.NET)

7

Ich habe einen Editor, mit dem Benutzer HTML hinzufügen können, das in der Datenbank gespeichert und auf einer Webseite gerendert wird. Da dies eine nicht vertrauenswürdige Eingabe ist, möchte ich Microsoft.Security.Application.AntiXsSS.GetSafeHtmlFragment verwenden, um das HTML zu bereinigen.

  • Muss ich vor dem Speichern in der Datenbank oder vor dem Rendern der nicht vertrauenswürdigen Eingabe in die Webseite die Anti-Rutsch-Funktion aktivieren?
  • Gibt es einen Vorteil, wenn ich den AntiXSS-Quellcode in mein Projekt statt nur die DLL einfüge? (Vielleicht kann ich die weiße Liste anpassen?)
  • In welcher Klassendatei sollte ich nach der tatsächlichen Implementierung von GetSafeHtmlFragment
  • suchen?
Nick 13.01.2010, 22:53
quelle

4 Antworten

29

Ich stimme der gewählten Antwort aus zwei Gründen nicht zu

  1. Wenn Sie codierte Daten gespeichert haben, müssen Sie vor dem Speichern einen Encoder auswählen. Was passiert, wenn Sie etwas als HTML gespeichert haben, es aber auch in einem anderen Format ausgeben möchten, zum Beispiel als JSON-Antwort oder als Teil eines XML-Dokuments? Sie haben jetzt ein HTML-kodiertes Format, das Sie dekodieren müssen, und kodieren Sie dann im richtigen Format.
  2. Was passiert, wenn wir einen Fehler in den Encodern entdecken und eine neue Version veröffentlichen? Jetzt, da Sie nicht zum Zeitpunkt der Ausgabe codieren, können alle Ihre alten Daten Dinge enthalten, die falsch codiert wurden. Sie können erneut codieren, aber dann stoßen Sie auf doppelte Codierungsprobleme, die sich bei der korrekten Filterung als schmerzhaft erweisen können.

Im Allgemeinen codieren Sie am Ausgabepunkt und behandeln alle Daten, die aus einem Datenspeicher kommen, standardmäßig als nicht vertrauenswürdig. Was passiert, wenn jemand Ihre Datenbank direkt oder per SQL-Injection bearbeitet?

    
blowdart 24.02.2010, 14:23
quelle
9

Hören Sie sich den OWASP-Podcast 67 mit Jeff Williams auf XSS an . Er redet darüber, dass er vor der Speicherung keine Desinfektion oder Kodierung vorgenommen hat. Der Hauptgrund dafür ist, dass Ihre Daten in der alten Version hängen bleiben, wenn sich Bibliotheken als Reaktion auf neue Schwachstellen weiterentwickeln. Das hindert Sie natürlich nicht daran, irgendeine Eingabe gegen eine Whitelist am Einstiegspunkt auszuführen und alles außerhalb des akzeptablen Bereichs abzulehnen.

    
Troy Hunt 25.05.2010 21:16
quelle
3
  • Beide
  • Nur wenn du vorhast, es zu ändern, was ich nicht persönlich machen würde
  • Die AntiXss-Klasse (da sie als AntiXss.GetSafeHtmlFragment() bezeichnet wird)
David 13.01.2010 22:55
quelle
-1

Sie können in der Seitenanweisung den Parameter ValidateRequest="true" verwenden. Auf diese Weise werden alle Request-Daten validiert und wenn es ein Validierungsproblem gibt, können Sie den Fehler immer abfangen. Es verhindert auch SQL-Injection-Threads und andere nicht nur mögliche XSS.

Mit numerischen Daten können Sie den Integer-Überlauf oder den Missbrauch von Datentypen mit Int32.TryParse () oder einer beliebigen anderen TryParse-Familie (Byte.TryParse Int16.TryParse ...) validieren.

Sie müssen keine andere Klasse oder zusätzliche Desinfektionsmethode verwenden.

    
backslash17 13.01.2010 23:06
quelle