Czy wartości pola tekstowego HtmlEncode są niezbędne, jeśli włączona jest funkcja sprawdzania poprawności ASP.Net?

Question

Jeśli funkcja sprawdzania poprawności żądania ASP.NET jest włączona dla witryny, czy nadal potrzebujesz informacji z łańcucha znaków HtmlEncode i HtmlDecode do iz prostych formularzy (np. Do pól tekstowych ASP)?

Answer 1

Jeśli ASP.NET Zapytanie Walidacja jest włączona na miejscu, czy trzeba jeszcze HtmlEncode

ASP.NET Zapytanie Walidacja jest hack próbować obejść niedziałających programów głupi autorów. Nie pisz zepsutych programów.

Dowolny ciąg tekstowy zapisany na stronie HTML musi być zakodowany w HTML; jest to kwestia poprawności, a nie tylko bezpieczeństwa (które jest podzbiorem poprawności). Nawet jeśli Request Validation może w magiczny sposób usunąć dowolny możliwy atak XSS (a to jest , więc nic w tym przypadku nie jest), niepoprawne wyjście tekstowe HtmlEncode pozostawia otwartą możliwość generowania zniekształconych danych wyjściowych, zniekształcania danych.Powiedzieć, że robił post na forum rozmawiać o niektórych zmiennych a, b i c i chciał powiedzieć:

a<b b>c b>a 

Jeśli to zostało powtórzone w niekodowanej źródłowym HTML, chciałbym dostać:

się cb> a

a może reszta strony byłoby zbyt śmiałe. Whoops!

Żądanie Walidacja jest nieprawdziwe i nie należy na niej polegać. Domyślnie "zalecane dla wszystkich środowisk produkcyjnych" jest smutne i sprawia, że ​​mam poważne wątpliwości co do zdrowego rozsądku zespołu ASP.NET.

Jeśli napisałeś swój program poprawnie, nie potrzebujesz go, a będzie on po prostu przeszkadzał. (Na przykład, jeśli używałbym go, nie byłbym w stanie stworzyć tego postu, który wspomniałby o tagu <script>.) Jeśli nie napisałeś poprawnie swojego programu, Request Validation nie naprawi twoich luk w zabezpieczeniach, to po prostu sprawię, że będą nieco bardziej niejasne.

i HtmlDecode ciąg informacji

Zwykle nie HtmlDecode coś w aplikacji internetowej. Koduje się, aby wypychać zawartość do formatu HTML, ale kiedy treść wraca z przesłanego formularza, jest to zwykły tekst, a nie kod HTML.

do iz prostych formularzy (np. Pola tekstowe ASP)?

Pola tekstowe powinny być w porządku; ustawienie ich .Text wykonuje niezbędne kodowanie, tworząc dokładny ciąg znaków, który pojawił się w polu tekstowym. Ale. Niektóre rzeczy, które wyglądają tak, że powinny być kodowane automatycznie, w rzeczywistości nie. Na przykład:

myTextBox.Text= "a<b b>c"; // Fine! 
myLabel.Text= "a<b b>c"; // Broken! 

Och kochanie. Text nie zawsze oznacza tekst. Sometimes, it actually means HTML. Dziękuję Microsoft, sposób na zabrudzenie wód w temacie, którego zbyt wielu ludziom trudno jest zrozumieć.

Answer 2

Nie ma niebezpieczeństwa związanego z tekstem w polach tekstowych ASP.NET, niezależnie od tego, czy funkcja sprawdzania poprawności jest włączona, czy wyłączona. Formant pola tekstowego automatycznie koduje dane wyświetlane w polu tekstowym.

Podczas wysyłania danych, które pochodziły od użytkownika w innych miejscach, ważne jest, aby kodować te dane przez kod HTML (lub JavaScript). Prośba o walidację programu ASP.NET zapewnia jedynie minimalny poziom ochrony. Nie jest nieprzenikniony ani nawet bliski. Jest przeznaczony tylko do ochrony przed najprostszymi atakami.

Nadal musisz kodować rzeczy podczas ich wysyłania w innych częściach witryny.

Edit
Co mam na myśli innych miejscach, jest to, że jeśli użytkownik wprowadzi dane w polu tekstowym, stosując kontrolę ASP.NET pola tekstowego jest bezpieczny, ponieważ kontrola automatycznie koduje wyjście więc będzie renderowanie bezpiecznie.

Załóżmy na przykład, że pracujesz na stronie informacji o użytkownikach StackOverflow. Gdy użytkownik wybierze swoją nazwę użytkownika, może wprowadzić coś, co może być szkodliwe, gdy zostanie wyświetlone w innej części witryny. Na przykład moja nazwa logowania StackOverflow jest wyświetlana u góry każdej strony dla mnie i jest również wyświetlana na stronie "Użytkownicy".

Na stronie Użytkownicy AJAX służy do ładowania użytkowników. Kiedy JavaScript przechodzi do oceny nazwy użytkownika, nie jest związany tymi samymi regułami kodowania, co znaczniki HTML, więc mógłbym wpisać coś w polu tekstowym nazwy użytkownika, co mogłoby spowodować pewne zachowanie powodujące łamanie, gdy jest wyprowadzane na listę użytkowników.

StackOverflow oczywiście poprawnie koduje dane użytkownika po wysłaniu do klienta, dzięki czemu są one bezpieczne. Zanim wyślę moją nazwę użytkownika do klienta, oni (zapewne) mają pewną procedurę kodowania JavaScript, która upewnia się, że moja nazwa użytkownika nie może stać się złośliwa po wykonaniu w kodzie JavaScript.

Moglibyśmy mieć również problemy, jeśli używamy go w sterowaniu wejściowym non -ASP.NET. Znaczniki wejściowe używają atrybutów do definiowania treści, dzięki czemu można łatwo wprowadzać tekst, który przejdzie przez sprawdzanie poprawności żądania, ale może zezwolić użytkownikowi na dodanie złośliwego atrybutu "kursor myszy".