Jaka jest różnica między kodami AntiXss.HtmlEncode i HttpUtility.HtmlEncode?

Question

Po prostu natknąłem się na pytanie z odpowiedzią sugerującą bibliotekę AntiXss, aby uniknąć skryptów cross site. Brzmi interesująco, czytając msdn blog, wydaje się po prostu dostarczyć metodę HtmlEncode(). Ale już używam HttpUtility.HtmlEncode().

Dlaczego chciałbym używać AntiXss.HtmlEncode przez HttpUtility.HtmlEncode?

Rzeczywiście, nie jestem pierwszym, który zadaje to pytanie. I rzeczywiście, Google zamienia się someanswers, głównie

• Biały-lista zamiast czarnej listy podejście
• wzrost wydajności 0,1 ms

Cóż, to miłe, ale to, co robi dla mnie znaczy? Nie przejmuję się tak bardzo wydajnością 0.1ms i naprawdę nie mam ochoty pobierać i dodawać innej zależności biblioteki dla funkcjonalności, którą już posiadam.

Czy są przykłady przypadków, w których implementacja AntiXss uniemożliwiłaby atak, którego nie miałaby implementacja HttpUtility?

Jeśli nadal będę korzystać z wdrożenia HttpUtility, czy jestem narażony na ryzyko? A co z this 'bug'?

Answer 1

Nie mam konkretnej odpowiedzi na twoje pytanie, ale chciałbym podkreślić, że podejście oparte na białej liście i czarnej liście nie jest tylko "miłe". To ważne. Bardzo ważne. Jeśli chodzi o bezpieczeństwo, każda drobnostka jest ważna. Pamiętaj, że w przypadku skryptów cross-site i cross-site request forgery, nawet jeśli twoja strona nie wyświetla poufnych danych, haker może zainfekować twoją stronę przez wstrzyknięcie javascript i użycie go do uzyskania poufnych danych z innej strony. Więc robienie tego dobrze jest krytyczne.

OWASP guidelines specify using a white list approach. Wytyczne PCI Compliance określają to również w standardach kodowania (ponieważ odnoszą się do wytycznych OWASP).

Również nowsza wersja biblioteki AntiXss ma nową ładną funkcję: .GetSafeHtmlFragment(), która jest dobra w przypadkach, w których chcesz przechowywać HTML w bazie danych i wyświetlać go użytkownikowi jako HTML.

Ponadto, jeśli chodzi o "błąd", jeśli kodujesz prawidłowo i postępujesz zgodnie ze wszystkimi wytycznymi bezpieczeństwa, używasz sparametryzowanych procedur przechowywanych, więc pojedyncze cytaty będą traktowane poprawnie, Jeśli nie kodujesz prawidłowo , żadna biblioteka na półce nie będzie cię w pełni chronić. Biblioteka AntiXss ma być narzędziem do wykorzystania, a nie substytutem wiedzy. Opierając się na bibliotece, robiąc to dla ciebie, spodziewałbyś się naprawdę dobrego pędzla, który mógłby wypróbować dobre obrazy bez dobrego artysty.

Edycja - Dodano

Jak zapytałem w pytaniu przykład gdzie anty XSS będzie cię chronić i HttpUtility nie będzie:

HttpUtility.HtmlEncode and Server. HtmlEncode do not prevent Cross Site Scripting

To jest według autora, choć . Nie testowałem tego osobiście.

---

To brzmi jakbyś się na swoich wytycznych bezpieczeństwa, więc nie może to być coś, co muszę ci powiedzieć, ale tylko w przypadku mniej doświadczonych deweloper tam czytanie tego, powód powiedzieć, że podejście oparte na białej liście ma kluczowe znaczenie.

Teraz, dzisiaj HttpUtility.HtmlEncode może skutecznie zablokować każdy atak tam, po prostu usuwając/kodowanie < i >, plus kilka innych „znanych potencjalnie niebezpiecznych” znaków, ale ktoś zawsze stara się wymyślić nowe sposoby włamania. Zezwalanie na zawartość tylko znanej bezpiecznej (białej listy) jest o wiele łatwiejsze niż próba pomyślenia o każdym potencjalnie niebezpiecznym fragmencie danych wejściowych, które atakujący może rzucić na ciebie (metoda z czarną listą).

Answer 2

Używamy białej listy w witrynach Microsoft Windows Live. Jestem pewna, że ​​istnieje jakakolwiek liczba ataków bezpieczeństwa, o których jeszcze nie myśleliśmy, więc jestem bardziej zadowolony z podejścia paranoidalnego. Podejrzewam, że zdarzały się przypadki, w których na czarnej liście ujawniały się słabe punkty, których nie ma biała lista, ale nie mogłem podać szczegółów.

Answer 3

Jeśli chodzi o to, dlaczego użyjesz jednego z nich, pomyśl, że biblioteka AntiXSS jest wydana częściej niż środowisko ASP.NET - ponieważ, jak mówi David Stratton, "ktoś zawsze próbuje wymyślić nowe sposoby włamanie, gdy ktoś wymyśli bibliotekę AntiXSS, jest o wiele bardziej prawdopodobne, że dostanie zaktualizowaną wersję, aby się przed nią obronić.

Answer 4

Większość luk w zabezpieczeniach XSS (w rzeczywistości każdy rodzaj luki) jest oparty wyłącznie na fakcie, że istniejące zabezpieczenia nie "oczekują" pewnych rzeczy. Podejścia oparte tylko na białej liście są bardziej odpowiednie do obsługi tych scenariuszy domyślnie.

Answer 5

Poniżej przedstawiono różnice między Microsoft.Security.Application.AntiXss.HtmlEncode i System.Web.HttpUtility.HtmlEncode metod:

1. Anti-XSS wykorzystuje technikę białego z wykazu, czasami określane jako zasada inkluzji, aby zapewnić ochronę przed Cross-Site Scripting (XSS) ataki. To podejście działa najpierw definiując prawidłowy lub dopuszczalny zestaw znaków i kodując wszystko poza tym zestawem (nieprawidłowe znaki lub potencjalne ataki). System.Web.HttpUtility.HtmlEncode i inne metody kodowania w tej przestrzeni nazw stosują zasadę wykluczeń i kodują tylko niektóre znaki oznaczone jako potencjalnie niebezpieczne, takie jak <,>, & i "znaki.

2. Lista białych (lub bezpiecznych) znaków biblioteki Anti-XSS obsługuje więcej niż tuzin języków (grecki i koptyjski, cyrylica, cyrylica, ormiański, hebrajski, arabski, syryjski, arabski, thaana, NKo i więcej)

3. Biblioteka Anti-XSS została zaprojektowana specjalnie do łagodzenia ataków XSS, natomiast metody kodowania HttpUtility są tworzone w celu zapewnienia, że ​​wyjście ASP.NET nie łamie HTML.

4. Wydajność - średnia delta między AntiXss.HtmlEncode() i HttpUtility.HtmlEncode() wynosi +0,1 milisekund na transakcję.

5. Anti-XSS wersja 3.0 zapewnia uprząż testową, która pozwala programistom na przeprowadzanie zarówno walidacji XSS, jak i testów wydajności.