Login lub e-mail Hasło   

Ochrona przed XSS - podstawy

Odnośnik do oryginalnej publikacji: http://www.beldzio.com/blog/ochrona-prze(...)odstawy
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.
Wyświetlenia: 10.612 Zamieszczono 30/05/2006

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

">
<h1>Test XSS</h1>

dzięki temu input zostanie zamknięty, a treść nagłówka

zostanie umieszczona poza formularzem. Efekt tego pokazuje poniższy obrazek:

Podatność na XSSJak 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ć

"><script>JavaScript:alert("Test XSS");</script>

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

"><script>JavaScript:alert(\"Test XSS\");</script>

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ą:

Podatność na XSS
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 :
Podatność na XSS
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

‘ ` \ i NUL

.

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

mosmsg

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ć

http://www.mamboserver.com/?mosmsg= Witamy+jesteśmy+kolejną+stroną+podatną+na+XSS+.

czego efektem jest :

Podatność na XSS

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ć

$_POST[‘nasza_zmienna’]

możemy napisać

$nasza_zmienna

. 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ą

if ($poziom === ‘admin’) echo ‘Jesteś adminem’;

. Agresor poprzez modyfikację adresu strony

http://www.nasz.serwer.pl/logowanie.php?poziom=admin

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.

Podobne artykuły


16
komentarze: 5 | wyświetlenia: 8988
9
komentarze: 0 | wyświetlenia: 2766
15
komentarze: 5 | wyświetlenia: 32713
13
komentarze: 2 | wyświetlenia: 22941
10
komentarze: 2 | wyświetlenia: 8128
8
komentarze: 5 | wyświetlenia: 18543
8
komentarze: 2 | wyświetlenia: 27407
7
komentarze: 3 | wyświetlenia: 18520
49
komentarze: 18 | wyświetlenia: 64914
11
komentarze: 7 | wyświetlenia: 14266
6
komentarze: 0 | wyświetlenia: 6688
37
komentarze: 9 | wyświetlenia: 28467
 
Autor
Dodał do zasobów: Mariusz Żurawek
Artykuł

Powiązane tematy






Brak wiadomości


Dodaj swoją opinię
W trosce o jakość komentarzy wymagamy od użytkowników, aby zalogowali się przed dodaniem komentarza. Jeżeli nie posiadasz jeszcze swojego konta, zarejestruj się. To tylko chwila, a uzyskasz dostęp do dodatkowych możliwości!
 

© 2005-2018 grupa EIOBA. Wrocław, Polska