Ein potenziell gefährlicher Request.Form-Wert wurde vom Client erkannt

Question

Jedes Mal, wenn ein Nutzer einen Beitrag mit < ou > in einer Seite in meiner Webanwendung, bekomme ich diese Ausnahme ausgelöst.

Ich möchte nicht in die Diskussion über die Klugheit des Auslösens einer Ausnahme oder des Absturzes einer gesamten Webanwendung gehen, weil jemand ein Zeichen in ein Textfeld eingegeben hat, aber ich suche nach einer eleganten Möglichkeit, dies zu behandeln.

Abfangen der Ausnahme und Anzeigen

Es ist ein Fehler aufgetreten. Bitte gehen Sie zurück und geben Sie das gesamte Formular noch einmal ein, aber verwenden Sie dieses Mal bitte nicht <

scheint mir nicht professionell genug zu sein.

Deaktivieren der Nachvalidierung ( validateRequest="false" ) wird dieser Fehler definitiv vermieden, aber die Seite ist dadurch anfällig für eine Reihe von Angriffen.

Idealerweise: Wenn eine Rückmeldung erfolgt, die in HTML eingeschränkte Zeichen enthält, wird der gepostete Wert in der Formularsammlung automatisch HTML-kodiert. So wird der .Text Eigenschaft meines Textfeldes wird sein something & lt; html & gt;

Gibt es eine Möglichkeit, wie ich dies von einem Handler aus tun kann?

Answer 1

Ich denke, Sie gehen das Problem von der falschen Seite an, indem Sie versuchen, alle veröffentlichten Daten zu verschlüsseln.

Beachten Sie, dass ein " < "Die Informationen können auch aus anderen Quellen stammen, z. B. aus einem Datenbankfeld, einer Konfiguration, einer Datei, einem Feed usw.

Außerdem: " < " ist nicht per se gefährlich. Es ist nur in einem bestimmten Kontext gefährlich: beim Schreiben von Zeichenketten, die nicht für die HTML-Ausgabe kodiert wurden (wegen XSS).

In anderen Kontexten sind verschiedene Teilstrings gefährlich, z. B. wenn Sie eine vom Benutzer bereitgestellte URL in einen Link schreiben, ist der Teilstring " javascript: " kann gefährlich sein. Das einfache Anführungszeichen hingegen ist gefährlich, wenn es um die Interpolation von Zeichenketten in SQL-Abfragen geht, aber völlig ungefährlich, wenn es Teil eines Namens ist, der in einem Formular eingegeben oder aus einem Datenbankfeld gelesen wird.

Die Quintessenz ist: Sie können die zufällige Eingabe nicht nach gefährlichen Zeichen filtern, denn jedes Zeichen kann unter den richtigen Umständen gefährlich sein. Sie sollten an dem Punkt kodieren, an dem bestimmte Zeichen gefährlich werden können, weil sie in eine andere Untersprache übergehen, wo sie eine besondere Bedeutung haben. Wenn Sie eine Zeichenfolge in HTML schreiben, sollten Sie Zeichen, die in HTML eine besondere Bedeutung haben, mit Server.HtmlEncode kodieren. Wenn Sie eine Zeichenkette an eine dynamische SQL-Anweisung übergeben, sollten Sie verschiedene Zeichen kodieren (oder besser, das Framework dies für Sie tun lassen, indem Sie vorbereitete Anweisungen oder ähnliches verwenden).

Wenn Sie sicher sind, dass Sie überall, wo Sie Zeichenketten an HTML übergeben, HTML-kodieren, dann setzen Sie ValidateRequest="false" において <%@ Page ... %> Richtlinie in Ihrem .aspx Datei(en).

In .NET 4 müssen Sie möglicherweise ein wenig mehr tun. Manchmal ist es notwendig, auch <httpRuntime requestValidationMode="2.0" /> zu web.config ( Referenz ).

Answer 2

Es gibt eine andere Lösung für diesen Fehler, wenn Sie ASP.NET MVC verwenden:

• ASP.NET MVC - Seiten validateRequest=false funktioniert nicht?
• Warum funktioniert ValidateInput(False) nicht?
• ASP.NET MVC RC1, VALIDATEINPUT, EINE POTENTIELL GEFÄHRLICHE ANFRAGE UND DER FALLSTRICK

C#-Beispiel:

[HttpPost, ValidateInput(false)]
public ActionResult Edit(FormCollection collection)
{
    // ...
}

Visual Basic-Beispiel:

<AcceptVerbs(HttpVerbs.Post), ValidateInput(False)> _
Function Edit(ByVal collection As FormCollection) As ActionResult
    ...
End Function

Answer 3

In ASP.NET MVC (beginnend mit Version 3) können Sie die AllowHtml Attribut auf eine Eigenschaft Ihres Modells.

Sie ermöglicht es einer Anfrage, HTML-Markup während der Modellbindung einzuschließen, indem die Anfragevalidierung für die Eigenschaft übersprungen wird.

[AllowHtml]
public string Description { get; set; }

Answer 4

Wenn Sie mit .NET 4.0 arbeiten, fügen Sie dies in Ihrem web.config Datei innerhalb der <system.web> Tags:

<httpRuntime requestValidationMode="2.0" />

---

In .NET 2.0 galt die Anforderungsvalidierung nur für aspx Anfragen. In .NET 4.0 wurde dies um folgende Punkte erweitert 何れも Anfragen. Sie können zurückkehren zu sólo Durchführung einer XSS-Validierung bei der Verarbeitung .aspx durch Angabe:

requestValidationMode="2.0"

Sie können die Validierung von Anfragen deaktivieren vollständig durch Angabe:

validateRequest="false"

Answer 5

Bei ASP.NET 4.0 können Sie Markup als Eingabe für bestimmte Seiten statt für die gesamte Website zulassen, indem Sie alles in eine <location> Element. Dadurch wird sichergestellt, dass alle Ihre anderen Seiten sicher sind. Sie müssen NICHT das Element ValidateRequest="false" in Ihrer .aspx-Seite.

<configuration>
...
  <location path="MyFolder/.aspx">
    <system.web>
      <pages validateRequest="false" />
      <httpRuntime requestValidationMode="2.0" />
    </system.web>
  </location>
...
</configuration>

Es ist sicherer, dies in Ihrer web.config zu steuern, da Sie auf Site-Ebene sehen können, welche Seiten Markup als Eingabe zulassen.

Sie müssen die Eingaben auf Seiten, auf denen die Anforderungsüberprüfung deaktiviert ist, immer noch programmatisch validieren.