Bezpieczeństwo web (część II): Odkrywanie ukrytej zawartości

Minęło już sporo czasu od ostatniego wpisu na temat bezpieczeństwa. Tak jak wspomniałem w pierwszym wpisie, dobrym sposobem na zabezpieczenie własnych aplikacji jest zrozumienie jak ta druga strona może próbować znaleźć lukę w naszym systemie. Mapowanie to pierwszy etap, który ma na celu rozpoznanie najmniej chronionych fragmentów aplikacji – zadziwiająco często można znaleźć bardzo wrażliwe informacje takie jak logi czy nawet hasła.

W poprzednim wpisie stworzyliśmy podstawową mapę, składającą się po prostu z publicznie dostępnych informacji, wygenerowanych manualnie oraz za pomocą spidering. Użyliśmy narzędzia Burp Suite, które jest również dostępne w darmowej wersji. W prostych przypadkach, czasami łatwiej napisać po prostu aplikacje konsolową w C#, która zrobi za nas np. wspomniany spidering, ale warto mimo wszystko przyzwyczaić się do zewnętrznych narzędzi.

Dzisiaj chciałbym pokazać na czym polega mapowanie ukrytej zawartości. Za ukryte strony mam na myśli tą zawartość, do której nie można dostać się za pomocą publicznej strony bo po prostu nie jest ona podlinkowana. Z tego względu, często programiści zapominają o niej i nie stosują autoryzacji. Co możemy znaleźć w takich plikach?

1. Logi – bardzo często przechowywane są w tym samym folderze co aplikacja, a co za tym idzie prawdopodobne jest, że ktoś zignorował autoryzację.

2. Kopie zapasowe. Szczególnie we współdzielonych hostingach, kopie są umieszczane w folderze aplikacji. Jeśli nie są chronione, istnieje prawdopodobieństwo, że uzyskamy dostęp do danych lub kodów źródłowych.

3. Hasła – wiem, że to mało prawdopodobne, a jednak. Bywały przypadki w historii, gdzie ludzie przechowywali pliki tekstowe z… hasłami.

4. Kody źródłowy – czasami osoby zamiast DLL przekopiowują cały kod, lub edytując skrypty (np. PHP), chwilowo zamieniają stare nazwy na np. “HomePage.php.txt”.

5.  Niechronione strony. Jeśli aplikacja ma mechanizm autoryzacji, warto spróbować otworzyć różne strony bez niej. Często autorzy popełniają błąd, myśląc, że skoro strona nie jest dostępna publicznie, to nie musi być chroniona.  Czasami wynika to po prostu z błędu – np. pominięcia atrybutu Authorize dla jednego kontrolera.

Odkrycie takiej zawartości jest jednak dużo trudniejsze i zwykle polega na zgadywaniu. Wymaga to sporej znajomości m.in. technologii wykorzystywanych przez daną stronę (o tym nauczymy się w następnych wpisach). Wiedząc np. jaki framework jest wykorzystywany do wykonywania logów, możemy domyśleć się gdzie są one przechowywane. Podobnie wygląda sprawa z kopią zapasową.

Nie oznacza to, że przeprowadzenie wspomnianego ataku jest niemożliwe… W Internecie istnieje wiele list zawierających najczęściej występujące nazwy plików i folderów. Listy te mogą mieć nawet tysiące wpisów. Posiadając taką listę, można automatycznie wygenerować zapytania do serwera. Na przykład, używając Burp Suite wystarczy przejść do Intruder->Positions i podać szablon zapytania HTTP:

1

Należy również załadować wspomnianą listę:

1

Po odpaleniu zapytań (Intruder->Start attack), zobaczymy listę zapytań. Warto zwrócić uwagę na zwracany kod HTTP i długość zapytania. Niektóre strony mogą zwracać HTTP 200, pomimo, że strona nie istnieje – po prostu maja swoją własną stronę z błędami. Dlatego obserwowanie kolumny Length może być bardziej skuteczne.

Leave a Reply

Your email address will not be published.