Wpis o Merge\Rebase powstanie pewnie w przyszłym tygodniu – pamiętam. Dzisiaj chciałbym rozpocząć nowy cykl o bezpieczeństwie aplikacji webowych. Niejednokrotnie o tym pisałem już, ale były to luźno powiązane ze sobą wpisy. Od tego wpisu chciałbym to zmienić i przedstawić bardziej dogłębnie tą tematykę.

Pierwsze wpisy będą stanowiły całkowite podstawy, ale mam nadzieję, że również bardziej zaawansowani programiści znajdą coś ciekawego w tym (np. wykorzystywane narzędzia).  Na końcu mam zamiar przedstawić kilka “sławnych” luk bezpieczeństwa, które miały miejsce w ASP.NET WebForms, ASP.NET MVC oraz w IIS.

Od strony technologicznej będę zajmował się głównie rozwiązaniami od MS (ASP.NET, IIS) ponieważ po prostu nie korzystałem na tyle długo z innych technologii, aby móc pisać o bezpieczeństwie w nich i najczęściej popełnianych błędach.  Oczywiście tematyka bezpieczeństwa aplikacji webowych głównie opiera się na tym samym mechanizmie i wykorzystywana technologia nie ma znaczenia. Na przykład, każda aplikacja może być podatna na SQL Injection.  Z drugiej strony jednak, czasami wykorzystuje się luki w bezpieczeństwie (np. w kodowaniu znaków) specyficzne dla danej technologii czy framework’u.

Zatem jaki jest pierwszy lub jeden z pierwszych kroków w przypadku bezpieczeństwa aplikacji? Jeśli nie znamy danej strony\aplikacji nie wiemy  jakie luki bezpieczeństwa mogą w niej występować. Z tego względu, warto rozpocząć analizę strony, która dostarczy nam informacji m.in. o wykorzystywanych technologiach, serwerze www, treści, wszelkich podstronach czy po prostu logice biznesowej, która została zaimplementowana. Luka w bezpieczeństwie może występować na każdym etapie. Jeśli dowiemy się, że wersja IIS jest nieaktualna, wtedy możemy spróbować znaleźć i wykorzystać jedną z wielu z luk bezpieczeństwa, które oficjalne są już znane i załatane w najnowszych wersjach.

Szczególnie ważne jest odkrycie wszelkich podstron czy plików. W skrajnych sytuacjach strony mogą eksponować nawet listę haseł. Wydaje się to bardzo nieprawdopodobne, ale nie jedna wielka firma czy organizacja w przeszłości przechowywała dane wrażliwe w plikach tekstowych, które były potem publicznie dostępne i wystarczyło zgadnąć po prostu URL… W praktyce strony\aplikacje są często pisane przez amatorów, outsourcowane do firm, które nie przejmują się bezpieczeństwem lub w przypadku dużych firm i napiętych terminów,  systemy webowe są na tyle skomplikowane, że prawdopodobieństwo wystąpienia błędu jest bardzo wysokie.

Innymi słowy, mapowanie dokonujemy, aby odkryć na jakie ataki może być potencjalnie podatna aplikacja. Na przykład, przeglądając zasoby możemy wywnioskować o:

1. Wykorzystywanych technologiach (o tym konkretnym mapowaniu napiszę później)
2. Plikach i podstronach. Czasami odkryte pliki bezpośrednio stanowią lukę w bezpieczeństwie np. logi aplikacji.
3. Ogólnym działaniu aplikacji. Budując mapę, analizujemy działanie strony. Dzięki temu w przyszłości skupimy się na konkretnych aspektach. Jeśli podczas analizy odkryjemy formularze do logowania, wtedy spróbujemy np. ominąć autoryzację. Jeśli zobaczymy, że pewna treść jest wstrzykiwana dynamicznie, możemy pomyśleć o atakach typu XSS czy SQL Injection.
4. Zwracanych kodach HTTP, czasach wykonywania konkretnych zapytań jak i łańcuchach interakcji. Dzięki niej, dowiemy się np. jaką serię zapytań należy wykonać, aby użytkownik został autoryzowany.
5. Odkrycie ukrytych plików, które w żaden sposób nie są podlinkowane na publicznej stronie (o tym później).
6. Identyfikacja punktów, gdzie wstrzykujemy dane do aplikacji. Klasycznym przykładem są formularze. Inne możliwości to Query String (argumenty w URL), ciasteczka, HTTP body, HTTP header czy po prostu zwykły URL. Oczywiście wszelkie punkty gdzie wstrzykujemy dane powinny zwrócić naszą uwagę, ponieważ potencjalnie są podatne na ataki (np. w przypadku braku walidacji).
7. Identyfikacja usług. Dzisiejsze aplikacje webowe to nie tylko pojedynczy serwis. Często występują połączenia z zewnętrznymi usługami, zwykle typu REST.
8. Walidacji po stronie klienta. Często strony weryfikują dane za pomocą JavaScript. Zawsze warto sprawdzić, czy ta sama weryfikacja następuje również po stronie serwera.
9. Połączeniach z bazą danych. Jeśli wiemy, że aplikacja nie jest statyczna to być może jest podatna na SQL Injection.

Oczywiście powyższa lista to tylko mały podzbiór przykładów. Jedynie co chcę pokazać, że bez mapowania nie wiemy po prostu od czego zacząć. Po analizie, możemy taką listę ułożyć np. od najbardziej prawdopodobnych ataków do tych mniej. Nie warto poświęcać wszystkiemu jednakowej uwagi.

Mapowanie aplikacji może odbywać się na kilka sposobów. Pierwszy z nich to ręczne przeglądanie strony i zgadywanie linków. Na przykład, jeśli aplikacja wykorzystuje elmah do wykonywania logów, możemy spróbować otworzyć http://localhost:xxxx/elmah.axd.  Logi zwykle dostarczają wystarczająco dużo informacji, aby przeprowadzić już konkretny atak.

Innym sposobem jest odpalenie automatycznego narzędzia, które będzie przechodziło za nas z jednej strony na drugą – tzw. web spidering.  W praktyce jednak jest to dość ograniczone ponieważ strony często korzystają z zaawansowanej walidacji danych w formularzach czy po prostu są asynchroniczne i interakcja polega na wysłaniu zapytania AJAX.

Najlepsze rezultaty daje trzeci sposób czyli połączenie ręcznego przeglądania strony ze wsparciem narzędzi. Ręcznie możemy zalogować się czy wykonać zapytania AJAX, a narzędzie w tle za nas będzie wszystko śledzić.

W Internecie można znaleźć wiele narzędzi, zarówno darmowych jak i komercyjnych. Osobiście korzystam z Burp Suite, które ma również darmową edycję.  Program może nie jest jakoś super intuicyjny, ale ma sporo użytkowników więc łatwo znaleźć odpowiedź na jakiekolwiek pytania. Screenshot:

Program działa na zasadzie proxy, zatem w ustawieniach musimy ustawić odpowiedni port:

Ruch będzie kierowany do 8080 czyli do Burp Suite. Dzięki temu, przeglądając jakąś stronę internetową,  Burp Suite będzie budował w tle mapę za nas.

Powinniśmy zatem przejść przez wszystkie strony, zarówno jako użytkownik anonimowy jak i po autentykacji (jeśli znamy hasło). Wracając do BS ponownie, zobaczymy, że wszelkie zapytania i odpowiedzi zostały zapisane:

BS w międzyczasie również odkryje za nas pewne strony. Zostaną one przedstawione kolorem szarym na powyższej liście. Jeśli posortujemy wyniki po Time Requested, wtedy strony automatycznie wykryte zostaną pogrupowane razem:

Warto poświęcić chwilę i przeanalizować je. Możliwe, że któraś ze stron wykryta przez BS nie miała być w zamiarze autorów aplikacji publiczna.

To dopiero początek mapowania aplikacji – w przyszłym wpisie więcej informacji o tym.