Szeroka Perspektywa Full-Stack Web Developmentu: Zabezpieczenia CSRF

0:00Bezpieczeństwo aplikacji webowych to bez

0:02wątpienia bardzo istotny i jednocześnie rozległy temat.

0:05Z tego powodu nie jesteśmy w stanie pokryć

0:07go całkowicie, ale mam nadzieję, że widzisz to jak na przestrzeni wszystkich

0:10lekcji i opracowanych przeze mnie materiałów.

0:12Staram się przynajmniej zwracać uwagę na

0:15pewne obszary, o których po prostu trzeba pamiętać.

0:18Najciekawsze w tym wszystkim jest to, że te najczęstsze problemy dotyczące błędów

0:21security wynikają nie tyle ze skomplikowanych rodzajów ataków, tylko po

0:25prostu z ludzkiej pomyłki bądź w wyniku zaniedbania.

0:28Mowa tutaj np.

0:30o niezabezpieczonych ścieżkach, bądź też

0:32nie ustawianiu odpowiednich limitów dla wprowadzanych przez użytkownika pól.

0:35O tym wszystkim już do tej pory mówiliśmy.

0:38Natomiast istnieje jeszcze rodzaj ataków,

0:40które można przeprowadzić w sposób celowy, a dodatkowo w tym wszystkim trzeba

0:44wykorzystać mniej lub bardziej złożone techniki ataku.

0:47Mam tutaj na myśli przede wszystkim ataki typu C, strefy oraz XSS.

0:51Jeżeli chodzi o ten pierwszy, to mowa tutaj o sytuacji, w której użytkownik jest

0:55w jakiś sposób zmuszony bądź bardziej zachęcony jakimś podstępem do tego, aby

0:59podjąć działanie, którego efektem z kolei jest wykonanie jakiejś niepożądanej akcji.

1:04Przykładem może być zachęcenie użytkownika

1:06do tego, aby przeszedł do konkretnej strony i tym samym nieświadomie wykonał

1:11operację, którą normalnie musiałby wykonać np.

1:13za pomocą formularza.

1:14Tutaj akurat w tym przypadku mówimy o kliknięciu w link.

1:18Natomiast jak pewnie wiesz, przykładowo obrazki pobierane są również z pomocą

1:22zapytania typu GET, do którego można przekazać parametry.

1:25Oznacza to, że użytkownik często nawet nie musi w nic klikać, tylko po prostu przejść

1:30na stronę, na której pozornie wyświetli się jakiś obrazek.

1:33Natomiast pod parametr Cel zostanie

1:35podstawiony taki oto link, który pozwoli nie doprowadzić do tej niepożądanej akcji.

1:39Tego rodzaju ataki działają również w

1:41sytuacji, gdy mamy do czynienia z zapytaniami typu post.

1:44Po prostu wtedy użytkownik zostaje

1:46przekierowany do strony, w której faktycznie osadzony jest jakiś formularz,

1:50który wysyłany jest z pomocą prostego kodu JavaScript.

1:53Na koniec dnia zatem chodzi tutaj wyłącznie o to, aby w jakiś sposób

1:57doprowadzić do sytuacji, w której użytkownik podejmie jakieś działanie,

2:00które uruchomi akcję przygotowaną w taki sposób, jak gdyby wykonał ją samodzielnie.

2:05Z tą różnicą, że w tym przypadku np.

2:07parametry podstawione są w sposób, którego nie spodziewa się użytkownik.

2:11I tutaj, jeżeli chodzi o zabezpieczenie się przed tego rodzajem ataków jest

2:15wykorzystanie autoryzacji opartej o local storage bądź session storage.

2:20W takiej sytuacji, nawet jeżeli użytkownik przypadkowo wczyta obrazek z podstawionym

2:24w ten sposób linkiem, to w żaden sposób nie wykona się tutaj kod JavaScript, który

2:28będzie odpowiedzialny za to, aby dołączyć odpowiednie informacje np.

2:32token j wt, który znajduje się chociażby w Local Storage.

2:36Zatem pierwszym sposobem przeciwdziałania

2:38atakom CSS jest po prostu uwierzytelnienie naszego połączenia za pomocą danych

2:42przekazywanych w formie nagłówka za pomocą JavaScriptu.

2:46Drugim sposobem jest też wykorzystanie ciasteczek, które również z pomocą

2:49JavaScriptu przekazywane są w celu uwierzytelnienia połączenia.

2:53Takie ciasteczko w przypadku REST API oczywiście nie może być klasyczną sesją,

2:57która jest przechowywana po stronie serwera.

2:59Ze względu na to, że wtedy naruszamy jedną z fundamentalnych zasad, to jest.

3:03Czyli oczywiście Styles.

3:04Teoretycznie więc okazuje się, że najlepszym sposobem zabezpieczenia się

3:08przed atakami CSS jest wykorzystanie sposobów uwierzytelnienia np.

3:12Jamesa Web Token, które po prostu zostają

3:15za każdym razem przez JavaScript dołączane do naszego zapytania.

3:19W takiej sytuacji przeglądarka nie jest w stanie tego samodzielnie zrobić i tym

3:23samym ataki takie jak wejście na ten link nie będą tutaj skuteczne.

3:27Jednocześnie, jak być może już wiesz, w momencie, gdy mamy do czynienia z

3:30aplikacją, która wykorzystuje sesję, informacja o niej dołączana jest

3:34automatycznie przez przeglądarkę do każdego zapytania.

3:37Podobnie zresztą dzieje się w momencie, gdy przekazujemy token jw

3:41z pomocą ciasteczka, które ma włączone flagę http only.

3:45Oznacza to, że w obu tych przypadkach jesteśmy narażeni na ten rodzaj ataków.

3:50I teraz przykładowo jeżeli przejdziemy

3:51sobie do dokumentacji frameworka Laravel, w przypadku którego

3:55zwykle domyślnie wykorzystywane są sesje do tego, aby uwierzytelnić połączenie.

4:00I z tego powodu ten framework domyślnie wykorzystuje tzw.

4:03tokeny CSS, które zabezpieczają przed tego rodzaju atakiem.

4:07Taki token należy dołączyć np.

4:09do meta tagu bądź bezpośrednio do formularza, który jest osadzane w widoku.

4:14W zależności od potrzeby taki token albo

4:16trafia właśnie do formularza w formie ukrytego pola, które wysyłany jest na

4:20serwer lub też ewentualnie tak jak w tym przykładzie, token odczytywany jest z tagu

4:25meta, a jego zawartość przesyłana jest razem z nagłówkiem.

4:28Oznacza to, że nawet jeżeli mamy tutaj z

4:30sytuacją, w której użytkownik wchodzi na stronę, która próbuje wykonać takie oto

4:35zapytanie, to w takim przypadku token, o którym mówimy tutaj nie jest dostępny i

4:39tym samym próba wykonania tego zapytania nie powiedzie się.

4:43Dodatkowo oczywiście taki token może teoretycznie zostać wykradzione i z tego

4:47powodu on również posiada datę wygaśnięcia.

4:50W ten sposób jesteśmy zabezpieczeni na ten rodzaj ataków.

4:53Jednocześnie nawet przygotowując się do tego materiału, zastanawiałem się, czy

4:57jest sens wykorzystywać ten token w przypadku.

5:00REST API, gdzie wykorzystujemy i ciasteczko z flagą http only.

5:04Okazuje się, że zdania są w tym temacie mocno podzielone.

5:08Jedni mówią, że w takim przypadku istnieje

5:10taka potrzeba, a drudzy wręcz przeciwnie mówią, że jest to całkowicie nie wymagane.

5:14Jak dokładnie jest? Niestety dość trudno mi odpowiedzieć.

5:18Jednocześnie w tym wszystkim trafiłem na

5:20świetną stronę, na której możemy poczytać sobie między innymi o tego rodzaju atakach

5:24oraz sposobach zabezpieczania się przed nimi.

5:27W skrócie okazuje się, że w przypadku REST

5:29API warto wykorzystać przechowywanie tokena właśnie w Local Storage i tym samym

5:34narazić się na ataki typu XSS, o których powiemy za chwilę, ale jednocześnie

5:38zabezpieczyć się na ewentualność ich wystąpienia.

5:41Z drugiej jednak strony spotkałem się z

5:43komentarzami takimi jak ten, które mówią jasno o tym, że w przypadku jw.

5:47Należy wykorzystać bezpieczne połączenie

5:49HTTPS oraz dodatkowo przekazywać ten token właśnie w formie niedostępnej z poziomu

5:54JavaScriptu, czyli za pomocą ciasteczka HTTP z dodatkową flagą Secure.

5:59Mało tego, należy tutaj dodać

6:01uwzględnienie zabezpieczenia kod, o którym mówiliśmy w jednej z poprzednich lekcji.

6:06Zatem pamiętaj proszę o tym, aby w

6:08momencie gdy konfigurujesz swój serwer wykorzystać np.

6:11middleware Helmet do tego, aby

6:13automatycznie dodać zestaw wymaganych nagłówków w kontekście security, no i

6:17oczywiście poprawnie skonfigurować kod tak aby nie doszło do sytuacji, w której można

6:22wykonać zapytanie do naszej aplikacji z poziomu jakiejś zewnętrznej domeny.

6:26Jednocześnie pamiętaj proszę o tym, że w

6:27niektórych przypadkach chcemy doprowadzić do sytuacji, w której zewnętrzna domena

6:32będzie musiała kontaktować się z naszą aplikacją.

6:34W związku z tym, jak widzisz odpowiedź na pytanie w jaki sposób przechowywać tokeny

6:39czy też w ogóle uwierzytelnić połączenie, bynajmniej nie jest tutaj oczywista.

6:43I uwierz mi, że pomimo tego, że spędziłem kilka dni nad tym, aby dotrzeć do różnych

6:47materiałów, które pozwoliłyby mi jasno odpowiedzieć na to, który sposób należy

6:51wybrać, w jakiej sytuacji tak naprawdę sytuacja jest tutaj zbyt skomplikowana.

6:56Ale jednocześnie na koniec tej lekcji

6:57podzielę się z Tobą moimi wnioskami, opartymi również o moje doświadczenie.

7:02Tymczasem przejdźmy do drugiego rodzaju ataku, jakim jest XSS, czyli jakiś sposób

7:06na wykonanie złośliwego kodu, którego stroną może być np.

7:10wykradzenie tokenu uwierzytelniające.

7:12Przykładowo, jeżeli w ramach Local

7:14Strategy bądź Session Storage przechowujemy Flash token, taki kod może

7:18doprowadzić do sytuacji, w której ten token zostanie przesłany do atakującego.

7:23Dzięki temu on będzie mógł wykorzystać ten

7:25token, a następnie działać jak normalnie zalogowany użytkownik.

7:29Podobnie jak w przypadku poprzedniego

7:31ataku, mówimy tutaj o sytuacji, w której użytkownik najczęściej jakimś podstępem

7:35zachęcany jest do tego, aby kliknąć w stronę, która zawiera zmodyfikowany kod,

7:39który w tym przypadku wykonuje jakieś złośliwe działanie.

7:42No i tutaj w tej sytuacji zabezpieczeniem się przed tego rodzajem ataków jest np.

7:47wykorzystanie tego http only kuki, czyli

7:50takiego, które nie jest dostępne z poziomu kodu JavaScript, bądź też ewentualnie

7:54sesji, w przypadku których również możemy zabezpieczyć się na taki rodzaj ataków.

7:58Jednocześnie wybierając ten sposób, jak pamiętasz, narażamy się na ataki CSS,

8:03przed którymi również musimy się zabezpieczyć.

8:05Zasadniczo jednak, jeżeli chodzi o ataki

8:07dotyczące złośliwych skryptów, należy przede wszystkim upewnić się, że nie ufamy

8:12użytkownikowi, który wprowadza jakiekolwiek dane do naszej aplikacji.

8:16Czyli tak jak już powtarzałem

8:17wielokrotnie, za każdym razem upewniamy się, że przykładowo użytkownik może

8:22przesłać wyłącznie dane, których się spodziewamy i dodatkowo zweryfikujemy ich

8:26typ oraz na rzucimy różnego rodzaju ograniczenia, np.

8:29dotyczące długości.

8:31W ten sposób minimalizujemy ryzyko tego,

8:33że złośliwy skrypt faktycznie wykona się z powodzeniem.

8:36Dodatkowo mamy również mechanizmy takie

8:38jak Sanity, czyli po prostu usuwanie pozornie

8:41niebezpiecznych znaków z danych przesyłanych przez użytkownika.

8:45Najprostszym możliwym przykładem jest moment dodawania komentarza, w której

8:48użytkownik mógłby wpisać kod JavaScript, który w momencie, gdy trafi w sposób

8:53bezpośredni do naszego serwera, a następnie wyświetlony innym użytkownikom

8:57właśnie w formie komentarza, zadziała tak, że nie wyświetli się w formie tekstu,

9:01tylko zostanie wykonane przez przeglądarkę.

9:03Oczywiście przed czymś takim musimy się odpowiednio zabezpieczyć.

9:07I ostatecznie, tak jak powiedziałem, możemy jeszcze rozważyć wykorzystanie http

9:11only kuki i tutaj uwzględnić przy tym ewentualną ekspozycję na ataki CSS.

9:17Zanim przejdziemy do podsumowania, dodam

9:19jeszcze, że całkiem dobrym pomysłem jest przejrzenie zarówno wcześniej wspomnianego

9:23przeze mnie linku, jak i innych materiałów dotyczących sposobów ataków.

9:27Im lepiej będziemy je rozumieć, tym lepiej

9:30będziemy rozumieć sposoby zabezpieczenia się przed nimi.

9:33I tutaj mamy przykładowo listę styli,

9:35petów, kodu, które w różnych sytuacjach mogą okazać się niebezpieczne.

9:38Nabywając wiedzę na ich temat możemy podejmować lepsze decyzje dotyczące

9:43uwierzytelnienia, połączenia i sposobów zabezpieczenia się przed takimi atakami.

9:48Jednocześnie jeżeli chciałbym podsumować teraz tą całą lekcję, powiedziałbym tak,

9:52że w momencie gdy masz do czynienia z aplikacją wykorzystującą sesja, koniecznie

9:56wykorzystaj token CSS do tego, aby zabezpieczyć.

10:00Sposób uwierzytelnienia.

10:01Z kolei w momencie, gdy wykorzystujesz REST API możesz albo podobnie jak ja w

10:06większości przypadków wykorzystać ciasteczko http only z dodatkową flagą

10:10secure oraz odpowiednim dbaniem o nagłówki i te najbardziej wymagane aktywności

10:15związane z kontrolą danych wprowadzanych przez użytkownika.

10:19Ewentualnie, jeżeli ten sposób nie jest

10:21dla Ciebie właściwy, pamiętaj proszę o tym, że możesz przechowywać ciastko w

10:25Local Storage bądź Session Storage, natomiast wtedy już definitywnie musisz

10:29uwzględnić zabezpieczenie się przed atakami XSS.

10:32No to teraz mam nadzieję, że ta lekcja i to, co powiedziałem, przynajmniej zwrócić

10:36Twoją uwagę właśnie na ten obszar dotyczący różnego rodzaju ataków, na które

10:41może zostać narażona Twoja aplikacja, jest tutaj?

10:44Nie.

10:44Niewykluczone, że przyjdzie Ci się mierzyć z mojej strony.

10:47Zachęcam Cię do tego, aby przeglądać sobie

10:49materiały dotyczące różnego rodzaju ataków i też form zabezpieczeń.

10:53Potem wykorzystując tą wiedzę możesz zestawić to z potrzebami Twojej aplikacji

10:58oraz wykorzystywanym przez Ciebie sposobem komunikacji.

11:01W ten sposób będziesz dążyć do tego, aby zminimalizować ryzyko ataku, bądź też

11:05ewentualnie w momencie, gdy wystąpi skutecznie uniemożliwić jego sukces.

11:10Oczywiście w tym wszystkim polecam jeszcze warstwę monitorowania swojej aplikacji, w

11:14tym wykorzystania systemu logów do tego, aby nie tylko przeciwdziałać, ale również

11:18w momencie, gdy ewentualny atak wystąpi, być w stanie namierzyć jego źródło i

11:23poradzić sobie z ewentualnymi konsekwencjami.

11:25Tymczasem dzięki za uwagę i zapraszam Cię do kolejnej lekcji.