Skrajnie krótkie wprowadzenie do nagłówków bezpieczeństwa w protokole HTTP
Jakub 'unknow' Mrugalski w swoim najnowszym wideo omawia jak zabezpieczenia internetowe mogą być wykorzystane z pomocą przeglądarek internetowych. W trakcie tego materiału porusza kwestie związane z atakami typu XSS, które polegają na wstrzykiwaniu złośliwego kodu, takiego jak JavaScript, do stron internetowych. Opisuje, że istnieją różne rodzaje tych ataków, w tym atak sterowany, odbity oraz zerowy. W kontekście tego zagadnienia zwraca uwagę na to, jak można poinformować przeglądarkę, aby nie wykonywała podejrzanych skryptów, co daje pewne wsparcie w zabezpieczeniach aplikacji webowych.
Wideo wprowadza do praktycznych sposobów na rzecz zabezpieczeń. Na przykład, Jakub przedstawia metody zapobiegania umieszczania strony w iframe'ie przez atakujących. Dzięki odpowiednim nagłówkom, przeglądarki mogą zostać poinstruowane, aby nie akceptowały takich działań. Do tego dodaje, że w przypadku wykrycia ataku XSS, można stworzyć białą listę elementów i domen, z których strona może czerpać zawartość, co znacznie zmniejsza ryzyko narażenia użytkowników.
Kolejnym cennym punktem, który porusza, jest zarządzanie członkiem HTTP, zwłaszcza w kontekście przekierowań z wersji HTTP do HTTPS. Jakub podkreśla znaczenie trwałych przekierowań nagłówków 301 oraz 302 i przedstawia sposób, aby zapobiec powrotom na niezabezpieczoną wersję strony. Wspomina, że można również nakazać przeglądarkom zapamiętywanie, że wersja HTTP już nie istnieje.
W kontekście ciasteczek (cookies) Jakub zwraca uwagę na to, jak można je zarządzać, aby zapewnić ich bezpieczeństwo. Objaśnia, że cookies mogą być przekazywane tylko w szyfrowanych połączeniach, co jest istotnym krokiem w kierunku zabezpieczenia danych użytkowników. Wspomniane ataki XSS mogą również prowadzić do kradzieży ciasteczek, co sprawia, że istotne jest ograniczenie dostępu do nich z poziomu JavaScript.
Na koniec Jakub podsumowuje, że przekazywanie referera i innych informacji z domenu do potencjalnych zagrożeń także może być regulowane za pośrednictwem przeglądarki. Dzięki różnym mechanicznym wymogom, przeglądarki mogą znacznie zwiększyć bezpieczeństwo użytkowników. W momencie pisania tego artykułu wideo zdobyło 8771 wyświetleń oraz 821 polubień, co świadczy o jego popularności i przydatności dla społeczności zajmującej się bezpieczeństwem w sieci.
Toggle timeline summary
-
Wprowadzenie do bezpieczeństwa w sieci oraz koncepcji przenoszenia odpowiedzialności za bezpieczeństwo na przeglądarkę użytkownika.
-
Dyskusja na temat ataków XSS, gdzie złośliwy kod jest wstrzykiwany na stronę internetową.
-
Identyfikacja trzech typów ataków XSS: przechowywane, odzwierciedlone i DOM.
-
Instrukcje dla przeglądarek dotyczące unikania wykonywania podejrzanych skryptów z zewnętrznych źródeł.
-
Wyjaśnienie, jak strona może zostać skompromitowana poprzez iframe prowadzące do serwera hakera.
-
Konsekwencje przypadkowego interakcji użytkowników z skompromitowanym kontentem.
-
Zalecenia dotyczące tego, jak instruować przeglądarki, aby unikały osadzania w iframe.
-
Wzmianka o ryzykach związanych z lukami odkrytymi na własnej stronie.
-
Znaczenie stosowania białych list dla akceptowalnych źródeł treści.
-
Badanie różnych wersji HTTP i HTTPS strony internetowej.
-
Przekierowywanie użytkowników z wersji HTTP do HTTPS z wykorzystaniem nagłówków HTTP.
-
Zapewnienie, że użytkownicy nie wracają do niezabezpieczonych wersji strony.
-
Ryzyko przesyłania ciasteczek przez niezabezpieczone połączenia.
-
Porady dotyczące przesyłania ciasteczek tylko przez bezpieczne połączenia.
-
Obawy dotyczące XSS, które mogą potencjalnie umożliwić kradzież ciasteczek.
-
Opis środków ostrożności dotyczących systemów poufnych.
-
Wpływ linków w biletach prowadzących do ujawnienia informacji poufnych.
-
Instrukcja dla przeglądarek, aby unikały wysyłania informacji o odsyłaczach do zewnętrznych stron.
-
Zachęcanie do zrozumienia funkcji zabezpieczeń przeglądarki i ich ustawień.
-
Podsumowanie i podziękowanie za uwagę, z notatką o źródle napisów.
Transcription
Nie wiem czy wiesz, ale w świecie security webowego część bezpieczeństwa możesz przerzucić na kogoś innego, konkretnie na przeglądarkę internetową użytkownika. Tak, możesz się z nim dogadać i powiedzieć na jakich zasadach będzie z tobą współpracować. Przykładowo, mamy ataki typu XSS, czyli ktoś wstrzykuje fragment kodu, na przykład JavaScript do twojej strony i ten kod się wykonuje. Rozróżniamy co najmniej trzy rodzaje tego ataku. Atak sterowany, atak odbity i atak zerowy, czasami domowy się to nazywa. No i teraz możesz powiedzieć przeglądarce, droga przeglądarko, jeśli dostaniesz z zewnątrz jakieś dane, które wyglądają plus minus jak skrypt wykonywalny, to weź to proszę nie wykonuj, okej? Inna rzecz, może się zdarzyć, że ktoś twoją stronę, załóżmy stronę z konkursem, wróci do środka iframe'a, czyli pływającej ramki, a następnie tę pływającą ramkę umieści na hakerskim serwerze. Co się wtedy stanie? Ktoś, kto wejdzie na hakerski serwer, jeżeli ta pływająca ramka będzie tam umieszczona, a następnie będzie miała dostatecznie dużą przeźroczystość, może się okazać, że człowiek klikający po tym serwisie, przypadkiem klika też po Twojej stronie, oddaje głosy na przykład w Twoim konkursie. Jak się zabezpieczyć? Możesz powiedzieć przeglądarce, przeglądarko. Ja nie zgadzam się, aby wsadzać mnie do ramek. Inna rzecz, czasami zdarza się tak, że ktoś znajdzie dziurę typu XSS u Ciebie na stronie i dzięki temu umieści jakiś skrypt złośliwy, javascriptu. Inna rzecz, umieści jakiś nieprzyzwoity obrazek. Możesz powiedzieć przeglądarce, przeglądarko. Ja mam białą listę elementów, z których mogę składać moja strona, białą listę też domen, z których mogą one pochodzić i tylko z nich życzę sobie zaciągać content. Inna rzecz, czasami zdarza się tak, że mamy na przykład dwie wersje strony. Wersja szyfrowana po HTTPS i rozszyfrowana po HTTP. No i teraz co z nimi robimy? Naturalne. Jak ktoś wejdzie na HTTP, to jest natychmiast odbijany na wersję szyfrowaną za pomocą nagłówka 301, 302, jak kto lubi. Ale, co zrobić, żeby ten człowiek nigdy nie wrócił na wersję rozszyfrowaną? Da się to zrobić jednym prostym nagłówkiem HTTP. Można powiedzieć przeglądarce, przeglądarko. Zapamiętaj, wersja rozszyfrowana nie istnieje i nigdy na nią nie zaglądaj. Inna rzecz, czasami zdarza się tak, że ktoś wejdzie na tą stronę rozszyfrowaną i bez żadnego szyfrowania polecą wszystkie ciastka, jakie on tylko miał, łącznie z tymi ciastkami, które zostały ustanowione w szyfrowanym połączeniu. Jak to zrobić? Wystarczy poprosić przeglądarkę. Powiedzieć przeglądarce, przeglądarko, daję Ci ciastko, ale to ciastko ma być przekazywane tylko w szyfrowanych połączeniach. Inna rzecz, może się zdarzyć, że ktoś za pomocą ataku XSS będzie chciał ukraść ciastko. Co możesz zrobić? Poprosić przeglądarkę. Przeglądarko, daję Ci ciastko, ale proszę Cię, nie daj tego ciastka Javascriptowi. Jeżeli Javascript go nie będzie widział, to nie będzie dało się go ukraść. Proste. Inna rzecz, czasami jest tak, że pracujemy w tajnych systemach. Na przykład mamy system tiketowy na super tajnym domenie. Nikt nie powinien się dowiedzieć, gdzie ona jest. Tylko nagle haker wysyła tiketa do tego systemu. I on pojawia się w środku. W środku tego tiketa jest link do hakerskiej strony. Jeden z operatorów systemu klika w tego linka. I co się teraz dzieje? Referer, czyli pasek adresu, domena i inne takie rzeczy przekazywane są do hakera i tajna lokalizacja nie jest już tajna. Można powiedzieć przeglądarce przeglądarką? Proszę Cię, nie przekazuj referera na zewnątrz. Zwróć uwagę, o ile rzeczy możesz poprościć przeglądarkę. Wystarczy tylko przeczytać sobie, do czego te wszystkie przełączniki, które ja omówiłem, służą. Zerknij na te wyskakujące boksy, które się pojawiały i doczytaj sobie o tym. Dzięki za uwagę. Unknown. Napisy stworzone przez społeczność Amara.org