Prezentacja z konferencji SECURE 2012 (Warszawa, 22-24.10.2012) Aplikacje to prawdziwa pięta achillesowa współczesnych systemów IT. Zarówno własne doświadczenia jak i dostępne opracowania wskazują, że w większości aplikacji, niezależnie od stosowanej technologii, można znaleźć poważne podatności. Na domiar złego – zewnętrzne zabezpieczenia (firewalle, IPS, WAF, itp.) mają ograniczoną skuteczność dla ochrony aplikacji. Ciągle, najlepszą metodą radzenia sobie z ewentualnymi podatnościami w eksploatowanych aplikacjach jest unikanie ryzyka, czyli wytwarzanie, bądź zamawianie oprogramowania, które nie posiada istotnych błędów bezpieczeństwa. Ale czy jest to możliwe w praktyce? Agenda: - Wprowadzenie do problemu - Kilka ciekawych przykładów - Krótko o nowych źródłach ryzyka (AJAX, HTML5, aplikacje mobilne, NFC, ...) - Przyczyny powstawania podatności we współczesnych aplikacjach. - Jak postępować w trakcie tworzenia lub zamawiania aplikacji, żeby ograniczyć możliwość powstania istotnych błędów? W szczególności krótko zostaną zaprezentowane ogólnodostępne narzędzia i dokumenty OWASP pomagające zbudować bezpieczne aplikacje (np.: ASVS - Application Security Verification Standard, OpenSAMM - Security Assurance Maturity Model, OWASP Cheat Sheets).

1. Bezpieczeństwo aplikacji
Czy musi być aż tak źle?
Wojciech Dworakowski
OWASP Poland Chapter Leader
OWASP SecuRing
2012-10-24
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. whoami
Wojciech Dworakowski
 Od 2003 - SecuRing
• Zarządzanie zespołem testującym bezpieczeństwo
aplikacji i systemów IT
 Od 2011 – OWASP Poland Chapter Leader
OWASP

3. Open Web Application Security Project
Misja: Poprawa stanu
bezpieczeństwa aplikacji
 100+ Local Chapters
 1500+ OWASP Members
 20000+ uczestników spotkań
Projekty: dokumentacja, narzędzia
OWASP w Polsce
 Od 2007
 Regularne spotkania w Krakowie i Warszawie
http://www.owasp.org/index.php/Poland
OWASP 3

4. Agenda
Bezpieczeństwo aplikacji – obecny stan
 Przykłady
Jak można to zrobić lepiej?
Jak może pomóc OWASP?
Podsumowanie
OWASP 4

5. Czy podatności w aplikacjach są faktycznym
problemem?
Verizon 2012 Data Breach Investigations Report
OWASP

6. Przykład 1: SQL injection
Aplikacja o znaczeniu strategicznym
Kilkadziesiąt tysięcy użytkowników
Projekt rozwijany od kilku lat, ok. 1 mln linii kodu
Testy penetracyjne blackbox  SQL injection
Przegląd kodu  sklejanie SQL
Usunięcie źródła problemu w praktyce niemożliwe
Łatanie  Testy  Kolejne podatności  Łatanie…
Koszt: Poprawki, wizerunek, spór z klientem
Wdrożenie poprawek, opóźnienie projektu
OWASP

7. Przykład 2: Kontrola dostępu
Aplikacja webowa
Testy penetracyjne  Całkowity brak kontroli
dostępu do danych
Developer twierdził że kontrola dostępu jest ale
„nie włączona”
„Włączenie” zajęło kilka tygodni
Po „włączeniu” – znalezione kolejne przypadki
Koszt: Opóźnienie, kary umowne, wizerunek
OWASP

8. Przykład 3: Aplikacja mobilna
Grafika: technabob.com
Uwierzytelnienie za pomocą PIN
Dodatkowo na urządzeniu dane w
postaci zaszyfrowanej
Klucz szyfrowania generowany na
podstawie PIN
Efekt
Klucz można crackować off-line
4 cyfry = 10 tys. prób = kilka minut
Koszt usunięcia: Zmiana algorytmu
(po wdrożeniu)
OWASP

9. Nowe technologie – nowe źródła zagrożeń
AJAX
HTML5
Aplikacje mobilne
NFC
Media społecznościowe
…
OWASP

10. Jak można to zrobić lepiej?
Rosnące koszty usuwania
podatności
Utrzymanie
Wdrażanie
Wytwarzanie
Projektowanie
Definiowanie Wpisanie bezpieczeństwa w cały
cykl rozwojowy aplikacji
SDLC (Secuity in Development Lifecycle)
OWASP

11. Od czego zacząć?
zagrożenia
Żeby planować
zabezpieczenia trzeba znać:
• zagrożenia
• scenariusze ataków
zabezpieczenia • potencjalne skutki
aktywa skutki
OWASP

12. • Zidentyfikowanie
zagrożeń • Wymagania
• Scenariusze dotyczące
ataków bezpieczeństwa
• Dobranie • Scenariusze
zabezpieczeń testowe
Niezbędne:
• Doświadczenie
• Umiejętność wczucia się w rolę atakującego
OWASP

13. Co dalej?
Przegląd projektu
Kontrola podczas implementacji
Testy bezpieczeństwa przed wdrożeniem
Szkolenie
• programistów
• PM-ów, architektów, testerów
OWASP

14. Testowanie bezpieczeństwa
• Niezbędne, bo może zawieść implementacja
założeń
• Na podstawie zidentyfikowanych zagrożeń
• Według ustalonych priorytetów
• NIE black-box !
• Pamiętaj o uwzględnieniu całego środowiska
• Atakowany jest cały system
a nie jeden element
• Połączenia z innymi systemami, biblioteki, framework
• Niezbędne doświadczenie
OWASP

15. Jak może pomóc OWASP?
DETECT PROTECT LIFE-CYCLE
Documentation Top10 Development Guide OpenSAMM
ASVS Secure Coding
Testing Guide Practices – Quick
Reference
Code Review
Guide
Tools WebScarab ESAPI WebGoat
Zed Attack Proxy AppSensor Education
JBroFuzz ModSecurity Core Project
Ruleset
~140+ Projektów
https://www.owasp.org/index.php/Category:OWASP_Project
OWASP

16. OpenSAMM
http://www.opensamm.org
Software Assurance Maturity Model
•Model dojrzałości dotyczący bezpieczeństwa w procesie
wytwarzania oprogramowania
•4 Business Functions x 3 Security Practices
•Każda z 12 „security practices” ma zdefiniowane 3
poziomy dojrzałości + poziom 0 jako punkt wyjściowy
OWASP
Źródło: www.owasp.org

17. OpenSAMM
http://www.opensamm.org
 Dla każdej praktyki / poziomu dojrzałości
(4x3x3) opisane są:
• Cel
• Czynności
• Pytania do audytu
• Rezultat wdrożenia
• Miara sukcesu
• Wpływ na koszty, niezbędny personel
OWASP

18. OWASP Application Security Verification
Standard (ASVS)
 Testowanie zabezpieczeń,
które chronią przed
typowymi zagrożeniami
 Celem oceny wg ASVS nie
jest poszukiwanie
podatności
 … ale sprawdzenie czy
istnieją odpowiednie
zabezpieczenia – zasady
dobrej praktyki
OWASP

19. OWASP ASVS – c.d.
Zastosowanie:
 Jako wzorzec – przy weryfikacji
(da się zastosować jako wzorzec audytowy)
 Jako wytyczne – dla developerów
 Jako specyfikacja – w kontraktach na
wykonanie aplikacji
Jest dostępny po polsku!
Owasp.org -> ASVS -> Downloads -> ASVS in Polish
http://owasp-asvs.googlecode.com/files/asvs-webapp-
release-2009-pl.pdf
OWASP

20. OWASP ASVS – Poziomy weryfikacji
Poziom 1 – Weryfikacja automatyczna
 1A – Dynamic Scan
 1B – Source Code Scan
Poziom 2 – Weryfikacja ręczna
 2A – Penetration Test
 2B – Code Review
Poziom 3 – Weryfikacja projektu
 L2 + wszystkie biblioteki i serwisy + weryfikacja projektu
Poziom 4 – Weryfikacja wewnętrzna
 L3 + framework, narzędzia, etc + weryfikacja możliwości
wprowadzenia złośliwego kodu
OWASP
Źródło: OWASP ASVS http://code.google.com/p/owasp-asvs/wiki/Approach

21. Podsumowanie
• Myśl o bezpieczeństwie!
• od planowania po wdrożenie i eksploatację systemu
• Zaplanuj bezpieczeństwo
• Identyfikacja zagrożeń
• Planowanie zabezpieczeń
• Testuj przed  Modelowanie zagrożeń
• … i po  Testy penetracyjne, przeglądy
konfiguracji, ...
• Niezbędne - doświadczenie i metnalność
atakującego
OWASP

22. Zapraszamy na spotkania OWASP Poland
 Wstęp wolny
 Streaming video
 Kraków
 Wstępny termin: 2012-11-21 (środa), 18:00
 Krakowski Park Technologiczny
Al. Jana Pawła II 41 L, III piętro
 Warszawa
https://www.owasp.org/index.php/Poland
Lista mailingowa
Facebook: OWASP Poland Local Chapter
Twitter: @owasppoland OWASP