„Współcześni młodzi programiści nieświadomie pozostawiają w aplikacjach proste podatności, bo… dzięki mechanizmom zaszytym w bibliotekach oraz frameworkach, bezpieczeństwo zaczęło w dużej mierze „robić się samo”. A oni z tego właśnie powodu nigdy nie zetknęli się z błędami w stanie czystym! […]”
Poniższy felieton ukazał się po raz pierwszy w raporcie CERT Orange za rok 2022 (format PDF). Pozostałe wydania można pobrać ze strony cert.orange.pl/raporty-cert
Codziennie w Polsce rodzi się około tysiąca dzieci. W dniu narodzin nie znają żadnych memów, jednak przed osiemnastką biegle operują nosaczem sundajskim, „twoją starą” oraz kompletem emotek. Aby taki stan się utrzymywał, każdego dnia średnio tysiąc młodych Polaków musi poznać zasady użycia literek „xD”.
Co roku pracę programisty rozpoczyna w Polsce kilkanaście tysięcy osób. Na początku swojej ścieżki edukacyjnej nie znają żadnego z punktów OWASP TOP10, jednak w dniu wejścia na rynek pracy… no właśnie. Tu jest znacznie gorzej, wiedza z obszaru bezpieczeństwa IT nie przesącza się do głów samoczynnie. Trudno też mówić o stanie stabilnym, moim zdaniem rozpoczął się powolny regres.
Czemu? Po wielu rozmowach (także kwalifikacyjnych) formułuję następującą tezę: współcześni juniorzy nieświadomie pozostawiają w aplikacjach podatności, bo… nigdy nie zetknęli się z błędami w stanie czystym. Spójrzmy na SQL Injection w formularzach webowych. Dawniej programista webowy sięgał do zmiennych $_POST albo $HTTP_POST_VARS i z odczytanych wartości sklejał zapytanie SQL. Demonstracja powstałej podatności była banalna, ówczesne remedium (zapytania parametryzowane) zajmowało jedną linię kodu więcej. A potem pojawiły się biblioteki ORM oraz frameworki realizujące persystencję – i bezpieczeństwo zaczęło „robić się samo”, skutecznie lecz niejawnie.
Takie automatyzacje są z nami dłużej, niż trwa typowy cykl kształcenia programisty. Efekt łatwo przewidzieć – junior dopisujący nową funkcję omijającą ORM-a najpierw umieści w apce soczystego SQL Injection, zaś napomniany – weźmie się za wykrywanie wstrzyknięć wyrażeniem regularnym. Pamiętacie pewnie dowcip o tym, że kiedyś instrukcja obsługi samochodu uczyła regulacji luzów zaworowych a dziś ostrzega jedynie, by nie pić płynu z akumulatora. Z programowaniem jest podobnie – mimo licznych (pomocnych!) warstw abstrakcji nadal dobrze jest wiedzieć, jak rzeczy naprawdę działają pod maską. A mało komu chce się zgłębiać tę wiedzę.
Paradoksalnie, nadal więcej uwagi poświęcamy zagrożeniom czyhającym na archetypiczną panią Grażynkę. Maile z załącznikami. Tekstowe wiadomości od prezesa domagającego się szybkiego przelewu dużych środków na zagraniczne konto. Cudzy pendrive znaleziony w windzie. Dopłata do „dezynfekcji paczki”, alert z „banku” z linkiem do logowania, „kontrahent” zmieniający rachunek bankowy. Jeśli pani Grażynka nie ma dość wiedzy, pomogą jej polityki bezpieczeństwa eliminujące całe klasy podatności, filtrowanie e-maili, proxy w przeglądarce, procedury wymuszające potwierdzanie ryzykownych działań przez więcej niż jedną osobę. Wreszcie – szkolenia z security awareness tuż po zatrudnieniu.
Mało która firma może pozwolić sobie na wybrzydzanie przy rekrutacji programistów – jest ich mało, są drodzy, roszczeniowi a i tak spora część kandydatów ledwie umie programować. Znajomość tematów security będzie więc jedynie mile widzianym dodatkiem, rzadko weryfikowanym, rzadko wspomaganym szkoleniami. Wciąż spotyka się podejście, w którym „bezpieczeństwo” dodawane jest do powstającego produktu na samym końcu, po testach penetracyjnych – jeśli oczywiście pozwoli na to czas i budżet. W przeciwnym razie usterki usuwane są już po wdrożeniu – albo pierwszym (wykrytym) włamaniu.
Co więc możemy zrobić, by regres się nie pogłębiał? Uniwersalnych rozwiązań brak. A może… może by tak utworzyć w firmach tworzących oprogramowanie stanowisko wędrownego bajarza? Starca migrującego od zespołu do zespołu, opowiadającego klechdy i legendy o tym, jak programowali nasi ojcowie i ojcowie naszych ojców? O dawnych wyzwaniach, o odwadze, wytrwałości, hotfiksach i workaroundach? O tym, jak Zło – raz zmitygowane – przyczai się by powrócić?
O autorze: zawodowy programista od 2003 roku, pasjonat bezpieczeństwa informatycznego. Rozwijał systemy finansowe dla NBP, tworzył i weryfikował zabezpieczenia bankowych aplikacji mobilnych, brał udział w pracach nad grą Angry Birds i wyszukiwarką internetową Microsoft Bing.
6 odpowiedzi na “Ci, którzy nie pamiętają podatności, skazani są na ich powtarzanie”
(Nie)stety to normalne. Programowanie staje się czymś popularnym i niewymagającym jakiegoś wielkiego przygotowania. Przynajmniej po to, żeby tworzyć coś, co jest biznesowo akceptowalne w krótkim okresie.
Wiąże się to m.in. z tym, że dostawcy są zasadniczo w bardzo maym stopniu odpowiedzialni za swoje wytwory.
I spadek znajomości podstaw dalece nie ogranicza się do bezpieczeństwa. Wielu współczesnych seniorów nie ma pojęcia o złożoności obliczeniowej algorytmów, nie zna pojęcia stabilności sortowania, albo nie rozumie dlaczego pieniędzy nie liczy się na liczbach zmiennoprzecinkowych. I zazwyczaj jest im to niepotrzebne. Zazwyczaj.
A potem jest ból i zgrzytanie zębów.
Ale to – jak sam zauważyłeś nie ogranicza się do programowania. Współczesny kierowca mając do dyspozycji samochód z ABS/ESP i innymi TLA _w normalnych_ warunkach radzi sobie lepiej i sprawniej przemieszcza się z punktu A do punktu B. Problem pojawia się gdy warunki przestają być normalne i wychodzimy poza zakres obsługiwany przez TLA. To się potrafi skończyć bardzo nieprzyjemnie.
No cóż, takie życie i mniej lub bardziej swiadoma analiza ryzyka.
Na początek trzeba wreszcie skończyć z kultem „młodych dynamicznych zespołów” i zacząć cenić doświadczonych pracowników. 50+ może spokojnie dalej kodować a 50+ i 60+ mogą być mentorami (inna, ciut bardziej cywilizowana nazwa na Twojego bajarza (który w sumie też jest spoko 😉
Tu sie tworza 2 bieguny. Z jednej strony pełno frameworków i bibliotek upraszcza programowanie, co biznes bardzo łatwo kupuje: szybciej, taniej, mocniej. To znowu powoduje, że nikt nie ma czasu na zaglądanie pod maske, bo przeciez „trzeba dowozic funkcjonalnosci”. Z drugiej strony klient mowi: „Chcemy byc bezpieczni. Jakie toole musimy wdrożyć?” No i tu zaczyna sie jazda, „bo nim wiecej, tym lepiej”. Nikt tego nie rozumie, co to robi, po co i tylko patrzy czy świeci sie na czerwono czy zielono. Jak za dużo czerwonego to klient sie niepokoi. No ale „jestesmy bezpieczni”.
Pomyśleć, że na techniku informatyku strony z zadań egzaminacyjnych są robione tak, aby były podatne na SQL Injection. Nikt tam nie zwraca uwagi na bezpieczeństwo, bo to zadania szablonowe. Ja wiem, że nie każdy technik informatyk będzie programistą, ale jak już uczymy czegoś, to mogłoby to być robione tak, aby zachować zasady bezpieczeństwa.
Takie stanowisko już istnieje i nazywa się Security Champion.
https://owasp.org/www-project-security-culture/v10/4-Security_Champions/
odpowiednie narzędzia faktycznie sprawiają, że wiele wiedzy nam nie potrzeba
ale te narzędzia są bardzo złożone, a często pojawia się „nowe, fajne”, które nie jest należycie przetestowane i może zawierać wiele luk, chociażby dlatego, że powstało przy niedoborze tej wiedzy…
a czasem i najlepsze narzędzie zawodzi, wysokowydajne implementacje z ręcznym zarządzaniem pamięcią są doskonałym miejscem, by „otworzyć portal, którym zło może wrócić do naszego świata”, co już wielokrotnie zostało udowodnione
ale gorzej się dzieje, gdy mimo szerokiego wyboru narzędzi żadne nie są używane, jak to ma najczęściej miejsce w wypadku biednej Pani Grażynki, która dostaje dziennie kilkaset Bardzo Pilnych Maili, ale nie ma żadnego zabezpieczenia przed uruchamianiem plików wykonywalnych i skryptów z załączników, a jej maszyna jest w tej samej sieci, co wiele maszyn krytycznych dla stabilności całej firmy…