XSS czyli Cross Site Scripting to sposób na wstawienie swojego kodu na podatną stronę. Dzieje się to przez obdarzenie użytkownika zbyt dużym zaufaniem.
Czym jest XSS ??
XSS czyli Cross Site Scripting to sposób na wstawienie swojego kodu na podatną stronę. Dzieje się to przez obdarzenie użytkownika zbyt dużym zaufaniem, czego skutkiem może być kompromitacja naszej strony.
Jakby zareagowali nasi klienci gdyby dowiedzieli się, że ich dane sę w posiadaniu osób, które nie powinny mieć do nich dostępu, lub po wejściu na stronę ukazały by im się treści kompromitujące naszą firmę/stronę? Artykuł‚ ten ma pokazać podstawowe sposoby zabezpieczania skryptów przed atakami typu XSS.
Co mamy do stracenia ?
Umiejętne wykorzystanie błędów programisty może skutkować wejściem w posiadanie ważnych danych firmowych, pobraniem loginów oraz haseł‚ użytkowników czy nawet zablokowaniem strony.
Do uzyskanie danych firmowych może doprowadzić brak filtrowania danych przekazywanych przez użytkownika podczas zapisu ich do bazy danych. Do kradzieży danych użytkownika może doprowadzić wstrzyknięcie kodu JavaScript, zaś do modyfikacji strony kodu HTML/PHP.
W tym artykule pominiemy zaawansowane kwestię SQL Injection, a zajmiemy się wstrzykiwaniem kodu JavaScript i HTML. Spowodowane jest to głównie faktem, że artykuł‚ ma nauczyć podstawowych metod zabezpieczania się, a nie sposobów ataku.
Czas na zabezpieczanie, czyli psucie czas zacząć
Jako, że uczyć się jest najlepiej na przykadach, dlatego w celu lepszego zobrazowania istoty błędów będę je opisywać‚ na podstawie istniejących stron.
Przykładem ufności do użytkowników może być strona Narodowego Funduszu Zdrowia (http://www.nfz.gov.pl/). Najbardziej podatnym elementem stron są wszelkie formularze, na stronie NFZ rzuca nam się od razu w oczy wyszukiwarka. Wyszukiwarka ta nie filtruje danych, które otrzymuje od użytkownika co skutkuje możliwością wstrzyknięcia kodu HTML oraz JavaScript.
Jak działa wyszukiwanie podatności na XSS ?
W polu input wyszukiwarki widoczne jest na bieżąco nasze zapytanie, dzięki czemu możemy bardzo prosto ingerować w wygląd strony. Aby tego dokonać wystarczy zamknąć ostatni tag HTML poprzedzający nasze zapytanie, czyli w tym przypadku jest to
dzięki temu input zostanie zamknięty, a treść nagłówka
zostanie umieszczona poza formularzem. Efekt tego pokazuje poniższy obrazek:
Jak się przed tym uchronić ?? Ochrona jest równie banalna jak i atak. Wystarczy użyć jednej funkcji PHP, a dokładnie
. Zadaniem funkcji
jest filtracja podanego jako parametr ciągu i usunięcie z niego tagów HTML oraz PHP. Gdyby programista piszący powyższą wyszukiwarkę użył‚ tej funkcji efektem wpisania groźnego kodu byłaby następująca informacja:
Niestety, nie znaleziono wyników pasujących do zapytania Test XSS.
Kradzież danych użytkownika ? Nic prostszego.
Wcześniejszy przykład ukazywał idee wstrzyknięcia kodu HTML, co jednak gdy agresor użyje JavaScript, który ma zdecydowanie większe możliwości? Powróćmy do wyszukiwarka NFZ, gdy dokonamy modyfikacji poprzedniego kodu, który modyfikował‚ wygląd strony tak aby zawierał‚ on w sobie kod JavaScript otworzą się przed nami ogromne możliwości. Aby sprawdzić, czy próba wstrzyknięcia kodu JavaScript powiedzie się wystarczy w wyszukiwarkę wpisać
i tutaj zaczynajś się schody. Parser PHP serwera NFZ ma włączoną dyrektywę magic_quotes_gpc, która jest złym zwyczajem. Dlaczego przecież zapewnia ona podstawowe bezpieczeęstwo skryptów? Tak jest, lecz gdy programista przyzwyczai się do zrzucania bezpieczeństwa swoich skryptów na parser PHP to stracą one na swojej przenośności, wzrośnie obciąenie serwera oraz nie uchroni go to przed wszystkimi niebezpieczeństwami. W tym przypadku uniemożliwia nam to pokazanie napisu ponieważ parser PHP przerabia nasz kod na
co uniemożliwia jego wykonanie. Nie blokuje to jednak wszystkich naszych możliwości. Możemy np. zmusić stronę do pokazania nam komunikatu z aktualną godziną:
Skoro już wiemy, że wstrzyknięcie kodu JavaScript jest możliwe pomyślmy jak atakujący może ukraść dane użytkownika. Wiele stron w plikach cookies umieszcza dane o użytkownikach takie jak loginy czy hasła. Za pomocą XSS agresor bez problemu może osiągnąć dostęp do tych danych. JavaScript posiada funkcję odczytująćą dane z plików cookies, poprzez napisanie odpowiedniego skryptu PHP, dane te mogą być przekazywane do skryptu na serwerze agresora. Z badań„ przeprowadzonych na stronie NFZ wynika, że ich strona również zapisuje ciastko na naszym komputerze, co prawda nie zawiera ono danych o loginach czy hasłach lecz :
Załóżmy, że dane te to poziom uprawnień użytkownika, jeśli agresor zmieniłby wartość na 0 to mógłby uzyskać dodatkowe prawa na serwerze. Dlatego właśne dane należy trzymać na serwerze, korzystając z sesji, a nie ciastek.
Mogłoby się wydawać, że skoro JavaScript ma większe możliwości to zabezpieczania też będą poważniejsze. Tak jednak nie jest, wystarczy, że prócz funkcji [code php=”lang”]strip_tags[/code] przydadzą się nam dwie dodatkowe funkcje
oraz
ich zadaniem jest dodawanie ukośnika przed znakami, które mogą być niebezpieczne czyli
.
Bezpieczne dołączanie plików.
Wiele osób nie widzi nic niebezpiecznego w bezpośrednim dołączaniu plików ze zmiennych superglobalnych. Co może być w tym niebezpiecznego. Wyobraźmy sobie sytuację, gdy nazwa pliku przesyłana jest w zmiennej z tablicy GET. Odpowiednie zmodyfikowanie adresu strony przez agresora może doprowadzić do uzyskania dostępu do pliku passwd oraz shadow, które zawierają dane o użytkownikach w systemie oraz innych plików np konfiguracyjnych. Jak się przed tym zabezpieczyć Wg mnie dobrym sposobem jest utworzenie tablicy ze zmiennymi, których odpowiedniki plikowe mogą być includowane i sprawdzać za pomocą funkcji
czy dany plik ma zezwolenie na dołczenie.
Bezpieczne dodawanie danych do bazy danych.
Tematyka SQL Injection jest bardziej rozległa niż poprzednich wstrzyknięć, dlatego przedstawię tutaj tylko podstawowe metody zabezpieczeń.
Pierwszą zasadą jest niewstawianie zmiennych przekazywanych przez użytkownika do zapytania. Należy wcześniej je przefiltrować. I tu ponownie PHP ułatwia nam zadanie udostępniając szereg funkcji. Należą do nich
. Wszystkie prócz ostatniej zostały już omówione więc skupimy się tylko na
. Umożliwia ona zamianę specjalnych znaczników HTML na odpowiednie im encje, dzięki czemu możemy bez poważnych konsekwencji przyjmować od użytkownika kod HTML.
Nie tylko formularze są podatne.
Najbardziej podatnymi na XSS elementami stron są formularze oraz dane przekazywane do skryptów za pośrednictwem adresu, czyli zmienne z tablicy GET. Brak filtracji tablicy GET może doprowadzić do tych samych konsekwencji co brak filtracji w formularzach.
Przykładem strony, a raczej stron podatnych na “adresowy XSS” są strony, na których zainstalowany jest system zarządzania treścią Mambo. CMS ten komunikuje się z użytkownikiem za pośrednictwem zmiennej
znajdującej się w tablicy superglobalnej GET. Poprzez odpowiednie zmodyfikowanie adresu strony możemy wstawić na stronę dowolny tekst. Jest to jedyne uchybienie Mambo, ponieważ dane przekazywane przez tą zmienną są czyszczone do postaci czystego tekstu, a więc wstrzyknięcie kodu HTML/PHP jest niemożliwe. Przykładem takiej modyfikacji adresu może być
czego efektem jest :
Samozagłada, czyli register_globals.
Register_globals jest dyrektywą parsera PHP, umożliwiającą automatyczne tworzenie, krótkich nazw zmiennych, dzięki temu zamiast pisać
możemy napisać
. Początkowo może się wydawać, że dyrektywa ta jest bardzo pomocna, ponieważ pozwala zaoszczedzić czas związany z wpisywaniem nazwy tablicy, jednak stanowi ogromne niebezpieczeęstwo dla naszej strony. Dlaczego ? Załóżmy, że nasz strona zawiera moduł‚ logowania. Poziom użytkownika sprawdzany jest poprzez instrukcję warunkową
. Agresor poprzez modyfikację adresu strony
uzyska dostęp do praw administratora, bez konieczności logowania się. Tak więc mimo swojej przydatności zalecane jest wyłączenie dyrektywy register_globals.
Zakończenie, czyli to jeszcze nie jest koniec.
W tym artykule starałem przekazać Wam podstawową wiedzę z zakresu obrony przed XSS. Uważam, że wiedza na ten temat jest bardzo potrzebna webmasterom, ponieważ ogromna ilość stron jest podatna na ten atak. Mimo, że PHP udostępnia nam wiele przydatnych funkcji pomagających w zabezpieczeniu przed wstrzykiwaniem złośliwego kodu, należy pomyśleć też o tworzeniu własnych funkcji, które zapewnią większe bezpieczeństwo pisanych przez nas skryptów. I pamiętajcie o najważniejszej zasadzie, podczas pisania kodu, należy postępować tak jakby każdy użytkownik był‚ agresorem i próbował‚ znaleźć każdy nasz błąd.
PS. Administrator strony NFZ został‚ poinformowany o błędzie na stronie.
Autor: Michał‚ `Bełdzio` Ławicki
WWW: http://www.beldzio.com/
Kontakt : beldzio@beldzio.com
Kopiowanie bez zgody autora zabronione.
Źródło: Bełdzio
Licencja: Creative Commons - bez utworów zależnych