Web14: Problemy bezpieczeństwa w protokole HTTP

W tym artykule przedstawiono pewne problemy bezpieczeństwa w protokole HTTP , poruszone w dwóch dokumentach RFC 7230 i RFC 7231. Przykłady w artykule dotyczące konkretnych błędów pochodzą z OWASP.

1. Ryzyka czynników pośrednich

HTTP pozwala na korzystanie z pośredników w celu odpowiadania na żądania poprzez serię połączeń. Istnieją trzy wspólne elementy pośredniczące: serwer proxy, brama i tunel.

Żądanie lub odpowiedź będzie musiało przejść przez punkty A, B i C. Mogą uzyskać dostęp do przesyłanych poufnych informacji, takich jak dane osobowe użytkowników lub organizacji. Brak dbałości o bezpieczeństwo i prywatność przez pośredników może prowadzić do szerokiej gamy potencjalnych ataków.

Twórcy i programiści systemów powinni wziąć pod uwagę czynniki związane z prywatnością i bezpieczeństwem podczas projektowania, kodowania i wdrażania systemu.

Użytkownicy muszą zdawać sobie sprawę z niebezpieczeństw związanych z korzystaniem z niezaufanych serwerów proxy lub bram.

2. Podział odpowiedzi

Dzielenie odpowiedzi (inaczej wstrzykiwanie CRLF) to popularna technika wykorzystująca luki w sieci. Osoba atakująca wysyła zakodowane dane w niektórych parametrach żądania, które są następnie dekodowane i powtarzane w określonym polu nagłówka odpowiedzi.

Jeśli te dane są symbolem końca odpowiedzi i zainicjowana zostanie kolejna odpowiedź, pierwotna odpowiedź zostanie podzielona na dwie części, a treść drugiej odpowiedzi będzie kontrolowana przez atakującego. Osoba atakująca może następnie wysłać kolejne żądanie w ramach tego samego trwałego połączenia i oszukać odbiorcę (w tym pośredników), aby uwierzył, że ta druga odpowiedź jest odpowiedzią na drugie żądanie.

3. Poproś o przemyt

Przemyt żądań to technika wykorzystująca różnice w przetwarzaniu żądań przez różne typy serwerów w celu ukrycia pozornie nieszkodliwych żądań dołączonych do pierwotnego żądania.

Rozważmy następujący przykład:

Załóżmy, że żądanie POST zawiera w nagłówku dwa pola „Długość treści” z dwiema różnymi wartościami. Niektóre serwery odrzucą to żądanie (IIS i Apache), ale inne nie. Na przykład SunONE W/S 6.1 używa najpierw pola Długość treści, podczas gdy sunONE Proxy 3.6 wykorzystuje pole Długość treści w drugiej kolejności.

Zakładając, że SITE to DNS urządzenia SunONE W/S, znajdującego się za serwerem proxy SunONE, na urządzeniu SunONE W/S znajduje się plik trujący.html. Oto jak wykorzystać sugestię żądań HTTP w oparciu o niespójności w przetwarzaniu między dwoma serwerami:

[Zauważ, że każda linia kończy się CRLF („”), z wyjątkiem linii 10]

Zastanówmy się, co się stanie, gdy żądanie zostanie wysłane do W/S poprzez serwer proxy. Najpierw serwer proxy przeanalizuje żądanie z linii od 1 do 7 (niebieskie) i napotka dwa pola Content-Length. Jak wspomniano powyżej, zignoruje pierwsze pole i zrozumie, że treść żądania ma długość 44 bajtów. Dlatego traktuje dane z linii od 8 do 10 jako treść pierwszego żądania (od linii 8 do 10 dane mają dokładnie 44 bajty). Serwer proxy przeanalizuje następnie linie od 11 do 14 (na czerwono) jako drugie żądanie klienta.

Zobaczmy teraz, jak W/S interpretuje powyższe dane przesyłane z serwera proxy. W przeciwieństwie do proxy, W/S użyje pierwszego pola Content-Length i zinterpretuje je w następujący sposób: pierwsze żądanie nie ma treści, a drugie żądanie zaczyna się od linii 8 (należy pamiętać, że W/S będzie analizować począwszy od linii 11 jako wartość pola Bla).

Następnie przyjrzyjmy się, w jaki sposób odpowiedź jest zwracana klientowi. Żądanie, które W/S rozumie, to „POST /foobar.html” (z linii 1) i „GET /poison.html” (z linii 8), więc wyśle ​​klientowi 2 odpowiedzi z zawartością strony foobar. html i trucizna.html. Serwer proxy rozumie, że te 2 odpowiedzi odpowiadają 2 żądaniom: „POST /foobar.html” (z linii 1) i „GET /page_to_poison.html” (linia 11). Serwer proxy będzie buforował zawartość strony trucizna.html odpowiadającej adresowi URL „page_to_poison.html” (zatruwanie pamięci podręcznej). Stamtąd, gdy klient zażąda „page_to_poison.html”, otrzyma zawartość strony trucizna.html.

4. Atak oparty na ścieżce pliku

Serwery internetowe często używają lokalnego systemu plików do zarządzania mapowaniem nazw plików w identyfikatorach URI na rzeczywiste zasoby na serwerze. Większość systemów plików nie jest zaprojektowana do ochrony przed złośliwymi ścieżkami plików. Dlatego serwer musi unikać dostępu do ważnych plików systemowych.

Na przykład UNIX, Microsoft Windows i kilka innych systemów operacyjnych używają „..” jako elementu ścieżki do reprezentowania katalogu o jeden poziom powyżej bieżącego pliku/katalogu. Bez odpowiedniej kontroli wprowadzania danych i autoryzacji dostęp do wrażliwych plików/folderów systemu można uzyskać poprzez wprowadzenie ścieżek wskazujących te pliki/foldery.

5. Rodzaje ataków: Command Injection, Code Injection, Query Injection

[Serwery internetowe często używają parametrów w identyfikatorze URI jako danych wejściowych do wykonywania poleceń systemowych i zapytań do bazy danych. Jednak danym otrzymanym we wniosku nie zawsze można ufać. Osoba atakująca może tworzyć i modyfikować komponenty żądania (takie jak metody, pola w nagłówku, treści...), aby wykonywać polecenia systemowe, wysyłać zapytania do bazy danych...

Na przykład SQL Injection to powszechny atak, podczas którego serwer WWW otrzymuje parametry w identyfikatorze URI będące częścią zapytania SQL. Dlatego osoba atakująca może oszukać serwer WWW w celu wykonania nielegalnych zapytań SQL w celu kradzieży lub sabotażu bazy danych.
Co do zasady, dane przekazywane przez użytkowników nie powinny być wykorzystywane bezpośrednio do wykonywania operacji na serwerze. Dane te muszą przejść przez filtry, które określają, co jest prawidłowe, a co nie, eliminując w ten sposób niepożądane dane.

6. Ujawnianie danych osobowych

Klienci często zawierają wiele danych osobowych, w tym informacje podane przez użytkownika w celu interakcji z serwerem (takie jak nazwa użytkownika, hasło, lokalizacja, adres e-mail itp.) oraz informacje na temat aktywności przeglądania stron internetowych użytkownika (historia, zakładki, itp.). Podczas wdrażania należy zwrócić uwagę na zapobieganie punktom, które mogą ujawnić te prywatne informacje.

7. Ujawnianie wrażliwych informacji w URI

Identyfikatory URI z założenia mają być udostępniane wszystkim użytkownikom i nie gwarantuje się ich bezpieczeństwa. Identyfikatory URI są często wyświetlane w kodzie źródłowym witryny i przechowywane w zakładkach bez mechanizmów ochronnych. Dlatego też będzie niebezpieczne, jeśli URI będzie zawierał poufne informacje, dane osobowe itp.

Unikaj używania metody GET do wysyłania danych osobowych na serwer, ponieważ będą one wyświetlane w identyfikatorze URI. Zamiast tego użyj metody POST.

8. Ujawnianie informacji o używanym oprogramowaniu

Pola User-Agent, Via, Server w nagłówku zazwyczaj dostarczają informacji o oprogramowaniu używanym przez nadawcę. Teoretycznie umożliwia to atakującym łatwiejsze wykorzystanie znanych luk w zabezpieczeniach tego oprogramowania.