W jaki sposób moduły równoważenia obciążenia i rzeczywiste relacje IP zagrażają Twojemu bezpieczeństwu?

Jedną z zalet bycia specjalistą ds. bezpieczeństwa jest praca z wieloma zespołami. Po audycie specjaliści ds. bezpieczeństwa będą mieli możliwość współpracy z administratorami i analitykami baz danych. Aby aplikacja działała poprawnie i bezpiecznie, zespoły te starają się radzić sobie z lukami w zabezpieczeniach, które mają wspólną podstawę. Dialogi między tymi zespołami poruszają pewne problemy z prawdziwym IP.

Koncepcje proxy i rzeczywistego adresu IP

Dzisiejsze aplikacje internetowe działają na wielu serwerach aplikacji i systemach baz danych. Wyobraź sobie dwa serwery aplikacji współdzielące ten sam kod źródłowy. Żądania użytkownika są gotowe do spełnienia przez jeden z tych serwerów w zależności od obciążenia. Mechanizm równoważenia obciążenia, który obsługuje żądania HTTP przed serwerami aplikacji, decyduje, które żądanie przekazać do którego serwera aplikacji. Stawia to duże pytanie dla administratorów systemów oprogramowania pośredniczącego i twórców oprogramowania: jaki jest prawdziwy adres IP użytkownika?

Proxy są odpowiedzialne za przesyłanie danych między dwoma systemami. Moduł równoważenia obciążenia jest mechanizmem odpowiedzialnym za serwer proxy. Innymi słowy, tylko jeden system komunikuje się zarówno z użytkownikiem, jak iz serwerem aplikacji. Jeśli chodzi o ruch sieciowy, serwery WWW A lub B zawsze komunikują się z adresem IP systemu równoważenia obciążenia. To samo można powiedzieć o użytkownikach. Dla specjalistów ds. bezpieczeństwa systemy równoważenia obciążenia powodują poważne problemy w atakach typu SQL injection opartych na czasie. Ale głównym celem jest tutaj fałszowanie adresów IP.

X-Forwarded-For i relacja IP

Rozważ związek między X-Forwarded-For, programistą i oprogramowaniem pośredniczącym. Załóżmy na przykład, że zadaniem twórcy aplikacji jest rejestrowanie wszystkich działań, takich jak błędne próby podania hasła przez użytkowników, wraz z ich adresami IP. W pierwszej kolejności programista ustali adres IP użytkownika, gdy żądanie HTTP zostanie spełnione z możliwością, jaką daje używany przez niego język programowania i będzie próbował dalej wykorzystywać te dane w aplikacji.

Ponieważ jego adres IP będzie stały podczas procesu programowania, podczas testów zawsze będzie widział ten sam adres, ponieważ generalnie komputery użytkowników w sieciach korporacyjnych pracują ze statycznym adresem IP przez adres MAC. Jednostka przeprowadzi kilka testów akceptacyjnych; jednak będą z nimi problemy. Jednostka testowa przekaże ten problem twórcy oprogramowania.

Na tym etapie programista może napisać kontroler w środowisku programistycznym i zobaczyć żądanie HTTP przesłane do aplikacji w surowej postaci, ponieważ wszyscy mają ten sam adres IP. Spowoduje to pracę z X-Forwarded-For.

Informacje nagłówka o nazwie X-Forwarded-For zostaną wysłane do serwera aplikacji. Na tym etapie programista zobaczy swój adres IP, który kontroluje za pomocą ipconfig, a nie moduł równoważenia obciążenia, który widzi w dziennikach. Wielu programistów uważa, że ​​mogą rozwiązać ten problem za pomocą takiego bloku kodu:

function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode(',', $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: false;
}


To nie wystarczy — programista musi sprawdzić, czy wartość przychodząca jest prawidłowym adresem IP.

Wszystko powyżej należało do części obsługiwanej przez dewelopera. Jednak aby aplikacja działała prawidłowo i bezpiecznie, zespoły — pracując razem w teorii, ale w rzeczywistości, w skrajnych punktach od siebie — próbują radzić sobie z lukami w zabezpieczeniach, które mają wspólną podstawę. Teraz spróbuj spojrzeć na problem z perspektywy osoby odpowiedzialnej za konfigurację load balancera.

Administratorzy systemu mogą pomyśleć, że programiści rejestrują informacje, takie jak X-Forwarded-For, ponieważ nie można ufać danym w żądaniu HTTP. Ci administratorzy często przesyłają X-Forwarded-For; jednak przesyłają również źródłowy adres TCP systemu, który wysłał żądanie, jako drugą wartość nagłówka. Struktura True-Client-IP jest tego dobrym przykładem.

Kiedy połączysz te wszystkie rzeczy razem, dwie różne jednostki podążają różnymi ścieżkami dla tego samego problemu, znanego jako fałszowanie adresu IP klienta. Rezultatem jest krytyczny problem, w którym nie zadziała żadne rejestrowanie adresów IP ani autoryzacja oparta na adresach IP.

W jaki sposób w testach penetracyjnych wykrywane jest fałszowanie adresu IP klienta?

Większość testerów penetracyjnych używa Firefoksa do kontroli bezpieczeństwa. Konfigurują Firefoksa za pomocą prostego dodatku X-Forwarded-For: 127.0.0.1 dla wszystkich żądań HTTP. I tak wzrasta możliwość wykrycia takich podatności we wszystkich testach penetracyjnych. Przeprowadzenie audytu zgodnie z listą kontrolną OWASP zapewnia sprawdzenie, czy nie występują takie luki. Jednak do wykrycia podatności X-Forwarded-For potrzebny jest moduł w aplikacji, który pokazuje Twój adres IP lub podjęte działania.

Jak rozwiązać lukę X-Forwarded-For

Organizacje potrzebują obowiązkowego dokumentu dotyczącego tworzenia bezpiecznych aplikacji dla wszystkich zespołów programistów i firm outsourcingowych. Na przykład, jeśli potrzebujesz adresu IP użytkownika, firma powinna planować z wyprzedzeniem i ustanowić regułę dotyczącą informacji nagłówka, których będzie tutaj używać. W przeciwnym razie różne zespoły będą produkować różne rozwiązania. Jeśli nie da się zaradzić takiej sytuacji, w grę wejdzie outsourcing aplikacji, co utrudni pomiar kodów źródłowych. Generalnie firmy nie chcą iść taką drogą.

Ale aby rozwiązać ten problem, możesz użyć następującej reguły F5:

when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}


Spowoduje to usunięcie pola X-Forwarded-For w żądaniu HTTP ze świata zewnętrznego. Następnie przesyła żądanie, dodając adres IP systemu, który wysłał do niego żądanie. W ten sposób tworzona jest wiarygodna lista oprogramowania, które działa zgodnie z X-Forwarded-For.

Podsumowując, najważniejszym celem jest wykonanie pewnych kontroli żądań HTTP i stworzenie niezawodnego środowiska. Powyższy blok kodu jest dobrym przykładem, którego możesz do tego użyć.

Ramy i dokumentacja cyberbezpieczeństwa dla przedsiębiorstw

Jednostki, które wydają się być od siebie niezależne, są w rzeczywistości częściami całości. Dlatego wszystko musi działać systematycznie. Zasady ustalone wcześniej muszą być stosowane pomiędzy każdą jednostką. Jeśli taki działający system nie zostanie przyjęty, może wystąpić wiele problemów, takich jak luka X-Forwarded-For. W tym celu należy wcześniej wszystko przemyśleć i wykorzystać możliwie wszechstronną dokumentację.

Każda jednostka w tym dużym systemie musi przyjąć i wdrożyć ramy cyberbezpieczeństwa. Twoim punktem wyjścia powinno być zbadanie i poznanie logiki działania tych frameworków.