Obrona wyjaśnia zanieczyszczenie parametrów HTTP

Spis treści

Zanieczyszczenie parametrów HTTP

W warunkach tworzenie aplikacji podczas standardowych faz, architektura aplikacji wielowarstwowych jest powszechna. Architektura wielowarstwowa to architektura klient-serwer, w której prezentacja, przetwarzanie aplikacji i zarządzanie danymi to zupełnie oddzielne procesy. Mówiąc najprościej, architektura wielowarstwowa jest wygodna dla programistów. Powodem, dla którego jest wygodna dla programistów, jest fakt, że programiści muszą ponownie używać kodu i rozwijać aplikacje, w których cały framework aplikacji nie musi być pisany od nowa. Mogą modyfikować tylko części architektury aplikacji w oparciu o warstwy i zyskać elastyczność w korzystaniu z takich aplikacji. Niestety przetwarzanie tych samych danych na wielu platformach może prowadzić do naruszenia bezpieczeństwa lub pozostawić aplikację podatną na ataki. Błędy logiczne są wyzwalane w ten sposób i są zupełnie inne od ataków opartych na wstrzykiwaniu, takich jak:

LDAP/Ślepe wstrzykiwanie LDAP
Wstrzyknięcie XML
Wstrzyknięcie HTML
SQL Injection
Wtrysk oparty na ORM
Wstrzyknięcie Spring/wstrzyknięcie nHibernate
Wstrzyknięcie Xpath
Wstrzykiwanie polecenia

Wszystkie wyżej wymienione warianty „wstrzyknięć” zaliczają się do luk w zabezpieczeniach aplikacji na poziomie kodu i są zupełnie inne od luk „logicznych”, które nadal mają większy wpływ na aplikacje internetowe. Podczas moich starych badań na wczesnych etapach analizy wzorców zachowań różnych aplikacji opartych na platformach na różnych architekturach internetowych odkryłem, że prowadzą one do kilku luk opartych na logice, które mogą być wykorzystane przez atakującego dla korzyści. To doprowadziło moją ciekawość do dalszych badań i doszedłem do wniosku, że coś, co już istniało, nazywa się „zanieczyszczeniem parametrów HTTP lub HPC”. Podczas moich badań w Defencely odkryłem, że ta konkretna metodologia ataku nie polega tylko na określonej platformie, ale jest szeroko stosowana na wielu innych różnych platformach internetowych, takich jak PHP na Apache, ASP.NET na serwerach IIS itp.

Zanieczyszczenie parametrów HTTP korzystne

Zanim udowodnię absolutną konieczność ręcznego testowania aplikacji, muszę powiedzieć, że wskazanie beneficjentów tej konkretnej luki byłoby bardzo istotne dla całej społeczności bezpieczeństwa. Ale zanim to zrobimy, zobaczmy, jak aplikacje są wdrażane na różne sposoby i traktowane w różny sposób, gdy są obsługiwane lub wywoływane w celu wykonania „użytecznego zadania”. Chcę, aby czytelnicy znali już podstawowe zasady wdrażania aplikacji, dlatego przechodzę do kolejnych kroków, z którymi czytelnicy muszą być już zaznajomieni. Architektura sieci Web stała się bardziej złożona i aby wszystko było prostsze dla programistów, programiści dodają warstwy (cykl życia RAD), aby ponownie wykorzystać funkcje tych warstw, ale samo to może wprowadzić luki w zabezpieczeniach. Poniższy diagram ilustruje, jak ogólna aplikacja jest wdrażana dla wygody:

Zgodnie z HTTP Parameter Pollution, które odnosi się do dodatkowego umieszczenia ciągów zapytań o tej samej nazwie, manipulując logiką, w jaki sposób ten nowo utworzony ciąg zapytań jest obsługiwany przez program obsługi HTTP serwera WWW; istnieją możliwości ataków HTTP Parameter Contamination, które celują w logiczne słabości architektury WWW, mogą być wykorzystane na korzyść atakujących. To właśnie tutaj ręczny przegląd testów penetracyjnych jest istotną częścią wszelkich testów bezpieczeństwa, niezależnie od tego, czy jest to przegląd kodu aplikacji wraz z przeglądem logiki serwera WWW, czy formalny test penetracyjny aplikacji. Aby naprawdę wykorzystać moc HTTP Parameter Contamination, tester penetracyjny lub atakujący musi mieć głębszą wiedzę na temat protokołu HTTP i programu obsługi HTTP, z którym ma do czynienia. Ponadto atakujący lub tester penetracyjny sieci musi wiedzieć, w jaki sposób ataki HTTP Parameter Pollution mogą być testowane, aby zapewnić bezpieczeństwo lub ukierunkować aplikację na ich beneficjentów. Więc kim są ci beneficjenci?

Zanieczyszczenie parametrów protokołu HTTP może służyć do obchodzenia różnych filtrów, ograniczeń bezpieczeństwa lub regulacji mających na celu ominięcie zapór sieciowych aplikacji internetowych.
Zanieczyszczenie parametrów protokołu HTTP może zostać wykorzystane przez atakującego w celu skorzystania z luk w zabezpieczeniach, jakie może wygenerować program obsługi protokołu HTTP, np. w postaci informacyjnych błędów serwera internetowego.
Atakujący może wykorzystać zanieczyszczenie parametrów protokołu HTTP równolegle z istniejącymi lukami w zabezpieczeniach, aby ominąć zasady bezpieczeństwa i wykorzystać te luki.

Załóżmy na przykład, że konkretny kod ASP zaplecza wygląda następująco:

Używanie ładunku: http://127.0.0.1/test.asp?file=.%./shritam_bhowmick.txt

Możliwe jest ominięcie ograniczeń bezpieczeństwa, które są dostarczane przez mod_security i tym samym przeprowadzenie ataków path traversal, które pierwotnie nie były możliwe. To (Path Traversal) w przeciwieństwie do HTTP Parameter Contamination uczyniło takie odporne ataki możliwymi i w związku z tym faktycznie manipulowało zapytaniem w jakiś sposób, aby dokonać obejścia, wykorzystując sposób, w jaki ruch HTTP był obsługiwany przez HTTP Handler. Podobnie można to wykorzystać wraz z MS-SQL Injection, w którym serwer IIS używający baz danych MS-SQL może doprowadzić do krytycznego naruszenia i tym samym spowodować poważne uszkodzenie.

Przykład:

Wzorzec tutaj, aby ominąć MS-SQL Injection, który miał poprzednie ograniczenia bezpieczeństwa, używał HPC lub HTTP Parameter Contamination. To może być również skierowane na interpretery PHP.

Przykładowy kod PHP dla zaplecza:

A Perl nie jest już niezniszczalny:

Kod Perl wraz z zastosowanym zanieczyszczeniem parametrów HTTP dał następujące wyniki:

Teraz, gdy udowodniłem swoją tezę w różnych aplikacjach zachowujących się w odmienny sposób, korzystając z ładunków HTTP Parameter Contamination, wnioskiem jest to, że nie należy wykorzystywać czasu produkcyjnego programistów, aby zmuszać ich do poświęcania czasu na rozwój, a zamiast tego skupić się na ręcznych testach penetracyjnych Branże aby złagodzić poważniejsze problemy, z którymi miałem już wcześniej do czynienia w przypadku aplikacji korporacyjnych na dużą skalę.

Obronnie – Nie do złamania

Wśród bezpieczeństwa aplikacji w Indiach Defencely jest wiodącą firmą, która udowodniła swoje usługi na całym świecie w krótkim czasie i z ogromnymi historiami sukcesu do podzielenia się. Defencely jest dostawcą usług bezpieczeństwa aplikacji i obecnie ma różne usługi poza bezpieczeństwem aplikacji. Obejmuje to:

Bezpieczeństwo aplikacji internetowych
Bezpieczeństwo sieci
mobile Security
Bezpieczeństwo logiki biznesowej

Strefa bezpieczeństwa bez zbędnych ceregieli właśnie objęła prowadzenie dzięki swojemu ogromnemu doświadczeniu eksperckiemu z silnym działem badawczym. Podstawową wizją Defencely jest zapewnienie klientom „bezpieczeństwa” w najlepszym wydaniu i prowadzenie „badań nad bezpieczeństwem”, odkrywanie nowych sposobów, wprowadzanie innowacji w zakresie nowych koncepcji bezpieczeństwa i dostarczanie ich cenionym klientom. Defencely.com nie tylko zyskało silną obecność w Indiach, ale także rozszerzyło swoje usługi na cały świat, aby wywrzeć głęboki wpływ na branżę bezpieczeństwa dzięki rosnącej wiedzy specjalistycznej w tym, co robi. Skupienie i jakość, jaką oferuje, są niesamowitym atutem dla każdego dostawcy korzystającego z jego usług, a wśród liderów już pojawiło się sporo szumu. Aby wykonać kolejny krok naprzód, Defencely kieruje teraz z Teksasu z silną obecnością w Indiach i USA. Jest to niezbędna rekomendacja dla potrzeb biznesu internetowego w zakresie bezpieczeństwa. Nic nie mogło pokonać silnego zespołu Defencely.

Czytać: Czy dzieci stanowią zagrożenie dla bezpieczeństwa w Internecie?

O autorze

Śritam Bhowmick jest profesjonalnym testerem penetracji aplikacji, wyposażonym w tradycyjne, jak i profesjonalne doświadczenie w testach penetracji aplikacji, dodając wartości Defencely Inc. Red Team i obecnie posiada wiedzę techniczną w zakresie raportowania zagrożeń aplikacji i koordynacji dla globalnych klientów Defencely Inc. Na swoim koncie ma doświadczenie w identyfikowaniu krytycznych luk w aplikacjach i dodawaniu wartości Defencely Inc. dzięki swojej pracy badawczej. Sektor badawczo-rozwojowy w zakresie bezpieczeństwa aplikacji staje się zielony w Defencely i jest przez niego obsługiwany. Zawodowo ma doświadczenie w kilku innych firmach pracujących nad zaangażowaniem w testy penetracji aplikacji krytycznych, kierując Red Team, a także ma doświadczenie w szkoleniu ciekawych studentów w czasie wolnym. Facet od bezpieczeństwa aplikacji!

Shritam Bhowmick dostarczył wiele prac badawczych, które w większości skupiają się na bezpieczeństwie aplikacji i uwielbia wykraczać poza szczegóły. To podejście sprawiło, że zaczął wprowadzać innowacje, zamiast wyważać otwarte drzwi, aby inni mogli wykorzystać stare koncepcje bezpieczeństwa. W wolnym czasie, którego jest niewiele, pisze bloga, burzy mózgów na temat koncepcji bezpieczeństwa sieci i woli trzymać się z dala od normalnego życia. Oprócz życia zawodowego znajduje błogość w czytaniu książek, grze w szachy, filantropii i koszykówce dla wytchnienia. Uwielbia oglądać horrory filmy dla dreszczyku emocji.