Ein potenziell gefährlicher Request.Form-Wert wurde von dem Client erkannt
https://stackoverflow.com/questions/81991
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Jedes Mal wenn ein Benutzer Beiträge etwas < oder > auf einer Seite in meiner Web-Anwendung enthält, bekomme ich diese Ausnahme ausgelöst.
Ich will nicht in die Diskussion über die Pfiffigkeit gehe von einer Ausnahme zu werfen oder eine ganze Web-Anwendung abstürzt, weil jemand ein Zeichen in einem Textfeld eingegeben, aber ich bin auf der Suche nach einem eleganten Weg zu handhaben.
Trapping die Ausnahme und zeigt
ist ein Fehler aufgetreten bitte gehen Sie zurück und wieder geben Sie Ihr gesamtes Formular erneut, aber diesmal bitte nicht <
nicht professionell genug scheint mir.
Das Deaktivieren Post Validierung (validateRequest="false") Dieser Fehler wird auf jeden Fall vermeiden, aber es wird die Seite anfällig für eine Reihe von Angriffen verlassen.
Im Idealfall: Wenn ein Postback auftritt HTML beschränkt Zeichen enthält, die einen Mehrwert in der Formularsammlung geschrieben wird automatisch HTML codiert.
So ist die .Text Eigenschaft meiner Textbox wird something & lt; html & gt;
Gibt es eine Weise, die ich dies von einem Handler tun?
Lösung
Ich glaube, Sie es aus dem falschen Winkel angreifen, indem Sie versuchen, alle eingestellten Daten zu kodieren.
Beachten Sie, dass ein „<“ von anderen externen Quellen auch kommen könnte, wie ein Datenbankfeld, eine Konfiguration, eine Datei, ein Futter und so weiter.
Darüber hinaus „<“ ist nicht von Natur aus gefährlich. Es ist nur dann gefährlich, in einem bestimmten Kontext: Wenn Strings zu schreiben, die (wegen XSS) in HTML-Ausgabe wurden nicht verschlüsseln
In anderen Kontexten unterschiedliche Unterketten sind gefährlich, zum Beispiel, wenn Sie einen Benutzer bereitgestellte URL in einen Link zu schreiben, der Sub-string „javascript:“ gefährlich sein kann. Der Apostroph Zeichen auf der anderen Seite ist gefährlich, wenn Zeichenfolgen in SQL-Abfragen interpoliert, aber vollkommen sicher, wenn es sich um ein Teil eines Namens aus einem Formular oder lesen von einem Datenbankfeld abgegeben wird.
Das Endergebnis ist: Sie zufällige Eingabe für gefährliche Zeichen nicht filtern können, weil jedes Zeichen unter den richtigen Umständen gefährlich sein kann. Sie sollten an der Stelle kodieren, wo einige spezielle Zeichen gefährlich werden können, weil sie in eine andere Unter Sprache überqueren, wo sie eine besondere Bedeutung haben. Wenn Sie eine Zeichenfolge in HTML schreiben, sollten Sie Zeichen kodieren, die eine besondere Bedeutung in HTML haben, Server.HtmlEncode verwenden. Wenn Sie eine Zeichenfolge in einer dynamischen SQL-Anweisung übergeben, sollten Sie verschiedene Zeichen kodieren (oder besser, lassen Sie den Rahmen macht es für Sie durch vorbereitete Anweisungen oder dergleichen) ..
Wenn Sie sind sicher, dass Sie HTML-kodieren überall Sie Strings in HTML übergeben, dann setzen validateRequest="false" in der <%@ Page ... %> Direktive in Ihrer .aspx Datei (en).
In .NET 4 Sie können ein wenig mehr tun müssen. Manchmal ist es notwendig, auch <httpRuntime requestValidationMode="2.0" /> zu web.config hinzufügen ( Referenz ).
Andere Tipps
Es gibt eine andere Lösung zu diesem Fehler, wenn Sie ASP.NET MVC verwenden:
- ASP.NET MVC - Seiten validateRequest = false funktioniert nicht?
- Warum ist ValidateInput (False) nicht funktioniert?
- ASP.NET MVC RC1, ValidateInput, auf eine mögliche Gefahren Anforderung und die Pitfall
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
In ASP.NET MVC (ab Version 3), können Sie die AllowHtml auf eine Eigenschaft auf Ihrem Modell zuzuschreiben.
Es ermöglicht eine Anforderung HTML-Markup während Modells enthält Bindung von Anforderungsvalidierung für die Eigenschaft zu überspringen.
[AllowHtml]
public string Description { get; set; }
Wenn Sie auf .NET 4.0 stellen Sie sicher sind Sie fügen Sie diese in Ihre web.config Datei innerhalb der <system.web> tags:
<httpRuntime requestValidationMode="2.0" />
In .NET 2.0 Anforderungsvalidierung angewandt nur Anfragen an aspx. In .NET 4.0 wurde diese alle Anfragen erweitert. Sie können zurückkehren nur XSS Validierung bei .aspx Verarbeitung durch die Angabe:
requestValidationMode="2.0"
Sie können deaktivieren Anfrage Validate vollständig durch Angabe:
validateRequest="false"
Für ASP.NET 4.0 können Sie Markup als Eingabe für bestimmte Seiten statt der gesamten Website ermöglichen, indem sie alle in einem <location> Elemente setzen. Dies wird sicherstellen, dass alle Ihre anderen Seiten sicher sind. Sie brauchen nicht ValidateRequest="false" in Ihrer ASPX-Seite zu setzen.
<configuration>
...
<location path="MyFolder/.aspx">
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" />
</system.web>
</location>
...
</configuration>
Es ist sicherer, diese in Ihrem web.config zu kontrollieren, weil man bei einer Site-Ebene sehen kann, welche Seiten Markup als Eingabe ermöglichen.
Sie müssen noch programmatisch Eingabe validieren auf Seiten, auf denen Anforderungsvalidierung deaktiviert ist.
Die bisherigen Antworten sind groß, aber niemand sagte, wie ein einzelnes Feld ausschließen aus für HTML / JavaScript-Injektionen validiert werden. Ich weiß nicht, über die früheren Versionen, aber in MVC3 Beta Sie können dies tun:
[HttpPost, ValidateInput(true, Exclude = "YourFieldName")]
public virtual ActionResult Edit(int id, FormCollection collection)
{
...
}
Dies bestätigt noch alle Felder mit Ausnahme der ausgeschlossenen ein. Das Schöne daran ist, dass die Validierung Attribute das Feld noch validieren, aber Sie bekommen einfach nicht die Ausnahmen „Ein potenziell gefährlicher Request.Form-Wert aus dem Client erkannt wurde“.
Ich habe dies für die Validierung eines regulären Ausdrucks verwendet. Ich habe meine eigene Validation gemacht, um zu sehen, ob der reguläre Ausdruck gültig ist oder nicht. Als regulärer Ausdrücke etwas, das aussieht wie ein Skript, das ich angelegt, um den obigen Code enthalten kann -. Der reguläre Ausdruck noch geprüft werden, wenn sie gültig ist oder nicht, aber nicht, wenn es enthält Skripte oder HTML
In ASP.NET MVC müssen Sie requestValidationMode = "2.0" und validateRequest = "false" in web.config, und geben Sie eine ValidateInput Attribut auf Ihre Controller-Aktion setzen:
<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 HTML kodieren Text Box Inhalt, aber leider, dass die Ausnahme nicht passiert stoppen. Nach meiner Erfahrung ist es keine Möglichkeit gibt um, und Sie müssen die Seitenvalidierung deaktivieren. Dadurch, dass Sie sagen: „Ich werde vorsichtig sein, versprochen.“
Für MVC, Eingabevalidierung ignoriert durch Hinzufügen
[ValidateInput (false)]
über jede Aktion im Controller.
Sie können diesen Fehler in Global.asax fangen. Ich möchte immer noch validieren, sondern zeigen eine entsprechende Meldung. Auf dem Blog unten aufgeführt, wie dies eine Probe zur Verfügung steht.
void Application_Error(object sender, EventArgs e)
{
Exception ex = Server.GetLastError();
if (ex is HttpRequestValidationException)
{
Response.Clear();
Response.StatusCode = 200;
Response.Write(@"[html]");
Response.End();
}
}
Umleiten auf eine andere Seite scheint auch wie eine vernünftige Antwort auf die Ausnahme.
http://www.romsteady.net/ Blog / 2007/06 / how-to-catch-httprequestvalidationexcep.html
Die Antwort auf diese Frage ist einfach:
var varname = Request.Unvalidated["parameter_name"];
Dies würde die Validierung für die jeweilige Anforderung deaktivieren.
Bitte beachten Sie, dass einige .NET-Steuerelemente automatisch HTML die Ausgabe codieren. Zum Beispiel wird die .Text Eigenschaft auf einem TextBox-Steuerelement Einstellung automatisch kodieren. Das bedeutet speziell < in <, > in > und & in & konvertieren. Also vorsichtig sein, dies zu tun ...
myTextBox.Text = Server.HtmlEncode(myStringFromDatabase); // Pseudo code
Doch die .Text Eigenschaft für HyperLink, Wörtliche und Etikett nicht HTML kodieren Dinge, so Einwickeln Server.HtmlEncode (); um etwas über diese Eigenschaften festgelegt wird, ist ein Muss, wenn man <script> window.location = "http://www.google.com"; </script> von auszugebende in der Seite und anschließend ausgeführt.
Sie ein wenig experimentieren, um zu sehen, was verschlüsselt wird und was nicht.
In der Datei web.config, innerhalb der Tags, legen Sie die Httpruntime Element mit dem Attribut requestValidationMode = "2.0". Fügen Sie auch die validateRequest = "false" -Attribut in den Seiten-Elemente.
Beispiel:
<configuration>
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
<pages validateRequest="false">
</pages>
</configuration>
Wenn Sie wollen ValidateRequest nicht deaktivieren benötigen Sie einen JavaScript-Funktion zu implementieren, um die Ausnahme zu vermeiden. Es ist nicht die beste Option, aber es funktioniert.
function AlphanumericValidation(evt)
{
var charCode = (evt.charCode) ? evt.charCode : ((evt.keyCode) ? evt.keyCode :
((evt.which) ? evt.which : 0));
// User type Enter key
if (charCode == 13)
{
// Do something, set controls focus or do anything
return false;
}
// User can not type non alphanumeric characters
if ( (charCode < 48) ||
(charCode > 122) ||
((charCode > 57) && (charCode < 65)) ||
((charCode > 90) && (charCode < 97))
)
{
// Show a message or do something
return false;
}
}
Dann im Code hinter, auf dem Pageload-Ereignisse, fügen Sie das Attribut auf Ihre Steuerung mit dem nächsten Code:
Me.TextBox1.Attributes.Add("OnKeyPress", "return AlphanumericValidation(event);")
Es scheint niemand die unten noch erwähnt, aber es behebt das Problem für mich. Und bevor jemand sagt, ja es ist Visual Basic ... igitt.
<%@ Page Language="vb" AutoEventWireup="false" CodeBehind="Example.aspx.vb" Inherits="Example.Example" **ValidateRequest="false"** %>
Ich weiß nicht, ob es irgendwelche Nachteile sind, aber für mich war erstaunlich.
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;
}
}
Wenn Sie mit Framework 4.0 dann dem Eintrag in der web.config (
<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>
Wenn Sie mit Framework 4.5 dann der 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 einzelne Seite wollen, dann, in Sie aspx Datei sollten Sie die erste Zeile wie diese setzen:
<%@ Page EnableEventValidation="false" %>
Wenn Sie bereits etwas wie haben <% @ Page so einfach den Rest hinzufügen => EnableEventValidation="false"%>
Ich empfehle es nicht zu tun.
In ASP.NET können Sie die Ausnahme abfangen und etwas dagegen zu tun, wie eine freundliche Nachricht angezeigt oder auf eine andere Seite umleiten ... Auch gibt es eine Möglichkeit, dass Sie die Validierung selbst behandeln kann ...
freundliche Nachricht anzeigen:
protected override void OnError(EventArgs e)
{
base.OnError(e);
var ex = Server.GetLastError().GetBaseException();
if (ex is System.Web.HttpRequestValidationException)
{
Response.Clear();
Response.Write("Invalid characters."); // Response.Write(HttpUtility.HtmlEncode(ex.Message));
Response.StatusCode = 200;
Response.End();
}
}
Ich denke, man es in einem Modul tun könnte; aber das lässt einige Fragen offen; was ist, wenn Sie die Eingabe in einer Datenbank speichern? Plötzlich, weil man von ihm codierte Daten in die Datenbank Eingabe am Ende ist sparend zu vertrauen, die wahrscheinlich eine schlechte Idee ist. Im Idealfall jedes Mal, Sie speichern rohe unverschlüsselte Daten in der Datenbank und die kodieren.
Das Deaktivieren des Schutzes auf einer pro Seite Ebene und dann jedes Mal codiert, wird eine bessere Option.
Anstatt Server.HtmlEncode verwenden Sie bei den neueren, vollständigere Anti-XSS-Bibliothek von dem Microsoft ACE-Team.
ich eine Lösung gefunden, die JavaScript verwendet, um die Daten zu kodieren, die in .NET decodiert wird (und nicht erfordern jQuery).
- Machen Sie das Textfeld ein HTML-Element (wie Textbereich) anstelle eines ASP ein.
- Fügen Sie ein verstecktes Feld.
-
Fügen Sie die folgende JavaScript-Funktion zu Ihrem Header.
Boo-Funktion () { targetText = document.getElementById ( "HiddenField1"); sourceText = document.getElementById ( "Userbox"); targetText.value = escape (sourceText.innerText); }
In Ihrem Textbereich, gehören Onchange die boo () aufruft:
<textarea id="userbox" onchange="boo();"></textarea>
Schließlich wird in .NET verwenden
string val = Server.UrlDecode(HiddenField1.Value);
Ich bin mir bewusst, dass dies ein Weg ist, - wenn Sie Zwei-Wege benötigen Sie kreativ werden müssen, aber dies stellt eine Lösung bereit, wenn Sie den web.config nicht bearbeiten
Hier ist ein Beispiel I (MC9000) kam mit und verwenden über jQuery:
$(document).ready(function () {
$("#txtHTML").change(function () {
var currentText = $("#txtHTML").text();
currentText = escape(currentText); // Escapes the HTML including quotations, etc
$("#hidHTML").val(currentText); // Set the hidden field
});
// Intercept the postback
$("#btnMyPostbackButton").click(function () {
$("#txtHTML").val(""); // Clear the textarea before POSTing
// If you don't clear it, it will give you
// the error due to the HTML in the textarea.
return true; // Post back
});
});
Und das Markup:
<asp:HiddenField ID="hidHTML" runat="server" />
<textarea id="txtHTML"></textarea>
<asp:Button ID="btnMyPostbackButton" runat="server" Text="Post Form" />
Dies funktioniert gut. Wenn ein Hacker über Umgehung JavaScript zu schreiben versucht, werden sie sie sehen nur den Fehler. Sie können auch in einer Datenbank verschlüsselt alle diese Daten speichern, dann ist es unescape (auf der Serverseite), und analysieren, Check für Angriffe, bevor an anderer Stelle angezeigt wird.
Ursache
ASP.NET standardmäßig alle Eingabesteuerungen für potenziell unsichere Inhalte validiert, die Cross-Site Scripting führen kann (XSS) und SQL-Injections . So verbietet es solche Inhalte durch die obige Ausnahme werfen. Standardmäßig ist es empfehlenswert, diese Überprüfung zu ermöglichen, auf jedem Postback passieren.
Lösung
Bei vielen Gelegenheiten müssen Sie HTML-Inhalte auf Ihrer Seite durch Rich-Textfelder oder Rich-Text-Editors einzureichen. In diesem Fall können Sie diese Ausnahme vermeiden, indem den ValidateRequest-Tag in der @Page Direktive auf false setzen.
<%@ Page Language="C#" AutoEventWireup="true" ValidateRequest = "false" %>
Dies wird die Validierung von Anforderungen für die Seite deaktivieren Sie die ValidateRequest Flag auf false gesetzt haben. Wenn Sie diese deaktivieren möchten, überprüfen Sie in Ihrem Web-Anwendung; Sie werden in Ihrer web.config auf false setzen müssen Abschnitt
<pages validateRequest ="false" />
Für .NET 4.0 oder höher Frameworks Sie müssen auch die folgende Zeile in dem Abschnitt
<httpRuntime requestValidationMode = "2.0" />
Das ist es. Ich hoffe, das hilft Ihnen, in dem oben genannten Problem loszuwerden.
Referenz von: ASP.Net Fehler: Ein potenziell gefährlicher Request.Form Wert vom Client erkannt wurde
Die anderen Lösungen hier sind nett, aber es ist ein bisschen eine königliche Schmerz im Rücken gelten zu haben [AllowHtml] zu jedem einzelnen Modell Eigentum, vor allem, wenn Sie mehr als 100 Modelle auf einem recht großen Gelände haben.
Wenn Sie wie ich, Sie wollen diese (IMHO ziemlich sinnlos) drehen Funktion off site breit können Sie die Execute () überschreiben Methode in Ihrer Basis-Controller (wenn Sie nicht bereits eine Basis-Controller habe ich schlage vor, Sie zu machen, sie können für die Anwendung gemeinsame Funktionalität ziemlich nützlich sein).
protected override void Execute(RequestContext requestContext)
{
// Disable requestion validation (security) across the whole site
ValidateRequest = false;
base.Execute(requestContext);
}
So stellen Sie sicher, dass Sie die HTML-Codierung alles, was auf die Ansichten abgepumpt wird, die aus Benutzereingaben kam (es ist das Standardverhalten in ASP.NET MVC 3 Razor mit wie auch immer, es sei denn, aus irgendeinem bizarren Grund Sie verwenden Html.Raw () Sie sollten diese Funktion nicht erforderlich.
Ich war immer diesen Fehler zu.
In meinem Fall ein Benutzer ein akzentuiertes Zeichen á in einem Rollennamen eingegeben (in Bezug auf dem ASP.NET-Mitgliedschaftsanbieter).
passiere ich die Rollennamen ein Verfahren Benutzer zu dieser Rolle zu gewähren und die $.ajax Post-Anforderung kläglich versagt ...
Ich tat dies, um das Problem zu lösen:
Anstelle von
data: { roleName: '@Model.RoleName', users: users }
Tun Sie dies
data: { roleName: '@Html.Raw(@Model.RoleName)', users: users }
@Html.Raw hat den Trick.
Ich war immer den Rollennamen als HTML-Wert roleName="Cadastro bás". Dieser Wert mit HTML-Entität á wurde von ASP.NET MVC blockiert. Jetzt habe ich den roleName Parameterwert so, wie es sein sollte. roleName="Cadastro Básico" und ASP.NET MVC-Motor wird die Anfrage nicht blockiert mehr
Deaktivieren Sie die Seite Validierung, wenn Sie wirklich die Sonderzeichen wie benötigen, >, < usw. dann sicher, dass, wenn die Benutzereingabe angezeigt wird, ist die Daten HTML-codiert.
Es gibt eine Sicherheitslücke, mit der Seite Validierung, so kann es umgangen werden. Auch die Seite Validierung nicht allein verlassen sollte.
Sie können auch JavaScript Funktion entkommen (string) die Sonderzeichen zu ersetzen. Dann serverseitige Verwendung Server. URLDecode (string) es zu wechseln.
Auf diese Weise müssen Sie Eingabevalidierung nicht ausschalten, und es wird auf andere Programmierer mehr klar sein, dass die Zeichenfolge HTML-Inhalt haben kann.
endete ich vor jedem Postbacks mit JavaScript up für die Charaktere überprüfen Sie nicht wollen, 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 vor allem der Dateneingabe, und es gibt nur sehr wenige Elemente, die Postbacks zu tun, aber zumindest ihre Daten beibehalten werden.
Solange diese sind nur „<“ und „>“ (und nicht die doppelten Anführungszeichen selbst) Zeichen und Sie sind mit ihnen in Zusammenhang wie
Wenn Sie gerade suchen, um Ihre Benutzer zu sagen, dass
Keiner der Vorschläge für mich gearbeitet. Ich wollte nicht, diese Funktion für die gesamte Website sowieso auszuschalten, weil 99%, wenn ich meine Nutzer keine HTML auf Web-Formulare platzieren möchten. Ich meine eigene Arbeit um Methode gerade erstellt, da ich der einzige mit dieser speziellen Anwendung bin. Ich konvertiere die Eingabe in HTML im Code hinter sich und setzen Sie sie in meiner Datenbank.
Sie können mit so etwas wie:
var nvc = Request.Unvalidated().Form;
Später nvc["yourKey"] sollte funktionieren.
