A Highly Concise Introduction to Security Headers in the HTTP Protocol
In his latest video, Jakub 'unknow' Mrugalski discusses how web security can be enhanced with the help of web browsers. Throughout the material, he addresses issues related to XSS attacks, which involve injecting malicious code, such as JavaScript, into websites. He explains that there are different types of these attacks including controlled, reflected, and zero attacks. In this context, he emphasizes how it's possible to inform the browser not to execute suspicious scripts, thus providing some support for web application security.
The video introduces practical methods for enhancing security. For example, Jakub demonstrates ways to prevent unauthorized placement of a site in an iframe by attackers. Through appropriate headers, browsers can be instructed not to accept such actions. He also adds that if an XSS attack is detected, one can create a whitelist of elements and domains from which the site is allowed to derive content, greatly reducing the risk to users.
Another valuable point he raises is the handling of HTTP headers, particularly regarding redirects from HTTP to HTTPS. Jakub highlights the importance of permanent redirections via 301 and 302 headers and presents a method to prevent users from returning to the unsecured version of the site. He mentions that one can also instruct browsers to remember that the HTTP version no longer exists.
Concerning cookies, Jakub draws attention to how they can be managed to ensure their security. He explains that cookies can be transmitted only over secure connections, which is an essential step in protecting user data. The mentioned XSS attacks can also lead to cookie theft, making it crucial to restrict access from JavaScript.
Lastly, Jakub summarizes that the delivery of referer and other information from the domain to potential threats can also be regulated through the browser. With various mechanical requirements, browsers can significantly enhance user security. At the time of writing this article, the video has garnered 8771 views and 821 likes, indicating its popularity and usefulness to the security community.
Toggle timeline summary
-
Introduction to web security and the concept of offloading security responsibilities to the user's browser.
-
Discussion about XSS attacks where malicious code is injected into a website.
-
Identification of three types of XSS attacks: stored, reflected, and DOM.
-
Instructions for browsers to avoid executing suspicious scripts from external sources.
-
Explanation of how a page can be compromised through an iframe leading to a hacker's server.
-
Consequences of users inadvertently interacting with compromised content.
-
Recommendations on how to instruct browsers to avoid being embedded in iframes.
-
Mention of the risks associated with vulnerabilities discovered on one's own site.
-
Importance of using whitelists for acceptable content sources.
-
Exploration of handling HTTP vs. HTTPS versions of a website.
-
Redirecting users from HTTP to HTTPS versions with HTTP headers.
-
Ensuring users do not revert to unsecured versions of a site.
-
Risks of cookies being sent over insecure connections.
-
Advice for cookies to be transferred only over secure connections.
-
Concerns about XSS potentially allowing cookie theft.
-
Description of security precautions for confidential systems.
-
Impacts of links in tickets leading to exposure of confidential information.
-
Instruction to browsers to avoid sending referrer information to external sites.
-
Encouraging understanding of browser security features and their settings.
-
Conclusion and thanks for attention, with a note on the source of the subtitles.
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