Bezpieczeństwo aplikacji, czyli 5-ty element kompleksowego podejścia do ochrony firmowych danych
W tym tygodniu najbezpieczniejsze w Polsce Data Center, Beyond.pl, wystartowało ze swoją najnowszą kampanią edukacyjną “Bezpieczeństwo zaczyna się u podstaw” (link TUTAJ), do której zaproszono naszą firmę technologiczną jako eksperta w dziedzinie bezpieczeństwa aplikacji. Temat ciekawy, niełatwy i potrzebny. Dlatego postanowiliśmy go tutaj dla Was rozwinąć.
Jak zadbać o bezpieczeństwo aplikacji: TWORZYMY PLAN DZIAŁAŃ
Na początek wyjaśnijmy sobie jedno — bezpieczeństwo aplikacji nie wydarza się ot tak po prostu przez przypadek. Bezpieczeństwo trzeba przygotować, wdrożyć i co najważniejsze — aktualizować. Oznacza to, że zamiast zdawania się na własną intuicję, potrzebujemy planu, który nie zostawi miejsca na żadne “nie pomyślałem”/”it will never happen to me”.
Tak na marginesie, “mi się to nigdy nie przydarzy” - to słowa kapitana Titanica, EJ Smith’a, które padły tuż przed pierwszym i ostatnim wypłynięciem statku w rejs. Zatem już na etapie budowania aplikacji, zanim “wypłynie” ona w Sieci, absolutną podstawą jest uświadomienie sobie wszystkich możliwych zagrożeń i uwzględnienie ich w procesie projektowania.
Zalecaną praktyką jest tu zapoznanie się z listą wytycznych OWASP, czyli czymś co w środowisku programistycznym nazywane jest potocznie ”Open Web Application Testing Guide”. Zaufajcie nam — zgromadzone na niej możliwe błędy aplikacji, świetnie uświadomią Wam, co trzeba po kolei ująć w procesie budowania i staną się solidną podstawą planu działań.
Gdy już ją przejrzymy i uwzględnimy w aplikacji, kolejnym krokiem jest zaangażowanie zewnętrznej firmy do pentestów. Dlaczego kogoś z zewnątrz, skoro my też możemy pobawić się w hakera i sami próbować włamać i złamać wszystko co się da w naszej app’ce? To proste — my ją znamy. A skoro ją znamy, to nie spojrzymy na nią świeżym okiem. Nie będziemy mieć dystansu. Mimo solennych zapewnień (lub też “solonych” jeśli ktoś woli programistyczny żargon;) ) , podświadomie wszystko wyda nam się w porządku. Poważnie — nie bagatelizujcie tego kroku. Pentesty wskażą Wam luki w systemie, które szybko będziecie mogli wyeliminować i naprawdę lepiej, żeby wskazała Wam je zewnętrzna firma specjalizująca się w temacie niż prawdziwy haker.
Z kolei tym co zamyka plan jest niekończąca się opowieść: systematyczne testy i aktualizacje. Uwzględnienie ich w długoterminowym planie jest prawie tak ważne jak przygotowanie zabezpieczeń podczas budowy aplikacji, zatem w planie też je ujmijcie. Najlepiej od razu z konkretnymi datami i konkretną osobą, która ma być za nie odpowiedzialna w Waszej firmie. Niech wie o tym i niech raportuje. Brzmi jak banał, ale sami zapewne doskonale wiecie, że wyrobienie w praktyce dobrych nawyków to nie to samo, co wiedza o tym, że powinno się coś robić. Najczęściej tym, co zawodzi w systemach bezpieczeństwa jest właśnie czynnik ludzki. Nie bagatelizujcie tego.
OWASP
Jeżeli, słyszycie o OWASP (Open Web Application Security Project) po raz pierwszy, to najważniejsze, co powinniście zapamiętać to:
- tworzą ją niezależni programiści z całego świata, opisując obrazowo przypadki zagrożeń, na które wszystkie nigdy przenigdy sami byście nie wpadli,
- dostęp do listy wytycznych OWASP jest bezpłatny i zawsze otwarty (linki do stron wrzuciliśmy na dole artykułu),
- i tak, OWASP** ma osę w logo ;)
**osa w jęz. angielskim to wasp.
I tak dla przykładu trochę posłuchać możecie o najczęściej spotykanych błędach w tworzeniu aplikacji wg OWASP TOP 10 od naszego CTO, Łukasza Gajosa:
Ale błąd A1 — Injection (wstrzyknięcie zewnętrznego kodu do naszej aplikacji, które pozwala atakującemu np. zostać adminem na naszej platformie czy dowolnie doładować komuś konto prepaidem) czy A6. Sensitive Data Exposure (ekspozycja danych wrażliwych, takich jak numery kart kredytowych, haseł czy dat urodzenia, do której dochodzi, gdy ktoś wywołuje błąd w naszej aplikacji a my zamiast np. strony z kosmonautą “Error wywaliło cię w przestrzeń” pokazujemy mu całą konfigurację i fragment struktury aplikacji) to tylko koniuszek góry lodowej…
OWASP: Application Security Verification Standard
Standard ten to kompleksowa podstawa zadbania o bezpieczeństwo każdej aplikacji webowej. Co bardzo przydatne, wszystkie możliwe zagrożenia logicznie na niej pokategoryzowano, co ułatwia potraktowanie listy OWASP jako świetnego guidebook’a do testów bezpieczeństwa.
Wrzucamy tu wszystkie obowiązujące w OWASP Application Security Verification Standard 3.0.1 kategorie zagrożeń:
- V1: Architecture, design and threat modelling
- V2: Authentication Verification Requirements
- V3: Session Management Verification Requirements
- V4: Access Control Verification Requirements
- V5: Malicious input handling verification requirements
- V6: Output encoding/escaping
- V7: Cryptography at rest verification requirements
- V8: Error handling and logging verification requirements
- V9: Data protection verification requirements
- V10: Communications security verification requirements
- V11: HTTP security configuration verification requirements
- V12: Security configuration verification requirements
- V13: Malicious controls verification requirements
- V14: Internal secrutiy verification requirements
- V15: Business logic verification requirements
- V16: Files and resources verification requirements
- V17: Mobile verification requirements
- V18: Web services verification requirements
- V19. Configuration.
Jest tego sporo — to prawda. Niemniej jeżeli mowa o bezpieczeństwie, lepiej o czymś pomyśleć niż nie pomyśleć.
Przydatne linki:
https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf
