W najnowszym odcinku naszego podcastu gościliśmy Patryka Omiotka, eksperta w dziedzinie front-endu i aplikacji webowych. Patryk podzielił się z nami cennymi spostrzeżeniami na temat kluczowych aspektów bezpieczeństwa w rozwoju aplikacji front-endowych. Oto trzy główne wątki, które zdominowały naszą rozmowę:
- Aktualizacja pakietów NPM: Patryk podkreślił, że jednym z najczęstszych błędów w projektach front-endowych jest ignorowanie aktualizacji pakietów NPM, co może prowadzić do poważnych luk w bezpieczeństwie.
- Podział odpowiedzialności za bezpieczeństwo: Omówiliśmy kontrowersyjny temat podziału odpowiedzialności za bezpieczeństwo między front-end i back-end, z naciskiem na to, że front-end również odgrywa kluczową rolę w zapewnieniu bezpieczeństwa aplikacji.
- Komunikacja problemów bezpieczeństwa w organizacji: Patryk podzielił się strategiami efektywnego komunikowania problemów bezpieczeństwa w organizacjach, podkreślając, jak ważne jest odpowiednie formułowanie tych kwestii, aby przyciągnąć uwagę decydentów.
Te wątki stanowią fundament naszej rozmowy o bezpieczeństwie w świecie front-endu.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof: W takim razie na kolejnym wywiadzie naszym gościem jest Patryk Amiotek. Patryk, bardzo miło Ciebie gościć tutaj, dzięki, że znalazłeś chwilę czasu. Patrząc na Twoje doświadczenie, muszę powiedzieć, że frontend mocno, ale myślę, że sam o sobie opowiesz najlepiej. Jakbyś mógł pokrótce stresić, czym się zajmujesz?
Patryk: Ok, ogólnie jestem programistą, trenerem i konsultantem IT. Tak jak wspomniałeś w Frontend ostatnio mocno, ale powoli, a może nawet szybciej. trochę wracam do Backendu, bo zaczynałem od Backendu, dawno temu od PHP, potem był Python, potem JavaScript, TypeScript, no i teraz już tak bardziej full-stockowo tworzymy projekty w jednym stacku.
Andrzej: To wspomniałeś, że wracasz powoli do Backendu, ale mam nadzieję, że nie do PHP.
Patryk: Do PHP nie, chociaż z ciekawości parę projektów sobie otworzyłem. Jakoś jednak nie. Aż takiego dużego sentymentu nie mam.
Andrzej: A to ci niespodzianka.
Krzysztof: Czyli rysy na psychice.
Andrzej: Zostały.
Patryk: Parę nieprzespanych nocy. Nie wiem, czy to da się wyleczyć. Także może zostawmy już PHP.
Andrzej: Tak, nie kopmy leżącego. Chociaż żarty żartami, ale PHP robi robotę. Żarciki tylko, takie programistyczne. Patryk. Od razu z grubej rury. Powiedz mi. Jak z Twoich obserwacji wygląda podejście do bezpieczeństwa? Może właśnie od tej strony frontendowej, z którą jesteś mocno związany w ostatnich latach. Jak to według Ciebie, jak to w Twojej wizji wygląda, jak to z Twojego doświadczenia wygląda? I Twojego personalnego i też tego co po prostu widzisz w organizacjach czy u ludzi, których szkolisz.
Patryk: Ok, to jest ogólnie ciekawe zagadnienie, bo jeżeli się skupimy na czystym frontendzie, to bardzo często ta odpowiedzialność jest przerzucana na backend, że backend powiedzmy powinien obsługiwać wszystko, a frontend tak na dobrą sprawę jest tylko jakimś tam interfejsem, więc niestety też w wielu projektach, gdzie na przykład tworzyłem audyt to widać po prostu też takie podejście że weekendowcy powinni za to wszystko odpowiadać. no ale mimo wszystko frontend jest tym pierwszym punktem styku. bardzo często w aplikacjach webowych to zawsze jest tym pierwszym punktem styku. jest masa po prostu aplikacji dziurowych niezabezpieczonych z których korzystają no setki miliony użytkowników. bardzo często. I dość często też widzę po prostu takie podejście do bezpieczeństwa, że okej kiedyś to załatamy. Jak dobrze wiemy nie ma takiego dnia jak kiedyś. Często potem uzyskać ten czas powiedzmy na refaktor czy łatanie dziur albo czekamy na jakiś audyt z działu powiedzmy security. I wtedy już koszty powiedzmy tych zmian są dość grube.
Andrzej: Czyli o ile dobrze zrozumiałem, to często te błędy, przynajmniej, może niekonieczne błędy, niedopatrzenia po stronie frontendowców wynikają z po prostu przerzucenia odpowiedzialności i całej pracy na backend. Mówią, że to nie nasza działka, to backend, a to nie my.
Patryk: Między innymi, ja bym podzielił te projekty jeszcze na takie mniejsze, gdzie mamy MVP, jakieś duże, powiedzmy w korporacjach. W tych małych jest nawet duża świadomość, że to oprogramowanie potrafi być dziurawe, ale to jest też kwestia czasu, budżetu, albo szybko, albo dobrze. Czasami po prostu trzeba to zrobić, żeby pozyskać dofinansowanie na dalszy rozwój. Więc wydaje mi się, że w tych projektach jest większa jakby świadomość zagrożeń, ale też te ryzyka się często podejmuje, wypuszczając tego typu aplikacje. W większych takich aplikacjach z kolei widzę, że jest takie przerzucanie właśnie odpowiedzialności, czy to backend, czy dział security, ale to też wynika z tego względu, że w szkole frontendowców nikt ich tak na dobrą sprawę tego security nie uczy.
Andrzej: Właśnie chciałem pójść w tym kierunku, że to ja mam podobne doświadczenia, że to nie do końca wynika z tego, że dana osoba chce zignorować bezpieczeństwo, tylko jest niedoedukowana, ale to też po prostu wynika, że biznes z nią nie inwestuje w te szkolenia dla front-endu. Bo też patrzy na to, że to back-end powinien.
Patryk: To back-end powinien, nie widzi tak od razu wartości.
Andrzej: Właśnie, nie widzi tej wartości, a z mojej perspektywy, no ja zdaję sobie sprawę z tego, że faktycznie to backend odpowiada za bycie źródłem prawdy, no ale jest multum różnych kawałków, które da się zabezpieczać, polepszać właśnie jeszcze na frontendzie po to, żeby Nawet jeżeli potem zrobię to na backendzie, to żeby już w tej pierwszej linii odrzucić pewne przypadki. I czy kojarzysz jakieś, nie wiem, narzędzia, metodyki, nie wiem, standardy jakieś, coś co można byłoby frontendowcom rzucić i powiedzieć, dobra, to na przykład jeśli spożyjecie na to, albo użyjecie tego, to polepszycie swoje albo zrozumienie, albo w ogóle bezpieczeństwo swoich projektów?
Patryk: Albo swoje życie. Jeżeli frontendowcy chcą spać spokojnie, to na pewno powinni uwzględnić dane od użytkowników. Nigdy nie możemy wierzyć tym użytkownikom. Zawsze znajdzie się jakiś atakujący, więc czy to powinniśmy zadbać o po prostu blokowanie, wstrzykiwanie skryptów, czy Content Security Policy, żeby nie ładować jakichś dziwnych zasobów z nie wiadomo jakichś źródeł, czy po prostu dbać o te requesty. Ale już z samego takiego powiedzmy warsztatu, coś co daje na przykład dużo jakby swobody w dalszym jakby utrzymywaniu aplikacji, albo jaki błąd bardzo często jest popełniany w projektach front-endowych, to ignorowanie starych wersji pakietów NPM-a. Bo musimy z nich korzystać, ale jak już skorzystamy z jednego pakietu, to on bardzo często zostaje przez miesiące albo nawet lata. Ostatnio widziałem, w grudniu bodajże, robiłem audyt projektu, który korzysta z Vue 2 i właśnie w grudniu skończył się oficjalny support do Vue 2. Więc projekt jest troszeczkę w kropce, bo jest masa dziur i nie wiadomo jak to załatać. Została podjęta decyzja, no to migrujemy do trójki. To zajmie miesiąc. Więc można się po prostu umówić co kilka release’ów np. na robienie audit loga, sprawdzanie co możemy podbić. Tylko też nie popadajmy tutaj w skrajności, w skrajność, bo czasami po prostu warto zweryfikować czy jest taki czas i budżet na to żeby daną paczkę teraz powiedzmy w tym sprincie podbić czy też nie. No ale na pewno inputy dane od użytkownika, nie przechowywanie danych wrażliwych, nie trzymanie tokenów w local storage, nie przechowywanie powiedzmy jakichś identyfikatorów sekwencyjnych, co się bardzo często zdarza też. No jest cała masa rzeczy, to temat rzeka, ale z takich najważniejszych myślę, że to.
Krzysztof: Tak, właśnie. Powiedziałeś o NPM. NPM sam w sobie jest pewnym problemem, mówiąc kolokwialnie i trochę żartobliwie. Dzisiaj miałem prezentację na temat złośliwych, intencjonalnie złośliwych paczek w NPM. MPM samą swoją skalą imponuje, bo to jest obecnie już ponad blisko 2,5 miliona paczek, które tam się znajdują, a codziennie średnio około 830 nowych paczek wpada do tego repozytorium. Ja się odniosę do tego, co powiedziałaś w kontekście update’owania, podnoszenia wersji tych paczek do aktualnych. Są narzędzia, które automatyzują nam ten proces Renovate, ale też zdaję sobie sprawę, że nie w każdym projekcie tego typu ruchy są plug and play i jesteśmy w stanie sobie podnosić wszystko do najnowszych wersji. Szczególnie jeżeli działamy z kodem, który jest Legacy, a projekt nie jest takim typowym Greenfieldem.
Patryk: Wydaje mi się, że nawet w mniejszej liczbie projektów możemy sobie na to pozwolić, bo bardzo często te audyty się robi, no zależy, zależy jaki mamy cykl wytwarzania. Jeżeli, jeżeli działamy w sprintach, to zauważyłem, że raczej gdzieś pod koniec te audyty są zakończone. No jeżeli mamy jakieś continuous delivery, no to tak, okej, powinniśmy te paczki podbić, no ale mamy jakieś pilniejsze biznesowo zadania, no i to gdzieś tam spada, spada, spada. Znowu trafia w ten worek kiedyś. Złotego środka. wydaje mi się, że nie ma na to.
Andrzej: Ja mam jeszcze jedno pytanie właśnie odnośnie tych podbijania podatnych zależności. Jak? Tu nie ma dobrych odpowiedzi. Wszystko to będzie moim zdaniem, ale właśnie jak. twoim zdaniem, tym bardziej, że masz dużo doświadczenia i w backendzie i frontendzie, ale też takiego na poziomie CTO. Powiedz mi, jak ty widzisz podchodzenie właśnie do wyprowadzania podatnych zależności? Czy widzisz to bardziej jako kawałek security, czy może po prostu bardziej jako spłacanie długu technologicznego, Coś, co jest szerszym aspektem niż tylko tym związanym z bezpieczeństwem.
Patryk: To jest bardzo dobre pytanie i to zależy.
Andrzej: Patryk też jest jeszcze konsultantem, jak słychać.
Patryk: Które słowo łatwiej sprzedać w danej organizacji? Czy na przykład słowo security powoduje, że szybciej wykonamy tę pracę? Czy dług techniczny, który wydaje mi się, że ma takie priorytywne bardziej zabarwienia, I często też ludzie się nie przyznają, że nie mamy takiego długu technicznego. Jeżeli byśmy przedstawili dwa audyty i powiedzieli, że to jest dług techniczny, no dobra, po czasie taki dług techniczny się pojawia. I drugi audyt, gdzie napiszemy to samo, że to są usterki, security, to kompletnie inaczej ludzie do tego podchodzą.
Andrzej: To jest bardzo ciekawa uwaga, że w zasadzie to zależy nie tyle od samego kontekstu takiego na polu operacyjnym, na polu bitwy, ale od kontekstu tego, co łatwiej jest przedać w organizacji i co nam pozwoli po prostu proaktywnie działać.
Patryk: Tak, tak, bo jeżeli sobie wyobrazimy, że na przykład mamy bank. Taki bank dostaje właśnie dwa audyty. Dług techniczny, dobra, system rozwijamy 5 lat. A dziury, security?
Andrzej: Tak, no to tu już są zobligowani i mają odpowiednie SLA, które im nakazują wyprowadzanie podatnego. Czyli tutaj naprawdę drajwerem jest bardziej organizacja i kontekst, a nie te operacyjne sprawy. Ok, kupuję tą odpowiedź.
Krzysztof: Ja bym chciał, Patek, wrócić, ponieważ rozmawialiśmy na temat tego, co dzieje się od strony przeglądarki. Jak ty czujesz, jak programiści, którzy na co dzień pracują na warstwie front-endu rozumieją to, jak działają przeglądarki pod kątem mechanizmów bezpieczeństwa, które tam zachodzą? Czy jest takie zrozumienie, czy kończymy na same origin policy i więcej mnie już nie obchodzi, a nawet i to często jest czymś, co sprawia im trudność w zrozumieniu?
Patryk: Bardzo często nie rozumieją. Bardzo często ten temat security jest jakby odrębnym skillem. Gdzieś w zespole jest np. osoba, która np. się tym interesuje i potrafi przed zespołem pokazać, że to jest warte rozważenia. Ale nawet jak sobie popatrzymy na jakieś tikety, czy definition of done, to tam praktycznie nie ma żadnych kryteriów związanych z security. To jest jeden taki aspekt. A drugi, content security policy w wielu organizacjach, z którymi ja pracowałem, był bardziej rozważany, czy uwzględniany, podnoszony przez devopsów, specjalistów od security. Mimo, że frontendowcy wiedzą, że coś takiego jest, no ale nie będziemy się tam bawili w manifesty, żeby teraz skądś jakieś zasoby blokować, nie blokować. My chcemy strzelać do tego restartowego API i pokazać piękny interfejs. Więc ESP to już w ogóle, jak już jest w projekcie, to jest super. To widać, że jest ktoś, komu zależy na tym bezpieczeństwie.
Krzysztof: I jeszcze jak jest dobrze wdrożone, a nie na sztukę. Bo to też jest jednak naprawdę kawał ciężkiej pracy, żeby w takiej aplikacji z dużym ruchem, z dużą ilością zależności, do których uderza, wdrożyć fajnie CSP, które będzie szczelne.
Patryk: No to prawda, to tak jak z robieniem kuchni, prawda? Można sobie samemu zrobić kuchnię, a porównajmy jak zatrudnimy wcześniej architekta.
Andrzej: Do porównania będę go używał. Dobra. Z mojej perspektywy to ja się wystrzelałem ze swoich pytań. Pusty magazynek.
Patryk: To teraz jeszcze Patryk. Dzięki wielkie.
Andrzej: Przyjemność po naszej stronie. Dziękujemy i do zobaczenia lub usłyszenia w przyszłości.
Patryk: Do zobaczenia. Dzięki.