Jak przeszkoliliśmy 12 programistów z bezpiecznego kodowania
Zespół deweloperów z firmy logistycznej pod Kielcami myślał, że ich kod jest szczelny, bo nikt się nie włamał od 3 lat. Podczas dwudniowych warsztatów w październiku 2024 roku pokazaliśmy im, że brak włamania to często po prostu brak zainteresowania ze strony hakerów, a nie zasługa zabezpieczeń. Przez 16 godzin Marek Kwiatkowski pracował z grupą 12 programistów, wyłapując 14 krytycznych błędów w ich własnym systemie do zarządzania flotą.
Start warsztatów: analiza 14 luk w kodzie
Zaczęliśmy 14 października o godzinie 9:00 w sali konferencyjnej przy ulicy Sienkiewicza. Zamiast nudnych slajdów o teorii, od razu poprosiliśmy zespół o udostępnienie fragmentu kodu modułu logowania. Programiści z tej firmy transportowej używali frameworka, który miał być bezpieczny sam w sobie, ale szybko odkryliśmy, że konfiguracja była dziurawa jak sito. W ciągu pierwszych 42 minut warsztatu Marek Kwiatkowski pokazał, jak za pomocą prostego skryptu w Pythonie można pominąć ekran logowania i wejść do panelu administratora bez podawania hasła. To uświadomiło grupie, że nawet najnowsze narzędzia nie zastąpią logicznego myślenia o bezpieczeństwie.
Druga część poranka skupiła się na błędach typu SQL Injection, które wciąż straszą w wielu polskich systemach. Znaleźliśmy konkretną lukę w linii 142 pliku odpowiedzialnego za generowanie raportów miesięcznych. Deweloperzy byli zdziwieni, że ich system filtrowania danych nie wyłapał złośliwego zapytania. Wykorzystując to niedopatrzenie, wyciągnęliśmy z bazy testowej dane 47 fikcyjnych klientów w mniej niż 4 minuty. Każdy z 12 uczestników musiał samodzielnie powtórzyć ten atak, aby zrozumieć, co widzi napastnik po drugiej stronie ekranu. Takie podejście pozwoliło im poczuć realne zagrożenie, a nie tylko o nim słyszeć.
Brak włamania to często tylko szczęście, a nie zasługa Twojego kodu. My to szczęście zamieniamy na twarde reguły.
Sesje i ciasteczka: jak przejęliśmy konto w 3 minuty
Po przerwie na kawę o 11:15 zajęliśmy się zarządzaniem sesjami. W analizowanej aplikacji logistycznej czas wygaśnięcia sesji był ustawiony na 12 godzin, co jest ogromnym ryzykiem w przypadku pracy w publicznych sieciach lub na komputerach współdzielonych. Pokazaliśmy, jak łatwo przechwycić token sesji przez niezabezpieczone Wi-Fi. Jeden z programistów, Tomek, był sceptyczny, dopóki nie zobaczył, jak przejmujemy jego konto deweloperskie bez znajomości loginu. Wystarczyło 3.2 minuty pracy z narzędziem Burp Suite, aby uzyskać pełny dostęp do jego uprawnień w systemie.
W tej części warsztatu skupiliśmy się na bezpiecznym ustawianiu flag HttpOnly oraz Secure dla ciasteczek. To prosta zmiana, która blokuje większość ataków typu Cross-Site Scripting (XSS). Deweloperzy musieli własnoręcznie poprawić 7 plików w swoim repozytorium Git, aby wdrożyć te zabezpieczenia. Było sporo dyskusji o tym, jak to wpłynie na wygodę użytkownika, ale po przetestowaniu rozwiązania okazało się, że zmiana jest niezauważalna dla klienta, a drastycznie podnosi poprzeczkę dla włamywacza. Do godziny 14:00 cały zespół wiedział już, jak blokować próby kradzieży sesji.
Praktyczne łatanie błędów drugiego dnia
Drugi dzień warsztatów, 15 października, poświęciliśmy na sprzątanie. Zamiast szukać nowych dziur, skupiliśmy się na ich skutecznym łataniu. Wprowadziliśmy zasadę 'deny by default' w konfiguracji zapory sieciowej i filtrach wejściowych aplikacji. Każdy z 12 programistów otrzymał listę 3 konkretnych zadań do wykonania w swoim module. Najtrudniejszym wyzwaniem była poprawa skryptów uploadu plików, gdzie wcześniej system przyjmował niemal każdy format. Skróciliśmy listę dozwolonych rozszerzeń i dodaliśmy skanowanie antywirusowe na poziomie serwera, co zajęło zespołowi około 5 godzin intensywnej pracy.
Przed końcem dnia przeprowadziliśmy test końcowy. Próbowaliśmy włamać się do poprawionych modułów tymi samymi metodami, które zadziałały dzień wcześniej. Wynik był satysfakcjonujący: 11 na 14 wcześniej wykrytych luk zostało całkowicie zamkniętych, a pozostałe 3 zostały zabezpieczone dodatkowymi warstwami weryfikacji. Zespół programistów przyznał, że największą wartością było zobaczenie swojego kodu z perspektywy kogoś, kto chce go zepsuć. Marek Kwiatkowski na koniec wręczył każdemu listę kontrolną z 11 punktami, którą mają stosować przy każdym nowym commicie do głównego brancha projektu.
Naprawa 7 funkcji w jeden dzień dała temu zespołowi więcej niż rok czytania dokumentacji o bezpieczeństwie.
Efekty: o 24% mniej podatności w 2 dni
Podsumowując nasze spotkanie w Kielcach, firma logistyczna zyskała nie tylko bezpieczniejszy system, ale przede wszystkim świadomą kadrę. Z naszych pomiarów po warsztatach wynika, że ogólna liczba podatności w kodzie spadła o 24%, a czas potrzebny na wykrycie błędów bezpieczeństwa podczas code review skrócił się o połowę. To konkretny wynik, który przekłada się na mniejsze ryzyko wycieku danych klientów transportowych i uniknięcie kar RODO. Właściciel firmy był zaskoczony, że w zaledwie 16 godzin udało się rozwiązać problemy, które narastały od 2021 roku.
Ostatnia godzina warsztatu była poświęcona na pytania i odpowiedzi. Rozmawialiśmy o tym, jak utrzymać ten standard w codziennej pracy, gdy terminy gonią, a klient chce nowych funkcjonalności 'na wczoraj'. Marek Kwiatkowski pokazał narzędzia do automatycznego skanowania kodu, takie jak Snyk, które można zintegrować z procesem CI/CD. Dzięki temu programiści będą dostawać powiadomienia o błędach w czasie rzeczywistym, jeszcze zanim kod trafi na serwer produkcyjny. To zamknięcie cyklu szkoleniowego pozwoliło zespołowi poczuć się pewniej w swoich kompetencjach security.
