Czy kodowanie HTML zapobiegnie wszelkim rodzajom ataków XSS?
Nie przejmuję się innymi rodzajami ataków. Chcę tylko wiedzieć, czy kodowanie HTML może zapobiec wszelkiego rodzaju atakom XSS.
Czy Jest jakiś sposób na atak XSS, nawet jeśli kod HTML jest używany?
9 answers
Nie.
Pomijając temat zezwalania na niektóre Tagi (nie o to chodzi), HtmlEncode po prostu nie obejmuje wszystkich ataków XSS.
Na przykład, rozważmy javascript generowany przez serwer po stronie klienta - serwer dynamicznie wysyła wartości htmlencoded bezpośrednio do javascript po stronie klienta, htmlencode będzie nie zatrzymywać wstrzykiwany skrypt z wykonaniem.
Następnie rozważ następujący pseudokod:
<input value=<%= HtmlEncode(somevar) %> id=textbox>
Teraz, jeśli nie natychmiast oczywiste, jeśli somevar (wysłane przez użytkownika, oczywiście) jest ustawione na przykład na
a onclick=alert(document.cookie)
Wynikiem jest
<input value=a onclick=alert(document.cookie) id=textbox>
Istnieje kilka dodatkowych wektorów do rozważenia... w tym trzeci smak XSS, zwany DOM-based XSS (w którym złośliwy skrypt jest generowany dynamicznie na kliencie, np. na podstawie # values).
Również nie zapomnij o Ataki typu UTF-7-gdzie atak wygląda
+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-
Rozwiązaniem, oczywiście (oprócz poprawnej i restrykcyjnej walidacji danych wejściowych na białej liście), jest wykonanie context-sensitive kodowanie: HtmlEncoding jest świetny, jeśli kontekstem wyjściowym jest HTML, a może potrzebujesz JavaScriptEncoding, lub Vbscriptencoding, lub AttributeValueEncoding, lub... itd.
Jeśli używasz MS ASP.NET, można skorzystać z ich biblioteki Anti-XSS, która dostarcza wszystkie niezbędne metody kodowania kontekstowego.
Zauważ, że całe kodowanie nie powinno być ograniczone do danych wejściowych użytkownika, ale także zapisanych wartości z bazy danych, plików tekstowych itp.
Oh, i nie zapomnij jawnie ustawić charset, zarówno w nagłówku HTTP, jak i meta tagu, w przeciwnym razie nadal będziesz mieć luki w UTF-7...
Trochę więcej informacji i dość definitywna lista (stale aktualizowana), sprawdź ściągawki RSnake: http://ha.ckers.org/xss.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-16 07:57:39
Jeśli systematycznie kodujesz wszystkie dane wejściowe użytkownika przed wyświetlaniem to tak, jesteś bezpieczny nadal nie jesteś w 100% bezpieczny.
(Zobacz post @ Avid po więcej szczegółów)
Ponadto pojawiają się problemy, gdy trzeba pozwolić niektóre znaczniki nie są zakodowane, aby umożliwić użytkownikom publikowanie obrazów lub pogrubionego tekstu lub dowolnej funkcji, która wymaga wejścia użytkownika, być przetwarzane jako (lub przekonwertowane na) nie zakodowane znaczniki.
Będziesz musiał skonfigurować system podejmowania decyzji, aby zdecydować, które tagi są dozwolone i które nie są, i zawsze jest możliwe, że ktoś znajdzie sposób, aby przepuścić niedozwolony tag.
To pomaga, jeśli zastosujesz się do rad Joela aby zły kod wyglądał źle lub jeśli twój język pomaga Ci ostrzegając/nie kompilując podczas wysyłania nieprzetworzonych danych użytkownika (typowanie statyczne).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-19 09:44:34
Jeśli zakodujesz wszystko to będzie. (w zależności od platformy i implementacji htmlencode), ale każda użyteczna aplikacja internetowa jest tak złożona, że łatwo zapomnieć o sprawdzeniu każdej jej części. A może komponent 3rd party nie jest bezpieczny. A może jakaś ścieżka kodu, którą jednak kodowałeś, nie zrobiła tego, więc zapomniałeś o niej gdzieś indziej.
Więc możesz też sprawdzić rzeczy po stronie wejściowej. I może chcesz sprawdzić rzeczy, które przeczytałeś w bazie danych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-10 10:16:14
Jak wspomniano przez wszystkich innych, jesteś bezpieczny tak długo, jak zakodujesz wszystkie Dane wejściowe użytkownika przed ich wyświetlaniem. Obejmuje to wszystkie parametry żądania i dane pobrane z bazy danych, które mogą być zmienione przez wejście użytkownika.
Jako wspomniany przez Pat czasami będziesz chciał wyświetlić niektóre tagi, ale nie wszystkie tagi. Jednym z powszechnych sposobów na to jest użycie języka znaczników, takiego jak Textile, Markdown , lub BBCode . Jednak nawet języki znaczników mogą być wrażliwy na XSS, po prostu bądź świadomy.
# Markup example
[foo](javascript:alert\('bar'\);)
Jeśli zdecydujesz się przepuścić "bezpieczne" znaczniki, zalecam znalezienie jakiejś istniejącej biblioteki, aby przeanalizować i zdezynfekować kod przed wyjściem. Istnieje wiele wektorów XSS, które musisz wykryć, zanim twój środek dezynfekujący będzie dość bezpieczny.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:10:18
Popieram radę metavidy, aby znaleźć bibliotekę innej firmy do obsługi filtrowania wyjściowego. Neutralizacja znaków HTML jest dobrym podejściem do powstrzymywania ataków XSS. Jednak kod, którego używasz do przekształcania metacharakterów, może być podatny na ataki typu evasion; na przykład, jeśli nie obsługuje prawidłowo Unicode i internacjonalizacji.
Klasyczny prosty błąd homebrew filtry wyjściowe zrobić jest złapać tylko , ale brakuje rzeczy takich jak", które mogą złamać kontrolowane przez użytkownika wyjście na przestrzeń atrybutów znacznika HTML, gdzie Javascript może być dołączony do DOM.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-11 19:40:38
Nie, samo kodowanie zwykłych tokenów HTML nie chroni Twojej witryny przed atakami XSS. Zobacz na przykład tę lukę XSS znajdującą się w google.com:
Http://www.securiteam.com/securitynews/6Z00L0AEUE.html
Ważną rzeczą w tego typu lukach jest to, że atakujący jest w stanie zakodować swój ładunek XSS za pomocą UTF-7, a jeśli nie podałeś innego kodowania znaków na swojej stronie, przeglądarka użytkownika może zinterpretować ładunek UTF-7 i wykonać skrypt ataku.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-18 16:19:14
Jeszcze jedna rzecz, którą musisz sprawdzić, to skąd pochodzi twój wkład. Możesz użyć ciągu odsyłającego (przez większość czasu), aby sprawdzić, czy pochodzi on z twojej własnej strony, ale umieszczenie ukrytej liczby losowej lub czegoś w formularzu, a następnie sprawdzenie go (może ze zmienną ustawioną na sesję) pomaga również wiedzieć, że dane wejściowe pochodzą z twojej własnej witryny, a nie z jakiejś witryny phishingowej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-19 10:15:27
Chciałbym zaproponować HTML Purifier ( http://htmlpurifier.org/) nie tylko filtruje html, ale w zasadzie tokenizuje go i ponownie kompiluje. Jest to naprawdę siła przemysłowa.
Ma dodatkową zaletę pozwalającą zapewnić poprawne wyjście html / xhtml.
Również N ' thing textile, to świetne narzędzie i używam go cały czas, ale też uruchomiłbym go za pomocą HTML purifier.
Chyba nie zrozumiałeś, co miałem na myśli. HTML Purifier nie tylko 'filter', faktycznie rekonstruuje html. http://htmlpurifier.org/comparison.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-08-26 15:06:14
Nie sądzę. Kodowanie Html konwertuje wszystkie znaki funkcyjne (znaki, które mogą być interpretowane przez przeglądarkę jako kod) na odniesienia encji, które nie mogą być przetwarzane przez przeglądarkę, a tym samym nie mogą być wykonane.
<script/>
Nie ma możliwości, aby powyższe dane mogły zostać wykonane przez przeglądarkę.
**chyba że jest to błąd w przeglądarce oczywiście.*
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-10 10:14:47