Jeśli kiedykolwiek myślałeś, że chciałbyś sprawnie wejść w tematykę aplikacji webowych, lub poszerzyć czy uporządkować swoją wiedzę, mamy dla Ciebie coś naprawdę unikalnego: szkolenie: “Praktyczne wprowadzenie do OWASP Top Ten”.
Do kogo skierowane jest szkolenie:
- programistów / testerów
- testerów bezpieczeństwa
- pentesterów
- architektów / projektantów
- administratorów
- osoby odpowiadające za proceduralne aspekty bezpieczeństwa / menagerowie
Czego nauczysz się podczas szkolenia:
- dowiecie się, w jaki sposób pisać bezpieczniejszy kod; być może nawet natychmiast po szkoleniu zidentyfikujecie błędy w swoim kodzie! (raz na jakiś czas dostajemy od naszych uczestników, już po pierwszym dniu szkolenia informacje typu: “popatrzyłem wieczorem na moją aplikację i znalazłem takie dziury, o których była dzisiaj mowa!”
- poznajcie nowe sztuczki pozwalające znajdować mniej znane problemy bezpieczeństwa w aplikacji,
- poznasz parę dodatkowych, mało znanych tricków, będziesz miał również możliwość – również po szkoleniu – dopytać o pewne szczegóły czy warsztat prowadzącego
- poznasz konkretne rozwiązania architektoniczne minimalizujące ryzyko błędów bezpieczeństwa w aplikacji webowej
- po tym szkoleniu będziesz już wiedział gdzie czają się największe niebezpieczeństwa dla aplikacji webowych; będziesz też mógł sprawnie rozmawiać z programistami w temacie bezpieczeństwa ich aplikacji,
- dowiecie się, co to może znaczyć, że aplikacja ma być “zgodna z OWASP 10” – i czy w ogóle jest to możliwe – i jakie kroki należy poczynić, by było to prawdą; będziecie też umieć nieco sprawniej rozmawiać z programistami czy osobami odpowiedzialnymi za techniczne bezpieczeństwo IT w firmie.
Agenda:
Na szkoleniu omawiamy każdy z punktów najnowszej wersji OWASP TOP 10 (tej z 2021 roku) pod następującym kątem:
- jakich problemów bezpieczeństwa dotyczy dany punkt,
- jak dane błędy mogą zostać wykorzystane,
- co można zrobić, by zminimalizować ryzyko wykorzystania tych błędów.
Omówione są zatem następujące punkty:
- A01 Broken Access Control
- A02 Cryptographic Failures
- A03 Injection
- A04 Insecure Design
- A05 Security Misconfiguration
- A06 Vulnerable and Outdated Components
- A07 Identification and Authentication Failures
- A08 Software and Data Integrity Failures
- A09 Security Logging and Monitoring Failures
- A10 Server Side Request Forgery (SSRF)
(czytaj dalej, jeśli chcesz wiedzieć, co dokładnie omówimy w każdym z tych punktów)
A01:2021 – Broken Access Control
W najnowszej wersji OWASP TOP 10, błędy kontroli dostępu zajmują zaszczytne pierwsze miejsce. W największym skrócie podatności tego typu polegają na nieodpowiedniej weryfikacji uprawnień do zasobów, w efekcie czego napastnik uzyskuje dostęp do danych, do których nie powinien mieć dostępu. Brzmi skomplikowanie? To nic! By lepiej zrozumieć zagadnienie, zobaczymy tutaj szereg praktycznych przykładów błędów tego typu, np.:
- Jak uzyskać dostęp do faktur innych użytkowników,
- Jak zmienić hasło innemu użytkownikowi,
- Jak uzyskać pełny dostęp do bazy danych,
- Jak wykraść dane użytkownika przez błędną konfigurację CORS,
- Jak dostać się do poufnych danych przez publiczne listingi katalogów.
W odpowiedzi na te problemy poznamy najistotniejsze sposoby zabezpieczania dostępu do zasobów, np. RBAC (role-based access control), zasadę najmniejszych uprawnień, rate limiting czy odpowiednie polityki CORS.
A02:2021 – Cryptographic Failures
Błędy w kryptografii mogą być subtelne, ale jeśli już występują, to zazwyczaj mają porażającą moc. Pozwalają zwykle na deszyfrację danych innych użytkowników lub uzyskanie dostęp do ich konta.
O kryptografii, jako nauce, moglibyśmy zrobić osobne, nawet 5-dniowe szkolenie. Tutaj jednak w sposób skondensowany przedstawimy problemy, z którymi w aplikacjach webowych musimy się najczęściej mierzyć w zakresie kryptografii i przedstawimy odpowiedzi na następujące pytania:
- W jaki sposób skonfigurować połączenie TLS do naszych usług, oraz jak przetestować, czy konfiguracja spełnia najnowsze standardy?
- Jak podejść do szyfrowania danych “w spoczynku” (tj. np. przy zapisie do bazy danych)?
- Czy sam fakt użycia szyfrowania danych bezpiecznym algorytmem szyfrującym czyni je automatycznie pod każdym względem bezpiecznymi?
- Czy można odgadnąć losowe tokeny, np. tokeny do resetu hasła?
- Jak radzić sobie z przechowywaniem kluczy API oraz innych secretów w aplikacji?
- W jaki sposób przechowywać hasła w bazie danych?
A03:2021 – Injection
Podatności typu “Injection” są jednymi z najsłynniejszych problemów bezpieczeństwa aplikacji, głównie kojarzonymi z SQL Injection. Ale czy tylko? Okazuje się, że nie! Pokażemy ogólne podejście do podatności “Injection”, oraz dlaczego można się z nimi spotkać nie tylko w kontekście SQL.
Zobaczymy kilka przykładów tego typu podatności (zaczynając od najsłynniejszych, jak SQL Injection czy XSS, a kończąc na nieco rzadszych Server-Side Template Injection) oraz omówimy ogólny sposób myślenia o tego typu podatnościach, który pozwoli nam na zabezpieczenie się przed nimi, nawet jeśli dany typ “Injection” nie ma nawet swojej nazwy!
A04:2021 – Insecure Design
Ten punkt jest niewątpliwie najbardziej ogólnym w najnowszej wersji OWASP TOP 10. Nie dotyka konkretnej podatności, a ogólnie błędów w projektowaniu aplikacji. Będzie zatem dobrą okazją, by porozmawiać o procesie budowy aplikacji. Dowiemy się czym jest S-SDLC (Secure Software Development LifeCycle) i jak można do wdrażać. Porozmawiamy o modelowaniu zagrożeń – dowiemy się jak je przeprowadzać i jak pomoże nam zrozumieć problemy bezpieczeństwa w naszej aplikacji.
Tradycyjnie przedstawimy też kilka przykładów praktycznych błędów, które mogły zostać wykryte na poziomie projektowania tej aplikacji. Gdyby zostały wówczas wykryte – koszt ich naprawy byłby o wiele mniejszy.
A05:2021 – Security Misconfiguration
Czasem błędy bezpieczeństwa w aplikacji webowej nie wynikają z problemów w kodzie, ale z niewłaściwej konfiguracji aplikacji lub jej środowiska. O tym właśnie będzie ten punkt. Zobaczymy kilka przykładów, do czego może się przydać poznanie zawartości katalogów na serwerze; dlaczego na serwerach produkcyjnych nie należy wyświetlać dokładnych stack trace’ów czy też dlaczego powinniśmy zmieniać domyślne hasła do usług.
A06:2021 – Vulnerable and Outdated Components
Kilka lat temu miał miejsce bardzo głośny atak na systemy firmy Equifax, w wyniku których wyciekły dane ponad stu milionów Amerykanów. Powód? Brak aktualizacji biblioteki Apache Struts, która była podatna na błąd, pozwalający na wykonanie dowolnego kodu po stronie serwera. To jeden z wielu przykładów uświadamiających, jak ważne jest utrzymywanie komponentów aplikacji (bibliotek, zależności itp.) w najnowszych wersjach, a przynajmniej w wersjach niezawierających znanych podatności.
W tym rozdziale poznamy przykłady narzędzi, które pozwalają na weryfikację, czy używane przez nas zależności zawierają znane błędy bezpieczeństwa. Zobaczymy także, jak proces weryfikacji wersji zintegrować z procesem rozwoju aplikacji.
A07:2021 – Identification and Authentication Failures
Błędy związane z identyfikacją lub uwierzytelnieniem zazwyczaj pozwalają na przejęcie konta użytkowników. Poznamy tutaj przykłady następujących ataków:
- Przejęcie konta użytkownika przez brute force loginu i hasła,
- Ominięcie zabezpieczeń pozwalających na ustalenie, czy dany login istnieje,
- Ominięcie dwuskładnikowego uwierzytelnienia,
- Błędy w procesie resetu hasła (np. poprzez nadpisanie nagłówka Host)
Dowiemy się, jak zabezpieczać się przed tymi konkretnymi przykładami ataków, ale także poznamy ogólne zasady dobrej implementacji tego procesu, niezależnie od tego, czy implementujemy go sami, czy też integrujemy się z zewnętrznym dostawcą (np. poprzez OpenID Connect). Dowiemy się także, jakie są obecnie najbardziej polecane zasady tworzenia polityki haseł.
A08:2021 – Software and Data Integrity Failures
Kolejny punkt najnowszego OWASP TOP10, który dotyczy bardziej procesu rozwoju aplikacji, aniżeli konkretnych podatności. Dotyka on wszelakich błędów wynikających z braku sprawdzania integralności plików wykonywalnych oprogramowania.
Pokażemy tutaj m.in. następujący przykład: instalujemy zależność z npm, co do której mamy pewność, że jest bezpieczna. Gdy ta sama zależność jest instalowana w procesie CI/CD, okazuje się, że została zainstalowana inna, podatna na błędy bezpieczeństwa wersja! Jak to możliwe? Dowiemy się na szkoleniu 🙂
Przy okazji tego tematu omówimy sobie także ogólniej problemy związane z atakami na łańcuchy dostaw; zastanowimy się nad możliwymi sposobami minimalizacji tych ryzyk.
A09:2021 – Security Logging and Monitoring Failures
Załóżmy, że w naszej aplikacji występuje incydent bezpieczeństwa, w wyniku którego ktoś pobiera poufne dane użytkowników. W tym momencie chcielibyśmy się dowiedzieć, w jaki sposób dokładnie doszło do tego włamania, i do jakich danych napastnik uzyskał dostęp… Niestety – jeśli nie logujemy wystarczająco dużo danych na temat naszych systemów, może okazać się, że nie będziemy w stanie wyciągnąć odpowiednich wniosków.
Dlatego w tym rozdziale omówimy w jaki sposób należy podejść do logowania danych w aplikacji webowej. Tj. jakie dane powinny być logowane, a jakie nie powinny być logowane.
Pokażemy też przykład aktywnego monitoringu, który pozwoli wykryć atak, nawet jeśli nie jest to atak stricte techniczny, a po prostu wynikający z pewnego nietypowego użycia aplikacji.
A10:2021 – Server-Side Request Forgery (SSRF)
SSRF (Server-Side Request Forgery) to atak pozwalający na zmuszenie serwera aplikacyjnego do wykonywania zapytań do innych serwerów. Na pierwszy rzut oka może nie wygląda to specjalnie groźnie, ale w praktyce atak pozwala na przełamanie pewnych cichych założeń dotyczących naszych systemów (np. “jak ktoś jest w LAN, to na pewno jest zaufany!”). Na szkoleniu poznamy praktyczne przykłady wykorzystania SSRF nawet do całkowitego przejmowania serwerów!
Dowiemy się także, że ochrona przed tym atakiem nie jest prosta – spróbujemy zastanowić się, jakie podejście będzie najbardziej odpowiednie, jeśli SSRF będzie de facto wynikał z oczekiwanej funkcjonalności w naszej aplikacji.
Przydatne informacje:
Pytanie: W jakich godzinach trwa szkolenie?
Odpowiedź: 9:00 -> 16:00 (w tym przerwy). Po każdym dniu dostępna jest również sesja Q&A z prowadzącym (16:00 -> 17:00)
Pytanie: Czy otrzymam certyfikat uczestnictwa po szkoleniu?
Odpowiedź: Tak
Pytanie: Czy szkolenie jest zdalne czy on-site w sali szkoleniowej?
Odpowiedź: Zdalne
Pytanie: Czy możemy zapłacić za szkolenie na podstawie wystawionej przez Was faktury pro forma?
Odpowiedź: Tak, zapisz się na szkolenie w normalny sposób, otrzymasz fakturę pro-forma.
Pytanie: jestem programistą, ale nie miałem do czynienia z bezpieczeństwem aplikacji webowych – czy dam sobie radę na szkoleniu?
Odpowiedź: Jak najbardziej, dodatkowo (jak każdy inny uczestnik) otrzymasz przed szkoleniem dostęp do zapisu filmowego 4-godzinnego szkolenia: wprowadzenie do bezpieczeństwa aplikacji webowych.
Pytanie: Czy na szkoleniu są warsztaty praktyczne?
Odpowiedź: Szkolenie ma postać pokazów praktycznych (plus oczywiście konieczna teoria). Uczestnicy mogą we własnym zakresie realizować zadania na naszej zamkniętej, praktycznej platformie szkoleniowej (dostępne są tam celowo podatne aplikacje). Platforma dostępna będzie minimum 2 miesięce po zakończeniu szkolenia.
Pytanie: czy moglibyśmy zorganizować takie szkolenie zamknięte? (tylko dla pracowników naszej firmy)
Odpowiedź: Tak, prosimy o kontakt: szkolenia@securitum.pl
Pytanie: zapomniałem o coś dopytać na szkoleniu, jak mogę skontaktować się z prowadzącym?
Odpowiedź: przez minimum pół roku dostępny będzie chat (dla każdego uczestnika) gdzie można skontaktować się z innymi uczestnikami (które dołączyły do chatu), a także z prowadzącym.
Pytanie: czy sesja Q&A jest nagrywana?
Odpowiedź: samo szkolenie jest nagrywane i udostępniane uczestnikom, ale sama sesja Q&A – nie jest.
O prowadzącym:
Kamil Jarosiński jest konsultantem ds. bezpieczeństwa IT w firmie Securitum. Posiada 6 lat doświadczenia w prowadzenia testów penetracyjnych oraz szkoleń z zakresu bezpieczeństwa aplikacji webowych. Pasjonat bezpieczeństwa systemów IT lubiący dzielić się wiedzą. Prelegent na konferencjach branżowych m.in: Mega Sekurak Hacking Party, uczestnik programów Bug Bounty.
Opinie uczestników o szkoleniu:
Najmocniejsze strony szkolenia to: holistyczne podejście do prezentowanego tematu, nastawienie na praktykę (live dema), wzorowy kontakt z uczestnikami szkolenia oraz dzielenie się unikalnymi poradami wynikającymi z doświadczenia trenera.
Super prowadzenie, bardzo ciekawa formuła - interaktywna i płynna, bez slajdów wszystko na żywo.
Duża ilość praktycznych przykładów, Informacja o przydatnych narzędziach do pracy.
Obszerna wiedza, sporo przykładów, możliwość konwersacji, streaming YT :)
Kompetentny prowadzący, przykłady podatności dotyczących współczesnych technologii, a nie rzeczy które były w php-ie w 2005 roku.
Oprócz przeanalizowania punktów OWASP, to każdy punk był przeanalizowany na demo.
Najciekawsze według mnie tematy były zaprezentowane w ciągu drugiego dnia szkolenia. Bardzo podobały mi się pokazy ataków na żywo (live dema). Pozytywnie zaskoczyło mnie to, że trener nie poprzestawał na jednym sposobie wykonania ataku - każdorazowo proponując kilka sposobów rozwiązania problemu.
Wszystkie przykłady były ciekawe i wyglądały na groźne i nieprzewidywalnie możliwe. Najbardziej pomocne, moim zdaniem, są informacje na temat jak się zabezpieczać przed i jakie są "typowe błędy" otwierające apki na ataki.
Wszystkie przedstawione tematy były dla mnie interesujące, jednak najciekawsze dla mnie był temat przedstawiający wykorzystanie podatności serializacji.
Masa ciekawych narzędzi do pracy.
Sekcja o kryptografii była super, spodziewałem się bardziej "standardowej" formuły.
Jak zwykle: CE-LU-JĄ-CO. Uczestniczenie w szkoleniach prowadzonych przez Michała Bentkowskiego to zawsze czysta przyjemność. Michał to prawdziwy profesjonalista o spokojnym i przyjaznym usposobieniu.
Bardzo dobrze, trener z dużą wiedzą w temacie i łatwością w przekazywaniu informacji.