Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Jak w 7 krokach zwiększyć bezpieczeństwo swojej webaplikacji?

Jak w 7 krokach zwiększyć bezpieczeństwo swojej webaplikacji?

Z tekstu dowiesz się

  • w3bJakie są wybrane częste i łatwe do zlokalizowania problemy z bezpieczeństwem aplikacji webowych i jak im zapobiec.
  • Jakie narzędzia możesz użyć do przetestowania bezpieczeństwa Twojej aplikacji.
  • Gdzie dalej możesz poszerzyć Twoją wiedzę.


Wstęp

W artykule przedstawię kilka prostych kroków, które można wykonać aby zwiększyć bezpieczeństwo swojej aplikacji webowej. Są to techniki podstawowe i nie obejmują lokalizacji / usuwania bardziej technicznych podatności jak SQL injection / XSS / OS Command Execution, Path TraversalAuthorization Bypass, itd. Osoby zainteresowane tego typu problemami odsyłam choćby do: OWASP Top Ten, OWASP Testing Guide, czy tutaj. Całość ma też charakter subiektywny i raczej wprowadzający w wybrane elementy bezpieczeństwa aplikacji www, niż je kompleksowo omawiający - o tym zresztą napisano już całe książki. Przed przejściem do konkretów jeszcze pewna uwaga - z oczywistych względów nie należy stosować niżej wskazanych technik do ataku na systemy, dla których nie posiadamy pozwolenia na testy.

1.    Wyświetlanie błędów aplikacyjnych

Często nie jesteśmy świadomi ile informacji nasza aplikacja udostępnia potencjalnym atakującym. Mogą to być szczegółowe informacje o wersjach użytych bibliotek czy komponentów, fragmenty kodu źródłowego, ścieżki instalacji aplikacji, fragmenty zapytań SQL, hasła bazodanowe, itd.

Google hacking

Jedną z technik, którą można zastosować aby wyłuskać interesujące informacje o aplikacji z komunikatów o błędach jest tzw. google hacking - czyli najprościej rzecz ujmując poszukiwanie w google zaindeksowanych stron zawierających komunikaty z błędami. Przykład tego typu zapytań do google?

site:www.securitum.pl error
site:www.securitum.pl warning
site:www.securitum.pl exception
site:www.securitum.pl invalid
site:www.securitum.pl sql query
site:www.securitum.pl unknown

Zauważmy, że odwołując się do wyszukiwarki, atakujący nie musi w ogóle uzyskiwać dostępu do naszej aplikacji - więc nawet nie wiemy o potencjalnie rozpoczynającym się ataku... Przykład:

gh1

Co więcej, wystarczy że nasza aplikacja działała tylko chwilę w trybie ze szczegółowym wyświetlaniem błędów i akurat w tym przedziale czasowym strony z komunikatami błędów zaindeksował robot. Ciekawą bazą zawierającą odpowiednio spreparowana zapytania do google jest tzw. GHDB (google hacking database):

ghdb

za: http://www.hackersforcharity.org/ghdb/

Odwołania do nieistniejących zasobów

Kolejnym częstym problemem - tym razem ujawniającym wersję użytych w systemie komponentów jest odwołanie się do nieistniejącej strony (np. http://test.securitum.pl/qweqwe) - tego typu problem występuje choćby na serwerach http apache czy serwerze aplikacyjnym Tomcat, a nie są to przypadki odosobnione. Przykład:

not found

Komunikacja HTTP

Popularnym, kolejnym miejscem gdzie można zlokalizować informacje o wykorzystanych komponentach są nagłówki HTTP odpowiedzi. W jaki sposób sprawdzić co aplikacja przesyła w nagłówkach odpowiedzi? Można użyć jednego z narzędzi typu http proxy (np. darmowy burp suite) lub jednego z pliuginów do Firefox-a, np.: Live HTTP headers lub Firebug:

http req-resp

Siłowe wywoływanie błędów

Kolejnym często wykorzystywanym sposobem na "sztuczne" wywołanie błędu jest zmiana typu użytego parametru, np.: user_detail.aspx?id=1234 na user_detail.aspx?id=asdqwe Odmianą tego problemu, charakterystyczną dla języka PHP, jest próba rzutowania zmiennej na tablicę, np.: user_detail.php?id=1234 -> user_detail.php?id[]=1234

php tablica błąd

Jak się ochronić?

  • Wykonać kilka zapytać do google dla swojej strony wyszukujących komunikaty o błędach - np. (site: .securitum.pl error). Jeśli zauważymy coś podejrzanego - usunąć daną informacje z cache google.


Zrekonfigurować odpowiednio system, jeśli przynajmniej jeden z elementów poniżej będzie udostępniał informacje ujawniające techniczne szczegóły naszego systemu:

  • Spróbować odwołać się do nieistniejącej strony np.: /qwnebkjqwejh - i zweryfikować czy aplikacja lub web serwer "przedstawia się" swoją wersją.
  • Przeanalizować nagłówki http odpowiedzi w poszukiwaniu informacji o wykorzystanych przez system wersjach komponentów.
  • W przypadku odwołania się aplikacji poprzez identyfikator liczbowy - np. user_detail.aspx?id=1234 spróbować użyć parametru nie będącego liczbą, np.: user_detail.aspx?id=asdqwe
  • W przypadku php dla dowolnego parametru użyć rzutowania na tablicę, np. user_detail.php?id=1234 zamienić na user_detail.php?id[]=1234
  • Jeśli aplikacja korzysta z Cookies - wysłać do aplikacji Cookies z nieprawidłową zawartością (np. ze znakami ' ; " \)

2.    Nieaktualne komponenty.

Do budowy aplikacji webowych czy portali stosuje się często gotowe komponenty czy biblioteki (jako przykład posłużyć mogą popularne systemy zarządzania treścią (CMS) jak np. Joomla!, Liferay czy silnik Wordpress).

W momencie uruchomienia dana wersja systemu może nie posiadać znanych publicznie błędów, ale co będzie np. za rok? Istnieją serwisy - np. secunia.com umożliwiające metodyczne sprawdzenie jakiej klasy błędy występują w danej wersji wykorzystanego komponentu, przykładowo - błędy w Wordpress 3.x

secunia - przykład

Inne tego typu bazy warte wspomnienia: to CVE czy słynny bugtraq.

Korzystając z poprzedniego kroku atakujący może już posiadać sporo informacji o naszym systemie, ale istnieją również inne metody wykrycia wersji komponentów, z których korzystamy - najprostsze sposoby to analiza źródła wybranej strony HTML aplikacji, czy plików charakterystycznych dla danego komponentu - istnieją tutaj gotowe narzędzia, które realizują tego typu testy: nikto, whatweb, czy blindelephant:

whatweb

Przykład działania whatweb, za http://www.morningstarsecurity.com/research/whatweb

Inna metoda to odczytanie standardowych plików typu: README, Changelog, plików z dokumentacją, itp.

Przykładowo, domyślna instalacja Wordpressa zawiera plik readme.html, który informuje nas o wykorzystanej wersji tego oprogramowania. Wystarczy więc wejść na http://adresportalu-gdzie-znajduje-sie-wordpress/readme.html i...mamy wersję wordpressa:

wordpress readme

 

Dla tego typu testów też istnieją gotowe narzędzia - choćby popularny skaner portów nmap z odpowiednimi pluginami NSE  czy wspomniany wcześniej burp suite pro.

 

$ nmap 192.168.0.101 -p 80 -sV --script=http-enum

Starting Nmap 6.01 ( http://nmap.org ) at 2012-07-20 14:08 CEST
Nmap scan report for 192.168.0.101
Host is up (0.00030s latency).
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.16 ((Debian))
| http-enum:
|   /wordpress/: Blog
|   /wp-login.php: Possible admin folder
|   /robots.txt: Robots file
|   /wp-login.php: Wordpress login page.
|   /readme.html: WordPress version 3.4.1
|   /icons/: Potentially interesting folder w/ directory listing
|_  /index/: Potentially interesting folder

Jeszcze inny sposób na lokalizację użytego komponentu to charakterystyczna budowa URLi, czy katalogi charakterystyczne dla danej wersji użytego komponentu. W tym przypadku mogą być pomocne testy ręczne połączone z zapytaniem do google czy innej popularnej wyszukiwarki.

Jak się ochronić?

  • Sprawdź np. na serwerze secunia (lub analogicznym) - czy użyte przez Ciebie wersje komponentów nie posiadają istotnych błędów.
  • Nie wyświetlaj w źródłach HTML informacji o wykorzystanym przez Ciebie rozwiązaniu
  • Usuń niepotrzebne pliki: README, Changelog, pliki z dokumentacją, przykładowymi aplikacjami, itd
  • Użyj narzędzi typu: nmap, nikto, whatweb, czy blindelephant w celu wykrycia dodatkowych problemów

3.    Problemy z panelem administracyjnym

Lokalizacja

Najczęstsza lokalizacja panelu administracyjnego to po prostu katalog: /admin
Jeśli dodatkowo administratorzy stosują proste hasła (nie tak rzadko spotyka się kombinację: admin/admin), czy w mechanizmie logowania występuje np. podatność SQL injection to przejęcie dostępu do portalu może być jedynie kwestią czasu.

Jeśli panel administracyjny nie jest umieszczony w katalogu 'admin', to może jest to np. admin.php albo coś równie oczywistego? Często, atakujący stosują w tym przypadku próby bazujące na swoim doświadczeniu lub używają metody siłowej z wykorzystaniem popularnych słowników zawierających potencjalne lokalizacje panelu administracyjnego.

Inne metody poszukiwania obejmują weryfikację pliku sitemap.xml czy robots.txt - nie chcemy przecież żeby google szperał nam po części administracyjnej systemu - dlatego katalog z administracją widnieje właśnie tutaj:

robots

Inna metoda, to próba odszukania panelu administracyjnego w google (np. operator site: oraz słowa typu administracja, admin, management, itd). Przykładowo:

site: securitum.pl management

Można również spróbować wejść na stronę aplikacji korzystając z przedrostka https, np.: https://portal.test/ - jest szansa że zaprezentowany zostanie certyfikat SSL, a w nim (w common name) adres aplikacji służącej do zarządzania systemem. Oczywiście część administracyjna portalu powinna być dostępna jedynie poprzez protokół https (zapewniający m.in. poufność przesyłanych: loginu i hasła dostępowego).

Niekiedy serwer aplikacyjny, z którego korzystamy posiada również własną konsolę zarządczą dostępną pod innym adresem niż 'standardowa' administracja systemem (często wymaga to bezpośredniego dostępu do application serwera - np. na porcie 8080 TCP). Prostymi przykładami mogą tu być: Tomcat czy JBoss. W przypadku tego pierwszego ścieżka administracyjna to /manager/html, z kolei dla JBossa to /jmx-console (który zresztą posiadał nie tak dawno temu istotną i prostą do wykorzystania podatność) oraz /web-console.

Hasła dostępowe

Osobą sprawą jest stosowanie odpowiednio złożonych haseł administracyjnych (np. hasło Malgorzata1, mimo że długie i pozornie skomplikowane - nie jest dobrym pomysłem), zwracam też uwagę na domyślne konta administracyjne/serwisowe do systemu (np. admin/admin, guest/guest, test/test, konto test@liferay.com z hasłem test dla  domyślnej instalacji popularnego portalu Liferay, albo domyślne hasła dla serwerów aplikacyjnych Tomcat, Jboss, Websphere AS- przykłady można mnożyć).

Jak się obronić?

  • Umieścić panel administracyjny w nietypowym katalogu (trudnym do odgadnięcia)
  • Wymuszać połączenie szyfrowane dla dostępu administracyjnego (https)
  • Wyłączyć (luz zmienić nazwę) kontom o loginie: admin, administrator, itp.
  • Stosować odpowiednio złożone hasła (minimum nie będące hasłami ze słownika oraz o odpowiedniej długości / złożoności - najlepiej > 10 znaków, zawierające małe / duże litery / znaki specjalne / cyfry).
  • Zweryfikować czy w administracji nie ma domyślnych kont administracyjnych / serwisowych.
  • Zlokalizować panele administracyjne dla ew. serwerów aplikacyjnych wykorzystanych w rozwiązaniu i zmienić domyślne hasła dostępowe - optymalnie - nie udostępniać konsoli zarządczych publicznie.
  • Idealnie - umożliwić połączenie administracyjne tylko z wybranych adresów IP
  • Idealnie - zastosować dodatkowo certyfikaty klienckie SSL do połączeń administracyjnych

4.    Inne testowe aplikacje - na tym samym web serwerze

Niekiedy system jest zabezpieczony niemal idealnie... z małym wyjątkiem. Administrator na tym samym fizycznie serwerze i tym samym adresem IP umieścił (np. "po znajomości") aplikację, której zabezpieczenia są... żadne. W tym przypadku atak może wyglądać tak: złamanie tej ostatniej aplikacji, uzyskanie dostępu na poziomie systemu operacyjnego i zaatakowanie w ten sposób aplikacji "głównej". W jaki sposób uzyskać informacje o innych aplikacjach hostowanych na tym samym adresie IP? Może do tego służyć np. mechanizm: reverse Reverse IP Domain Check, dostępny online tutaj.
Po prostu w wyszukiwarkę wpisujemy nazwę interesującej nas domeny, którą chcemy sprawdzić, otrzymując potencjalną listę innych serwisów znajdujących się pod tym samym adresem IP. Innym wartym zaznaczenia sposobem jest odpytanie serwera DNS: odpytujemy o adres IP portalu, a następnie robimy zapytanie odwrotne (reverse lookup) -  tj. podajemy adres IP oczekując w odpowiedzi nazwy. Nazwa ta nie zawsze jest tą od której zaczęliśmy...

Jak się obronić?

  • Mając dostęp do konfiguracji web serwera - zweryfikować czy na tej samej fizycznej maszynie nie innych hostujemy serwisów / aplikacji (np. testowych, zupełnie niezwiązanych z naszą działalnością) które mogą stanowić prosty punkt ataku.

5.    Directory listing

Dość popularnym, a zarazem łatwym do zdiagnozowania problemem jest tzw. funkcjonalność directory listing na serwerach http, polegająca na wyświetlaniu do użytkownika zawartości katalogu, jeśli katalog ten nie zawiera pliku index. Np.: wejście na http://test.securitum.pl/cv/ mogłoby wyświetlić listę plików CV uploadowanych wcześniej przez osoby aplikujące o pracę. Atakujący w tym momencie wystarczy, że zlokalizuje odpowiedni katalog (kłaniają się tutaj metody brute-force lub zdrowy rozsądek). Jeśli atakujący posiada konto w systemie (np. aby aplikować o pracę należy wcześniej założyć konto), to sprawa jeszcze bardziej się upraszcza - śledząc komunikację http można próbować zlokalizować interesujące nazwy katalogów, w których aplikacja przechowuje dane). Przykład:

directory listing

Jak się obronić?

  • Wyłączyć mechanizm Directory Listing na web serwerze
  • Jeśli składujemy pliki bezpośrednio w webroocie (katalog dostępny dla klienta przeglądarką internetową), do których nie powinno być anonimowego dostępu - przenieść pliki poza webroot, a dostęp do nich zapewnić mechanizmem pośrednim.

6.    Wyszukiwarka

Niewinnie wyglądającym elementem może być wyszukiwarka treści w portalu. Prostym trickiem umożliwiającym często wyświetlenie wszystkich zindeksowanych przez wyszukiwarkę zasobów jest użycie tzw. wildcardu, np.: jednego ze znaków: * %

W ten sposób można namierzyć takie strony jak: testowy contest, dostęp do treści dostępnej tylko dla zalogowanych użytkowników, strony z błędami, itd.

Można tutaj zastosować również techniki podobne do google hackingu (wyszukanie słów: test, admin, error, warning, itd).

Dość często wyszukiwarka podatna jest na tzw. cross site scripting (XSS), choć tego problemu akurat nie będę szczegółowo opisywał. Jako podstawowy, prosty test można spróbować wyszukać ciągów:

  •  <script>alert(1)</script>
  • "><script>alert(1)</script>
  • '><script>alert(1)</script>

Jeśli na stronie z wynikami wyszukiwania wyświetlony zostanie popup w javascript - mamy potwierdzenie XSSa :-)

Jak się obronić?

  • Wykonać kilka sprawdzeń wskazanych wcześniej i zweryfikować informacje prezentowane na wyniku wyszukiwania

7.    Upload

Co jest niebezpiecznego w mechanizmie uploadu? A gdyby była możliwość uploadowania na serwer pliku wykonywalnego (.php, .aspx, itd) ? Często programiści nie pamiętają, aby tego typu mechanizmy odpowiednio zabezpieczyć. Dobrym przykładem jest choćby luka w systemie dotnetnuke umożliwiająca anonimowy upload plików .aspx - a tym samym wykonanie poleceń w systemie operacyjnym. Jeśli serwer www działa z uprawnieniami administracyjnymi (częsty przykład to kombinacja: Apache + Windows), to atakujący otrzymuje w ten sposób dostęp administracyjny na systemie operacyjnym.

Wydaje się więc, że naturalnym zabezpieczeniem będzie uniemożliwienie uploadu plików z rozszerzeniem wykonywalnym (np. php), prawda? Niekoniecznie. Prosty przykład: mało znanym problemem, jest domyślny sposób obsługi plików przez serwer www apache. W jaki sposób zostanie obsłużony uploadowany plik z rozszerzeniem 543?, np.:

shell.php.nslo.12kwo.534

Rozszerzenie '.534' nie jest znanym przez Apache typem plików, podobnie '12kwo' czy 'nslo' - web serwer będzie więc próbował 'cofać się', chcąc zlokalizować pierwsze obsługiwane przez siebie rozszerzenie, a będzie nim .php!

W celu ochrony należy zastosować tu inną metodę - tj. dokładnie wskazać jakie rozszerzenia plików mogą być uploadowane (np. tylko .jpg .png .gif czy .doc).

Swoją drogą, błąd ten dość często występuje w co najmniej dwóch innych odmianach. Jeśli do formatowania treści używamy edytora wizualnego (np. fckeditor, tinymce) to być może część elementów (np. upload manager) jest dostępna anonimowo - wystarczy jedynie zlokalizować katalog, w którym dany edytor jest dostępny publicznie a następnie spróbować czy nie istnieje możliwość uploadu dowolnych plików na serwer. Inna odmiana to przykładowe aplikacje instalowane z biblioteką czy środowiskiem, na którym działa nasza aplikacja. Co jeśli zawierają one niezabezpieczony przykład funkcjonalności uploadu...?

Poniżej - krok po kroku, sposób w który nastąpić może atak:

upload problem

Jak się obronić?

  • Jeśli posiadamy mechanizm uploadu, zweryfikować czy istnieje możliwość umieszczenia na serwerze plików o innych rozszerzeniach niż zamierzane (np. jpg, .pdf, itp)
  • Umożliwiać upload plików tylko o popularnych, niewykonywalnych przez web serwer rozszerzeniach.

Polecane linki

 

--Michał Sajdak (michal.sajdak@securitum.pl)

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS