ValidateRequest = „false” nie działa w Asp.Net 4

156

Mam formularz, w którym używam ckeditor. Ten formularz działał dobrze w Asp.Net 2.0 i 3.5, ale teraz nie działa w Asp.Net 4+. Mam dyrektywę ValidateRequest = "false". Jakieś sugestie?

asp.net asp.net-4.0 validate-request

— HasanG
źródło

Jest krótki artykuł na temat prawidłowego renderowania kontrolek walidacji, jeśli kogoś to obchodzi: Sprawdzanie poprawności błędów w .NET 4

— Ian

czy ktoś może mi dać znać, jakie są wady używania ValidationRequest = false?

— fc123

194

Znaleziono rozwiązanie na stronie błędu. Wystarczy dodać requestValidationMode = "2.0"

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

Informacje MSDN: właściwość HttpRuntimeSection.RequestValidationMode

— HasanG
źródło

1

to super, ale czy ktoś wie, jak ustawić to na stronie? Jak umieścić to w pliku web.config, aby nadal działało z .NET 2?

— MK.

1

@MK: Myślę, że nie ma dyrektywy strony dla tego ustawienia. Nie możesz uruchomić go na .net 2. Nie sądzę, żeby to było konieczne. Ponieważ możesz po prostu zbudować aplikację internetową przeznaczoną tylko dla jednej wersji platformy. Po prostu skopiuj tę linię do .net 4 web.config, która tego potrzebuje ...

— HasanG

2

Ale co się zmieniło podczas sprawdzania poprawności dla .net 4? Czy można to zrobić bez zmiany trybu walidacji?

— Sly

4

@Sly: Odpowiedzi można znaleźć tutaj: asp.net/learn/whitepapers/aspnet4/ ...

— HasanG

czy ktoś może dać mi znać, dlaczego w aplikacji asp.net 4.0 używanie requestValidationMode = "2.0" jest dobrym pomysłem?

— fc123

102

Istnieje sposób, aby przywrócić walidację z powrotem do wersji 2.0 dla jednej strony. Po prostu dodaj poniższy kod do swojego web.config:

<configuration>
    <location path="XX/YY">
        <system.web>
            <httpRuntime requestValidationMode="2.0" />
        </system.web>
    </location>

    ...
    the rest of your configuration
    ...

</configuration>

— Ben Hoffman
źródło

Lokalizacja to dowolna ścieżka i jest oparta na dowolnym węźle poniżej folderu określonego w drzewie.

— DFTR

7

Jest to lepsze rozwiązanie niż zaakceptowana odpowiedź, ponieważ nie jest to szeroka aplikacja, a raczej wąska do konkretnego zakresu zdefiniowanego w ścieżce lokalizacji

— Charles Wesley,

5

Powyższa deklaracja <location ..> powinna zostać umieszczona wewnątrz deklaracji <configuration>, ale nie powinna być dalej zagnieżdżana.

— rbassett

1

Wydaje się, że ustawienie na stronę nie działa w przypadku projektów przeznaczonych dla platformy .NET 4.6.1.

— Dennis T - Przywróć Monikę -

56

Wiem, że to stare pytanie, ale jeśli napotkasz ten problem w MVC 3, możesz ozdobić ActionMethodgo [ValidateInput(false)]i po prostu wyłączyć weryfikację żądań dla pojedynczego ActionMethod, co jest przydatne. Nie musisz też wprowadzać żadnych zmian w web.configpliku, więc nadal możesz korzystać z weryfikacji żądań .NET 4 wszędzie indziej.

na przykład

[ValidateInput(false)]
public ActionMethod Edit(int id, string value)
{
    // Do your own checking of value since it could contain XSS stuff!
    return View();
}

— Tom Chantler
źródło

1

@ RossCooper to jest tylko dla asp.net MVC

— mxmissile

28

Działa to bez zmiany trybu weryfikacji.

Musisz użyć System.Web.Helpers.Validation.Unvalidatedpomocnika z System.Web.WebPages.dll. To będzie powrót do UnvalidatedRequestValuesobiektu, który umożliwia dostęp do formularza i QueryString bez walidacji.

Na przykład,

var queryValue = Server.UrlDecode(Request.Unvalidated("MyQueryKey"));

Działa dla mnie na MVC3 i .NET 4.

— Morderca
źródło

1

Czy możesz podać przykład, jak pobrać queryString za pomocą tej metody? Wciąż otrzymuję komunikat „Unvalidated is not a member of…” wszystkich obiektów, do których próbuję je dołączyć. Myślę, że może mi brakować dołączenia

— CodedMonkey

3

var queryValue = Server.UrlDecode (Request.Unvalidated ("MyQueryKey"));

— sfuqua

1

To zdecydowanie powinna być akceptowana odpowiedź. Zachowuje bezpieczeństwo i jest niezwykle elastyczny, ponieważ można go używać selektywnie.

— cmartin

W przypadku formularzy sieci Web należy zastąpić wpis w kolekcji QueryString, aby uniknąć błędu walidacji - zobacz potencjalnie niebezpieczną wartość Request.QueryString wykryto od klienta podczas wysyłania znaczników html z wywołania jquery post do strony asp.net

— Michael Freidgeim

15

Zauważ, że innym podejściem jest zachowanie zachowania walidacji 4.0, ale zdefiniowanie własnej klasy, która pochodzi z RequestValidatori ustawia:

<httpRuntime requestValidationType="YourNamespace.YourValidator" />

(gdzie YourNamespace.YourValidatorjest dobrze, powinieneś zgadywać ...)

W ten sposób zachowujesz zalety zachowania 4.0 (w szczególności walidacja odbywa się na wcześniejszym etapie przetwarzania), a jednocześnie zezwalasz na przepuszczanie żądań.

— Jon Hanna
źródło

7

Dobrze wiedzieć. Ale nadal uważam, że cała funkcja sprawdzania poprawności żądań w ASP.Net jest błędna. Samo wejście nie jest problemem, to to, co z nim robisz . Akceptowanie kodu SQL, HTML lub JavaScript jako danych wejściowych do aplikacji może być całkowicie poprawne, o ile kodujesz / escapujesz go poprawnie przed wyprowadzeniem lub zapisaniem w bazie danych.

— Jordan Rieger

2

@JordanRieger Częściowo się zgadzam. OOTB, ma przynajmniej tę zaletę, że domyślnie jest zabezpieczony (nie myśl o tym, a otrzymujesz błędy, a nie 0wned), ale jest to trochę uciążliwe, a zachowanie przed 4.0 jest bardzo dobre. Jest coś w możliwości posiadania warstwy walidacji, która jest używana przed jakimkolwiek innym przetwarzaniem, tak jak w przypadku niestandardowego requestValidationType, ale wiele walidacji musi być bardziej powiązanych z innym przetwarzaniem. Wydaje mi się, że w sumie to bardziej chroni ludzi o złych nawykach przed niektórymi (ale nie wszystkimi) rozłamami, niż zachęca do dobrych nawyków.

— Jon Hanna