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




asp.net-mvc validation (20)

Beachten Sie, dass einige .NET-Steuerelemente die Ausgabe automatisch mit HTML codieren. Wenn Sie beispielsweise die Eigenschaft .Text für ein TextBox-Steuerelement festlegen, wird es automatisch codiert. Das bedeutet konkret, < in &lt; , > in &gt; und & in &amp; . Sei also vorsichtig damit ...

myTextBox.Text = Server.HtmlEncode(myStringFromDatabase); // Pseudo code

Die Eigenschaft .Text für HyperLink, Literal und Label wird jedoch keine HTML-codierten Objekte enthalten, daher muss das Umbrechen von Server.HtmlEncode (); Alles, was in diesen Eigenschaften festgelegt wird, ist ein Muss, wenn Sie verhindern möchten, dass <script> window.location = "http://www.google.com"; </script> <script> window.location = "http://www.google.com"; </script> wird auf Ihrer Seite ausgegeben und anschließend ausgeführt.

Machen Sie ein wenig experimentieren, um zu sehen, was codiert wird und was nicht.

Jedes Mal, wenn ein Benutzer etwas mit < oder > auf einer Seite in meiner Webanwendung veröffentlicht, wird diese Ausnahme ausgelöst.

Ich möchte nicht in die Diskussion über die Klugheit des Auslösens einer Ausnahme oder des Absturzes einer ganzen Webanwendung einsteigen, weil jemand einen Charakter in eine Textbox eingegeben hat, aber ich suche nach einer eleganten Art, damit umzugehen.

Überfüllen der Ausnahme und Anzeigen

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

scheint mir nicht professionell genug zu sein.

Die Deaktivierung der Postvalidierung ( validateRequest="false" ) wird diesen Fehler definitiv vermeiden, aber die Seite wird für eine Reihe von Angriffen anfällig bleiben.

Idealerweise: Wenn ein Post-Back auftritt, der HTML-beschränkte Zeichen enthält, wird dieser Wert in der Form-Sammlung automatisch HTML-codiert. Also wird die Eigenschaft .Text meiner Textbox something & lt; html & gt; something & lt; html & gt;

Gibt es einen Weg, wie ich das von einem Hundeführer machen kann?


Bei MVC ignorieren Sie die Eingabeüberprüfung, indem Sie hinzufügen

[ValidateInput (false)]

über jeder Aktion im Controller.


Die Antwort auf diese Frage ist einfach:

var varname = Request.Unvalidated["parameter_name"];

Dies würde die Validierung für die bestimmte Anforderung deaktivieren.


Die anderen Lösungen hier sind nett, aber es ist ein bisschen ein königlicher Schmerz in der Rückseite, [AllowHtml] auf jede einzelne Model-Eigenschaft anwenden zu müssen, besonders wenn Sie über 100 Modelle auf einer anständigen Site haben.

Wenn Sie wie ich diese (IMHO ziemlich sinnlose) Funktion außerhalb der Site aktivieren möchten, können Sie die Execute () Methode in Ihrem Basis-Controller überschreiben (wenn Sie nicht bereits einen Basis-Controller haben, schlage ich vor, dass Sie einen machen ziemlich nützlich für die Anwendung der allgemeinen Funktionalität).

    protected override void Execute(RequestContext requestContext)
    {
        // Disable requestion validation (security) across the whole site
        ValidateRequest = false;
        base.Execute(requestContext);
    }

Stellen Sie nur sicher, dass Sie HTML-Code für alles kodieren, was zu den Ansichten gepumpt wird, die von Benutzereingaben stammen (das ist das Standardverhalten in ASP.NET MVC 3 mit Razor sowieso, es sei denn aus irgendeinem seltsamen Grund verwenden Sie Html.Raw ()) sollte diese Funktion nicht benötigen.


Eine andere Lösung ist:

protected void Application_Start()
{
    ...
    RequestValidator.Current = new MyRequestValidator();
}

public class MyRequestValidator: RequestValidator
{
    protected override bool IsValidRequestString(HttpContext context, string value, RequestValidationSource requestValidationSource, string collectionKey, out int validationFailureIndex)
    {
        bool result = base.IsValidRequestString(context, value, requestValidationSource, collectionKey, out validationFailureIndex);

        if (!result)
        {
            // Write your validation here
            if (requestValidationSource == RequestValidationSource.Form ||
                requestValidationSource == RequestValidationSource.QueryString)

                return true; // Suppress error message
        }
        return result;
    }
}

Es scheint, dass noch niemand das Folgende erwähnt hat, aber es behebt das Problem für mich. Und bevor jemand sagt, es ist Visual Basic ... yuck.

<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Example.aspx.vb" Inherits="Example.Example" **ValidateRequest="false"** %>

Ich weiß nicht, ob es irgendwelche Nachteile gibt, aber für mich hat das super funktioniert.


Für ASP.NET 4.0 können Sie Markup als Eingabe für bestimmte Seiten anstelle der gesamten Site zulassen, indem Sie alles in ein <location> -Element einfügen. Dadurch wird sichergestellt, dass alle anderen Seiten sicher sind. Sie müssen ValidateRequest="false" in Ihre ASPX-Seite einfügen.

<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 kontrollieren, da Sie auf Seitenebene sehen können, welche Seiten Markup als Eingabe zulassen.

Sie müssen die Eingabe auf Seiten, auf denen die Anforderungsüberprüfung deaktiviert ist, weiterhin programmgesteuert überprüfen.


Ich denke, Sie greifen es aus dem falschen Winkel an, indem Sie versuchen, alle veröffentlichten Daten zu kodieren.

Beachten Sie, dass ein " < " auch von anderen externen Quellen stammen kann, z. B. von einem Datenbankfeld, einer Konfiguration, einer Datei, einem Feed und so weiter.

Außerdem ist " < " nicht von Natur aus gefährlich. Es ist nur in einem bestimmten Kontext gefährlich: beim Schreiben von Strings, die nicht in HTML-Ausgabe (wegen XSS) codiert wurden.

In anderen Kontexten sind verschiedene Sub-Strings gefährlich. Wenn Sie beispielsweise eine vom Benutzer bereitgestellte URL in einen Link schreiben, kann die Sub-Zeichenfolge " javascript: " gefährlich sein. Das einfache Anführungszeichen hingegen ist gefährlich beim Interpolieren von Strings in SQL-Abfragen, aber vollkommen sicher, wenn es Teil eines Namens ist, der von einem Formular gesendet oder aus einem Datenbankfeld gelesen wurde.

Die Quintessenz ist: Du kannst keine zufälligen Eingaben für gefährliche Charaktere filtern, da jeder Charakter unter den richtigen Umständen gefährlich sein kann. Sie sollten an dem Punkt kodieren, an dem bestimmte Zeichen gefährlich werden können, weil sie in eine andere Untersprache übergehen, in der sie eine besondere Bedeutung haben. Wenn Sie eine Zeichenfolge in HTML schreiben, sollten Sie Zeichen, die eine besondere Bedeutung in HTML haben, mit Server.HtmlEncode codieren. Wenn Sie eine Zeichenfolge an eine dynamische SQL-Anweisung übergeben, sollten Sie verschiedene Zeichen codieren (oder besser, lassen Sie das Framework dies für Sie tun, indem Sie vorbereitete Anweisungen oder ähnliches verwenden).

Wenn Sie sicher sind, dass Sie HTML überall dort codieren, wo Sie Strings an HTML übergeben, legen Sie validateRequest="false" in der <%@ Page ... %> .aspx in Ihren .aspx Dateien fest.

In .NET 4 müssen Sie möglicherweise ein wenig mehr tun. Manchmal muss auch <httpRuntime requestValidationMode="2.0" /> zu web.config ( reference ) hinzugefügt werden.


Ich habe dann vor jedem Postback JavaScript verwendet, um nach den Zeichen zu suchen, die du nicht haben willst, wie zum Beispiel:

<asp:Button runat="server" ID="saveButton" Text="Save" CssClass="saveButton" OnClientClick="return checkFields()" />

function checkFields() {
    var tbs = new Array();
    tbs = document.getElementsByTagName("input");
    var isValid = true;
    for (i=0; i<tbs.length; i++) {
        if (tbs(i).type == 'text') {
            if (tbs(i).value.indexOf('<') != -1 || tbs(i).value.indexOf('>') != -1) {
                alert('<> symbols not allowed.');
                isValid = false;
            }
        }
    }
    return isValid;
}

Zugegeben, meine Seite ist hauptsächlich Dateneingabe, und es gibt sehr wenige Elemente, die Postbacks ausführen, aber zumindest ihre Daten bleiben erhalten.


Ich habe diesen Fehler auch bekommen.

In meinem Fall hat ein Benutzer ein Zeichen mit Akzent in einem Rollennamen (in Bezug auf den ASP.NET-Mitgliedschaftsanbieter) eingegeben.

Ich übergebe den $.ajax an eine Methode, um Benutzern diese Rolle zu gewähren, und die $.ajax scheitert kläglich ...

Ich habe das getan, um das Problem zu lösen:

Anstatt von

data: { roleName: '@Model.RoleName', users: users }

Mach das

data: { roleName: '@Html.Raw(@Model.RoleName)', users: users }

@Html.Raw hat den Trick gemacht.

Ich erhielt den roleName="Cadastro b&#225;s" als HTML-Wert roleName="Cadastro b&#225;s" . Dieser Wert mit der HTML-Entität &#225; wurde von ASP.NET MVC blockiert. Jetzt bekomme ich den Parameter roleName wie er sein sollte: roleName="Cadastro Básico" und ASP.NET MVC Engine wird die Anfrage nicht mehr blockieren.


In ASP.NET MVC (ab Version 3) können Sie das Attribut AllowHtml einer Eigenschaft in Ihrem Modell hinzufügen.

Es ermöglicht einer Anforderung, HTML-Markup während der Modellbindung einzufügen, indem die Anforderungsüberprüfung für die Eigenschaft übersprungen wird.

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

In ASP.NET MVC müssen Sie requestValidationMode = "2.0" und validateRequest = "false" in web.config festlegen und ein ValidateInput-Attribut auf Ihre Controller-Aktion anwenden:

<httpRuntime requestValidationMode="2.0"/>

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

und

[Post, ValidateInput(false)]
public ActionResult Edit(string message) {
    ...
}

Sie können auch die JavaScript-Funktion escape(string) verwenden, um die Sonderzeichen zu ersetzen. Dann Server-Seite Server verwenden. URLDecode(string) , um es zurückzuschalten.

Auf diese Weise müssen Sie die Eingabeüberprüfung nicht abschalten, und anderen Programmierern wird klar, dass die Zeichenfolge HTML-Inhalt haben kann.


Sie können den Textrahmeninhalt in HTML codieren , aber das wird die Ausnahme leider nicht stoppen. Nach meiner Erfahrung gibt es keinen Weg, und Sie müssen die Seitenvalidierung deaktivieren. Damit sagst du: "Ich werde vorsichtig sein, das verspreche ich."


Sie können etwas wie verwenden:

var nvc = Request.Unvalidated().Form;

Later, nvc["yourKey"] should work.


Solange diese Zeichen nur "<" und ">" (und nicht das doppelte Anführungszeichen selbst) sind und Sie sie im Kontext wie <input value = " this " /> verwenden, sind Sie sicher (während für <textarea > diese </ textarea> du wärst natürlich verletzlich). That may simplify your situation, but for anything more use one of other posted solutions.


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

C # -Probe:

[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

Wenn Sie Framework 4.0 verwenden, dann den Eintrag in der web.config (<pages validateRequest = "false" />)

<configuration>
    <system.web>
        <pages validateRequest="false" />
    </system.web>
</configuration>

Wenn Sie Framework 4.5 verwenden, dann den Eintrag in der web.config (requestValidationMode = "2.0")

<system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" requestValidationMode="2.0"/>
</system.web>

Wenn Sie nur für eine einzelne Seite wollen, dann sollten Sie in Ihrer aspx-Datei die erste Zeile wie folgt einfügen:

<%@ Page EnableEventValidation="false" %>

Wenn Sie bereits etwas wie <% @ Page haben, fügen Sie einfach den Rest hinzu => EnableEventValidation="false" %>

Ich empfehle, es nicht zu tun.


Ursache

ASP.NET überprüft standardmäßig alle Eingabesteuerelemente auf potenziell unsichere Inhalte, die zu Cross-Site-Scripting (XSS) und SQL-Injektionen führen können . Daher erlaubt es keinen solchen Inhalt, indem die obige Ausnahme ausgelöst wird. Standardmäßig wird empfohlen, diese Überprüfung bei jedem Postback zuzulassen.

Lösung

In vielen Fällen müssen Sie HTML-Inhalt über Rich TextBoxes oder Rich Text Editors an Ihre Seite senden. In diesem Fall können Sie diese Ausnahme vermeiden, indem Sie das ValidateRequest-Tag in der @Page Direktive auf false setzen.

<%@ Page Language="C#" AutoEventWireup="true" ValidateRequest = "false" %>

Dadurch wird die Überprüfung der Anforderungen für die Seite deaktiviert, für die Sie das ValidateRequest-Flag auf false festgelegt haben. Wenn Sie dies deaktivieren möchten, überprüfen Sie Ihre gesamte Webanwendung. Sie müssen es in Ihrem web.config <system.web> -Abschnitt auf false setzen

<pages validateRequest ="false" />

Für .NET 4.0 oder höhere Frameworks müssen Sie außerdem die folgende Zeile im Abschnitt <system.web> hinzufügen, um die obigen Schritte auszuführen.

<httpRuntime requestValidationMode = "2.0" />

Das ist es. Ich hoffe, dass dies Ihnen hilft, das oben genannte Problem loszuwerden.

Referenz von: ASP.Net-Fehler: Ein potenziell gefährlicher Request.Form-Wert wurde vom Client erkannt


If you're just looking to tell your users that < and > are not to be used BUT, you don't want the entire form processed/posted back (and lose all the input) before-hand could you not simply put in a validator around the field to screen for those (and maybe other potentially dangerous) characters?







request.form