- Atak polegający na zanieczyszczaniu parametrów protokołu HTTP polega na wykorzystaniu zduplikowanych parametrów w celu zmiany logiki aplikacji internetowych poprzez wykorzystanie pierwszeństwa wartości.
- Jego skutki są różne, od drobnych awarii po omijanie uwierzytelniania i omijanie zabezpieczeń WAF, dotykając nawet dużych dostawców.
- Możliwości automatycznego wykrywania są ograniczone, dlatego konieczne jest łączenie specjalistycznych narzędzi, testowanie ręczne i stosowanie dobrych praktyk bezpiecznego programowania.
- Zrozumienie, w jaki sposób każdy stos obsługuje powtarzające się parametry, jest kluczowe dla złagodzenia problemu HPP i uniknięcia niespójności między walidacją a faktycznym użyciem.
Kiedy mówimy o bezpieczeństwie aplikacji internetowych, wiele osób myśli tylko o Wstrzyknięcie SQL, XSS lub błędy uwierzytelnianiaJednakże od lat stosowana jest dość cicha technika, która nadal pozostaje niezauważona w wielu audytach: zanieczyszczenie lub skażenie parametrów HTTP, znane jako Zanieczyszczenie parametrów HTTP (HPP) o Zanieczyszczenie parametrów HTTP.
Ten typ podatności wykorzystuje sposób, w jaki różne technologie serwerowe i struktury zarządzają duplikaty parametrów w tym samym żądaniu HTTPJeśli aplikacja nie jest na to przygotowana, atakujący może zmienić jej wewnętrzną logikę, ominąć walidację, oszukać zapory aplikacji internetowych (WAF), a nawet przejąć kontrolę nad krytycznymi funkcjami, takimi jak uwierzytelnianie lub zarządzanie uprawnieniami.
Koncepcja parametrów HTTP i pierwszeństwa
Na praktycznie każdej nowoczesnej stronie internetowej użytkownicy przesyłają dane za pośrednictwem Parametry HTTP w adresie URL lub w treści żądaniaParametry te pozwalają przeglądarce na przekazywanie aplikacji informacji: wyszukiwań, danych w formularzach, wyborów w ankietach, komentarzy, danych logowania itp.
W typowym żądaniu GET dane te przesyłane są w ciąg zapytania (wszystko, co następuje po znaku ? w adresie URL)Pary klucz/wartość są rozdzielone symbolem ampersandu (&). W żądaniu POST mogą one znajdować się w treści, ale logika aplikacji na serwerze zazwyczaj traktuje je bardzo podobnie: klucze z jedną lub wieloma skojarzonymi wartościami.
Wiele języków programowania i frameworków zapewnia metody umożliwiające uzyskanie obu pojedyncza wartość parametru jak np. kompletna lista wartości, jeśli dany parametr pojawia się wielokrotnie. Jest to powszechne na przykład w przypadku pola wyboru umożliwiające wielokrotny wybór, gdzie ta sama nazwa parametru pojawia się kilka razy.
Problem pojawia się, gdy deweloper zakłada, że Na każdy parametr będzie przypadać tylko jedna wartość. i używa funkcji, które zwracają pojedynczą wartość, podczas gdy przeglądarka (lub atakujący) wysyła wiele wartości o tej samej nazwie. W tym momencie pojawia się kluczowa koncepcja: pierwszeństwo wartości.
W zależności od języka, struktury i serwera WWW wielokrotne występowanie tego samego parametru może skutkować różnymi zachowaniami: pierwsza otrzymana wartośćże on bierze ostatnia wartość lub który jest generowany kombinacja wszystkiego (na przykład połączona przecinkami)Nie ma jednego standardu, więc każda technologia może zachowywać się inaczej, co otwiera drogę bardzo niebezpiecznym sytuacjom.
Fakt, że funkcja zwraca tylko jedną wartość, nie jest sam w sobie podatnością, ale gdy istnieje Duplikacja parametrów i nieświadomość dewelopera W zależności od tego, jak działa ta precedensowość, aplikacja może uzyskać nieoczekiwaną wartość. To właśnie to nietypowe zachowanie wykorzystują techniki. Zanieczyszczenie parametrów HTTP.
Czym jest zanieczyszczenie parametrami HTTP (HPP)?
Zanieczyszczenie parametrów HTTP to technika polegająca na: wstrzyknij dodatkowe parametry lub ograniczniki ciągu zapytania (zakodowany) w innych istniejących parametrach. Gdy wstrzykiwany parametr zostanie zdekodowany i ponownie użyty do wygenerowania nowego adresu URL lub skonstruowania kolejnego żądania, aplikacja W efekcie dodano dodatkowe parametry, których twórca nie przewidział..
Innymi słowy, HPP wykorzystuje sposób, w jaki aplikacja Rekonstruuje adresy URL, przetwarza formularze i obsługuje powtarzające się parametry.Jeśli dane wejściowe nie zostaną poprawnie zweryfikowane, atakujący może zmusić aplikację do interpretowania wartości innych niż oczekiwane lub do uwzględnienia dodatkowych parametrów w linkach, formularzach i przekierowaniach.
Techniki HPP zostały publicznie wprowadzone przez Stefano Di Paola i Luca Carettoni na konferencji OWASP AppSec 2009. Od tego czasu zostały udokumentowane wiele scenariuszy atakówJednak nawet dziś nie są one tak widoczne, jak inne, lepiej znane luki w zabezpieczeniach, ani nie są w pełni wykrywane przez wszystkie zautomatyzowane narzędzia.
Wpływ ataku polegającego na zanieczyszczeniu parametrów HTTP w dużej mierze zależy od szczególna logika aplikacjiframeworka i serwera WWW. W niektórych przypadkach konsekwencje są niewielkie (błędy prezentacji, problemy z drukowaniem etykiet itp.), ale w innych mogą oznaczać obejście uwierzytelniania, zmiana uprawnień lub manipulacja krytycznymi operacjami.
Aby luka w zabezpieczeniach HPP była rzeczywiście możliwa do wykorzystania, mechanizm odczytu parametrów serwera lub struktury musi być zwraca wartość inną niż oczekiwana gdy napotka zduplikowane parametry. Stamtąd atakujący może manipulować tym priorytetem, aby sterować przepływem aplikacji na swoją korzyść.
Jak serwery radzą sobie z duplikatami parametrów
Kluczowym elementem technicznym umożliwiającym HPP jest nierówne zachowanie różnych serwery WWW i języki zaplecza podczas przetwarzania powtarzających się parametrów. Nie wszyscy robią to samo, a właśnie ta różnorodność pozwala atakującym znaleźć luki w zabezpieczeniach.
W niektórych środowiskach, jeśli wyślemy adres URL tego typu zmienna1=wartość1&zmienna1=wartość2serwer będzie przechowywał tylko pierwsza wartość (val1). W innych przypadkach zajmie to ostatnia otrzymana wartość (val2). A w pewnych przypadkach, jak to się dzieje w przypadku pewnych konfiguracji IIS, te dwie wartości są łączyć wewnętrznie w listę, na przykład rozdzielone przecinkami, które aplikacja będzie musiała następnie zinterpretować.
Często cytowanym przykładem jest to, że Apache Domyślnie zachowuje ona zwykle pierwszą wartość parametru i odrzuca kolejne, podczas gdy inne technologie generują Lista CSV (wartości rozdzielone przecinkami) ze wszystkimi wartościami tego zanieczyszczonego parametru. Jeśli aplikacja back-end jest dostosowana tylko do jednego z tych przypadków, niekontrolowane scenariusze mogą powodować nieoczekiwane skutki.
Takie przetwarzanie duplikatów parametrów nie tylko wpływa na logikę widoczną dla użytkownika, ale także wewnętrzne kontrole bezpieczeństwa, walidatory danych wejściowych, procedury uwierzytelniania i autoryzacjiTen sam parametr można sprawdzić w jednym miejscu aplikacji, używając jednej wartości, a w innym użyć go z inną wartością — wszystko w ramach tego samego żądania.
Co więcej, HPP można wykorzystać do wykorzystania wewnętrzne transformacje charakteru co robi sam serwer. Udokumentowano na przykład, jak niektóre serwery zmieniają określone znaki (takie jak znak „]” zastępowany znakiem „_”) podczas przetwarzania, co można wykorzystać do omijanie reguł filtrowania lub oprogramowania sprzętowego WAF na podstawie wyrażeń regularnych.
Konsekwencje i scenariusze eksploatacji elektrowni wodnych
Techniki zanieczyszczenia parametrów HTTP pozwalają na generowanie dość szerokiego zakresu sytuacji ryzyka, zarówno po stronie serwera, jak i klienta. Ich waga zależy od funkcja parametru, którego to dotyczy, i punkt w przepływie aplikacji w którym jest zmieniany.
Do najbardziej znaczących konsekwencji zaobserwowanych w podatnych na ataki aplikacjach należą: nadpisywanie chronionych parametrówAtakujący może dodać więcej niż jedną wartość dla krytycznego parametru i zmusić aplikację do użycia dokładnie tej złośliwej wartości dzięki sposobowi działania priorytetów w danym środowisku.
Powszechne jest również, że HPP pozwala modyfikacja oczekiwanego zachowania aplikacjiNa przykład poprzez zmianę filtrów w wewnętrznych wyszukiwarkach, modyfikację identyfikatorów zasobów, manipulowanie operacjami głosowania lub zmienianie parametrów kontrolujących logikę biznesową (takich jak flagi administracyjne, tryby debugowania lub stany transakcji).
Inną ważną konsekwencją jest unikanie walidacji danych wejściowychJeśli kod walidacji bezpieczeństwa sprawdza pierwsze wystąpienie parametru, ale faktyczna operacja jest wykonywana z późniejszym wystąpieniem, atakujący może ominąć pozornie dobrze zaimplementowane zabezpieczenia. Zaobserwowano to w przypadkach: ominięcie uwierzytelniania i kontroli dostępu.
W bardziej złożonych kontekstach HPP może wywołać wewnętrzne błędy aplikacji, ujawnienie poufnych informacji, dostęp do zmiennych spoza zamierzonego zakresu i nawet wykorzystanie połączonych parametrów, które po ponownym złożeniu tworzą ładunki, których zapora WAF nie wykryła podczas analizy każdego parametru osobno.
Jeśli chodzi o skutki, ataki były obserwowane z obu stron. po stronie serwera (omijanie WAF, zmiana przepisywania adresów URL, wymuszanie innych tras wewnętrznych) strona klienta (wstrzykiwanie parametrów do linków i formularzy w celu oszukania ofiar za pomocą specjalnie zmanipulowanych adresów URL).
Klasyczny przykład HPP w aplikacji do głosowania
Aby lepiej zrozumieć, jak działa atak polegający na zanieczyszczeniu parametrów HTTP, przytoczmy przykład aplikacja internetowa do głosowania napisana w JSPgdzie użytkownicy mogą głosować na swojego ulubionego kandydata w różnych wyborach.
Aplikacja otrzymuje za pomocą parametru o nazwie identyfikator_wyborczy Identyfikator bieżących wyborów. Na podstawie tej wartości serwer generuje stronę z listą dostępnych kandydatów, z których każdy zawiera link umożliwiający oddanie głosu. Metoda Request.getParameter("para") W JSP, gdy dla tego samego parametru występuje wiele wartości, zawsze zwracana jest wartość pierwsza wartość.
Wyobraźmy sobie taki adres URL: http://servidor/eleccion.jsp?eleccion_id=4568Na wyświetlonej stronie znajduje się link umożliwiający głosowanie na każdego kandydata, na przykład:
Łącze 1Głosuję na pana White'a
Łącze 2Głosuję na panią Green
Załóżmy, że złośliwy użytkownik, który popiera konkretnego kandydata, zdaje sobie sprawę, że aplikacja nie pomyślnie weryfikuje parametr choice_idWykorzystując lukę w zabezpieczeniach HPP, decyduje się na wstrzyknięcie parametru kandydat w ramach tego choice_id, kodując ograniczniki ciągu zapytania.
Utworzony adres URL może wyglądać następująco: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3DgreenNależy pamiętać, że atakujący zakodował symbol & jako %26, a znak = jako %3D, dzięki czemu po zdekodowaniu stają się one nowym parametrem kandydata osadzonym w wartości election_id.
Kiedy ofiara klika na ten zmanipulowany adres URL, pozornie uzyskuje dostęp do właściwych wyborów. Jednak ponieważ aplikacja używa wartości election_id do konstruowania linków do głosowania, dekoduje wstrzykniętą wartość... W rezultacie w ciągu zapytania zostaje uwzględniony dodatkowy kandydat.
W rezultacie generowane wewnętrznie linki wyglądają mniej więcej tak:
Łącze 1Głosuję na pana White'a
Łącze 2Głosuję na panią Green
Nie ma znaczenia, w który z dwóch linków kliknie ofiara: skrypt vote.jsp zawsze otrzymuje dwa wystąpienia parametru candidatesgdzie pierwsza wartość jest zielona. Ponieważ programista używa standardowej funkcjonalności Javy do uzyskania pojedynczej wartości, pobiera tylko pierwszą wartość z parametru „kandydat” i odrzuca drugą, która reprezentowałaby rzeczywisty głos użytkownika.
Dzięki takiemu zachowaniu luka w zabezpieczeniach HPP umożliwia atakującemu zmusić wszystkie głosy oddane na tej stronie do oddania głosu na ich kandydataniezależnie od wyborów ofiary w interfejsie. To bardzo wyraźny przykład tego, jak rzekomo „proste” zarządzanie parametrami może mieć bezpośredni wpływ na integralność danych i logika biznesowa.
Ominięcie uwierzytelniania: przypadek Bloggera
Jednym z najbardziej znanych przykładów wykorzystania zanieczyszczenia parametrów HTTP był system blogowy BloggerLuka w zabezpieczeniach obsługi parametrów umożliwiła atakującym uzyskanie dostępu do zostać administratorami blogów innych osóbpo prostu manipulując parametrami żądania POST.
Problematyczne żądanie wyglądało mniej więcej tak (uproszczając składnię):
POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Zaproś
Problem leżał w tym, że mechanizm uwierzytelniania i weryfikacji bezpieczeństwa Właśnie patrzyłem na pierwszy parametr blogID który dotarł w żądaniu, weryfikując, czy użytkownik ma uprawnienia do tego bloga. Jednak faktyczna operacja, którą dodał autor gościnny, została wykonana przy użyciu drugie wystąpienie blogID, co odpowiadało blogowi ofiary.
Dzięki tej wewnętrznej sprzeczności sposób, w jaki serwer sobie z tym poradził, duplikaty parametrówAtakujący zdołał przejść kontrolę bezpieczeństwa na swoim blogu, ale wykonał akcję na innym blogu. W rezultacie całkowite ominięcie uwierzytelniania z jedną, dobrze skonstruowaną prośbą.
Przypadek ten doskonale pokazuje, że HPP to nie tylko „ciekawostka techniczna”, ale technika, rzeczywisty wpływ na systemy dużych dostawcówPonadto podkreśla znaczenie kontroli bezpieczeństwa i wykonywania operacji przy użyciu dokładnie takich samych wartości parametrów, bez polegania na niekontrolowanych pierwszeństwach.
HPP i zapora aplikacji internetowych (WAF)
Wiele organizacji korzysta z WAF-u jako dodatkowej warstwy chroniącej ich aplikacje internetowe przed znanymi atakami. Te zapory sieciowe zazwyczaj opierają się na reguły i podpisy (wyrażenia regularne) które są stosowane do parametrów, nagłówków i nawet treści żądań HTTP.
Problem polega na tym, że w przypadku występowania zduplikowanych parametrów atakujący może fragmentacja złośliwego ładunku na kilka wartości tego samego parametruChociaż WAF analizuje każdy parametr osobno, istnieje możliwość, że żadna z izolowanych wartości nie będzie odpowiadała sygnaturom ataku, w związku z czym żądanie przejdzie przez filtry bez zablokowania.
Gdy żądanie dotrze do serwera WWW, modułu aplikacji lub samego serwera ponownie składa wartości zgodnie ze swoją wewnętrzną logiką (na przykład łącząc je przecinkami lub biorąc ostatni), co skutkuje ciągiem znaków, który jako całość stanowi atak. W ten sposób ta sama technika zanieczyszczenia parametrów pozwala ominąć zapory sieciowe WAF, które nie są wyposażone w funkcję analizy połączonego zestawu wartości.
Ponadto niektóre zapory sieciowe WAF nie działają jako odwrotny serwer proxy A te, które nie mają pełnego obrazu przepływu między klientem a serwerem, a działają raczej jako filtry punktowe, mogą być szczególnie podatne na te obejścia HPP. Te oparte na technologiach takich jak Apache z modułem oceny parametrów i analizy statystycznej Zwykle zachowują się lepiej, gdy są poddawane tego typu technikom.
Krótko mówiąc, HPP pokazuje, że nawet przy prawidłowo skonfigurowanej zaporze WAF, Bezpieczeństwo nie jest gwarantowane Jeśli logika aplikacji i serwera nieprawidłowo obsługuje zduplikowane parametry, ochrona musi być kompleksowa i uwzględniać sposób przetwarzania żądań na wszystkich poziomach.
Prawdziwe przypadki, narzędzia i rozpowszechnienie HPP
Badania naukowe i prace ekspertów ds. bezpieczeństwa wykazały, że zanieczyszczenie parametrów HTTP nie jest rzadkie. Projekty takie jak PAPAS (System Analizy Zanieczyszczeń Parametrów), kierowane przez badaczy takich jak Carmen Torrano, zostały zaprojektowane właśnie po to, automatycznie wykrywa luki w zabezpieczeniach HPP w aplikacjach internetowych na dużą skalę.
W eksperymentach przeprowadzonych na ponad 5000 bardzo popularnych stron internetowych (według rankingów takich jak Alexa) zaobserwowano, że prawie 30% analizowanych witryn Zawierały one co najmniej jedną stronę podatną na atak HPP. Oznacza to, że możliwe było wstrzyknięcie zakodowanego parametru do innego, istniejącego parametru i sprawdzenie, czy został on zdekodowany w jakimś wynikowym adresie URL lub formularzu.
Jeszcze bardziej uderzające jest to, że w pobliżu 47% wykrytych luk (co stanowi około 14% wszystkich witryn) były naprawdę nadający się do wykorzystaniaumożliwiając ataki wykraczające poza proste błędy w prezentacji. Wśród dotkniętych stron znalazły się Wielkie nazwiska, takie jak Microsoft czy GoogleTo wyraźnie pokazuje, że nawet giganci technologiczni nie są wolni od tych problemów.
Narzędzia takie jak PAPA Posłużyły one do analizy i ilościowego określenia problemu, ale także podkreśliły trudności automatycznie wykrywa HPPWiele tradycyjnych skanerów podatności sieci nie bierze pod uwagę scenariuszy z duplikacją parametrów lub generuje bardzo dużą liczbę fałszywych wyników pozytywnych.
Oprócz rozwiązań specyficznych, takich jak POTATOES, istnieją rozszerzenia, takie jak HPP Finder dla przeglądarki Google ChromeNarzędzia te zostały zaprojektowane do wykrywania potencjalnych wektorów ataku HPP w adresach URL i formularzach HTML. Chociaż mogą pomóc w identyfikacji podejrzanych punktów (na przykład formularzy, które ponownie wykorzystują parametry bez odpowiedniej walidacji), nie stanowią one… nie jest to kompletne rozwiązanie ani substytut dogłębnego audytu bezpieczeństwa.
Innym narzędziem powszechnie stosowanym w ekosystemie testów bezpieczeństwa jest OWASP ZAPZawiera rozszerzenia i skrypty do testowania różnych wektorów, w tym tych związanych z parametrami w ciągu zapytania. Jednak w konkretnym przypadku HPP nadal konieczne jest połączenie zautomatyzowanych narzędzi z ręczna analiza i zrozumienie przepływu aplikacji.
HPP w wewnętrznych wyszukiwarkach i przykładach takich jak Apple.com
HPP obserwowano nie tylko w systemach zarządzania blogami lub panelach administracyjnych, pojawiają się one również w pozornie niegroźne funkcje, takie jak wyszukiwarki tagów na forach internetowych i w społecznościach. Uderzający przykład znaleziono w Fora Apple, gdzie zarządzanie zanieczyszczonymi etykietami i parametrami wykazało ciekawe zachowania.
Na tych forach wybranie tagu w interfejsie dodało parametr tagi Ciąg zapytania w adresie URL otrzymywał wartość wybranego tagu. Aplikacja zaplecza pobierała tę wartość, wyszukiwała tematy z tym tagiem i wyświetlała wyniki użytkownikowi. W przypadku wybrania wielu tagów, dodawane były wszystkie. w tym samym parametrze tagów, rozdzielone operatorem dodawania (+)więc zaplecze było gotowe do przetworzenia tej listy.
Gdy parametr tagów został zanieczyszczony kilkoma zduplikowanymi wartościami, zaobserwowano, że technologia zaplecza wygenerowała lista rozdzielona przecinkami (CSV) ze wszystkimi zanieczyszczonymi wartościami parametrów. Aplikacja była w stanie częściowo przetworzyć tę listę (odkryć różne tagi), ale Nie wszystkie etykiety zostały wydrukowane prawidłowo. w polu tekstowym wyszukiwarki.
W tym konkretnym kontekście nie wydawało się, aby istniała luka w zabezpieczeniach, którą można wykorzystać, ale było jasne, że Były scenariusze, których twórcy nie wzięli pod uwagęW innych, mniej nieszkodliwych zastosowaniach podobne zachowanie może prowadzić do rozbieżności między tym, co jest sprawdzane, co jest używane i co jest pokazywane użytkownikowi, z poważniejszymi konsekwencjami.
Analiza technologii bazowych na forach takich jak Apple (na przykład Apache z J2EE w zapleczu) pokazuje, że wiele nowoczesnych stosów zachowuje się podobnie do serwerów takich jak IIS lub kombinacji takich jak Apache z Pythonem podczas obsługi zanieczyszczonych parametrów, generując listy rozdzielone przecinkami i delegując ostateczne przetwarzanie tych wartości do logiki aplikacji.
Tego typu przykłady służą jako przypomnienie, że W normalnych przypadkach nie wystarczy, że „pozornie działa”.:Musisz systematycznie testować, jak aplikacja reaguje, gdy wysyłane są jej zduplikowane parametry, dziwnie zakodowane wartości, nietypowe kombinacje itp., ponieważ właśnie w tym obszarze HPP znajduje swoją niszę.
Wykrywanie i łagodzenie zanieczyszczeń parametrów HTTP
Wykrywanie i łagodzenie skutków HPP wymaga podejścia hybrydowego, które łączy dobre praktyki bezpiecznego rozwoju, prawidłowa konfiguracja serwera i korzystanie ze specjalistycznych narzędziNie wystarczy polegać na WAF, że wszystko naprawi, bo jak widzieliśmy, często to właśnie ta warstwa może zostać oszukana.
Z perspektywy rozwoju istotne jest, aby programiści Należy pamiętać, że parametr może mieć wiele wartości i muszą wyraźnie zdecydować, jak postąpić w takim przypadku. Nie powinni polegać na domyślnym języku ani zachowaniach frameworka bez dogłębnego zrozumienia, jak działa priorytet wartości.
Zaleca się również, aby w punktach krytycznych, takich jak: uwierzytelnianie, autoryzacja, operacje wrażliwe lub ważne zmiany stanuŚciśle przestrzegane jest, aby parametry pojawiały się tylko raz, odrzucane są żądania zawierające zduplikowane parametry lub przynajmniej są one rejestrowane w celu analizy.
W zakresie infrastruktury wskazane jest dokonanie przeglądu konfiguracje serwera WWW i frameworka Aby dokładnie zrozumieć, co dzieje się po otrzymaniu powtarzającego się parametru: czy zachowany zostanie pierwszy, ostatni, czy wszystkie połączone. Na tej podstawie można dostosować logikę aplikacji, aby uniknąć rozbieżności między walidacją a faktycznym wykorzystaniem wartości.
Jeśli chodzi o narzędzia, oprócz standardowych skanerów podatności, przydatne jest włączenie rozwiązań ukierunkowanych, takich jak: PAPA lub typu rozszerzeń Wyszukiwarka HPP w przepływie testów. Jeśli używany jest OWASP ZAP lub inne narzędzia do testów penetracyjnych, warto zaprojektować konkretne skrypty, które generują żądania z duplikatami parametrów i wartościami zakodowanymi w różny sposób aby zaobserwować reakcję aplikacji.
Na koniec należy podkreślić, że HPP stanowi problem znacznie bardziej rozpowszechnione niż się powszechnie uważaJest to szczególnie istotne w przypadku dużych aplikacji, które ewoluowały przez wiele lat. Połączenie szkolenia, przeglądu kodu, testów automatycznych i dobrze zaprojektowanych testów manualnych to najlepszy sposób na utrzymanie tych błędów pod kontrolą.
Zanieczyszczenie parametrów HTTP słusznie zyskało miejsce wśród technik ataków internetowych, które każdy zespół ds. rozwoju i bezpieczeństwa powinien mieć na oku: Jest to zjawisko dyskretne, trudne do zauważenia na pierwszy rzut oka, a jego konsekwencje mogą być bardzo poważne. Jeśli wpływa to na kluczowe parametry logiki biznesowej lub kontroli bezpieczeństwa. Zrozumienie, jak obsługiwane są zduplikowane parametry w stosie, i aktywne testowanie tych scenariuszy to jedno z zadań, które na pierwszy rzut oka mogą wydawać się nieco żmudne, ale to właśnie one decydują o różnicy między aplikacją czysto funkcjonalną a taką, która jest naprawdę odporna na zaawansowane ataki.
Pisarz z pasją zajmujący się światem bajtów i technologii w ogóle. Uwielbiam dzielić się swoją wiedzą poprzez pisanie i właśnie to będę robić na tym blogu, pokazywać Ci wszystkie najciekawsze rzeczy o gadżetach, oprogramowaniu, sprzęcie, trendach technologicznych i nie tylko. Moim celem jest pomóc Ci poruszać się po cyfrowym świecie w prosty i zabawny sposób.

