Wojciech DworakowskiWojciech Dworakowski
Projektowanie zabezpieczeń aplikacji nie tylko dla orłów. Projektowanie zabezpieczeń aplikacji nie tylko dla orłów. Case study e-płatnościCase study e-płatności
2
login: Wojciech Dworakowski
Testowanie i doradztwo dotyczące bezpieczeństwa aplikacji i systemów IT
od 2003 roku / ponad 300 systemów i aplikacji
OWASP Poland Chapter Leader Cel: Podnoszenie świadomości w zakresie
bezpieczeństwa aplikacji
3
Rosnące koszty usuwania błędów
Definiowanie
Projektowanie
Wytwarzanie
Wdrażanie
Utrzymanie
Dotyczy to również defektów bezpieczeństwa!
4
Definiowanie
• Identyfikacja ryzyka
• Do kluczowych ryzyk są dobierane zabezpieczenia
• Zdefiniowanie wymagań
Projektowanie
• Wymagania są weryfikowane w projekcie
Wykonanie
• Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych wymagań)
Wdrażanie
• Testy odbiorcze – w zakresie odpowiadającym przyjętym wymaganiom
Wymagania
Software Security Development Lifecycle
5
Definiowanie
• Identyfikacja ryzyka
• Do kluczowych ryzyk są dobierane zabezpieczenia
• Zdefiniowanie wymagań
Projektowanie
• Wymagania są weryfikowane w projekcie
Wykonanie
• Testy jednostkowe zabezpieczeń i poprawności kodu (według przyjętych wymagań)
Wdrażanie
• Testy odbiorcze – w zakresie odpowiadającym przyjętym wymaganiom
Wymagania
Szara rzeczywistość
• Brak założeń• Brak kwestii niefunkcjonalnych
(SQLi, XSS, CSRF, kontrola dostępu, logika, …)• Brak uwzględnienia realnych scenariuszy ataku
7
Płacenie za zakupy w sklepie aplikacją mobilną
Klient: Wybiera „ZAPŁAĆ” w swojej aplikacji mobilnej. Generowany jest KOD.
Kasjer: Wprowadza KOD i kwotę do aplikacji kasowej
Klient: Akceptuje transakcję w swojej aplikacji mobilnej
9
Aktywacja aplikacji przez Klienta
W aplikacji operatora:
Podaje nr telefonu i skojarzony rachunek / nr karty / …
Ustala PIN (hasło do aplikacji) Generuje KOD STARTOWY
W aplikacji mobilnej:
Wprowadza NR TELEFONU i KOD STARTOWY
10
Rejestracja sklepu
Manager sklepu: Wprowadza dane sklepu i nr rachunku rozliczeniowego w aplikacji operatora
26
Podsumowanie
Modelowanie zagrożeń daje:
Wyeliminowanie błędów projektowych Wymagania odnośnie bezpieczeństwa Dopasowanie zabezpieczeń do ryzyk Uwzględnienie najistotniejszych
zagrożeń i ryzyk Wyzwala myślenie o bezpieczeństwie
27
Podsumowanie (c.d)
Modelowanie zagrożeń nie daje:
Pewności że nie ma defektów bezpieczeństwa
Mogą zostać wprowadzone na etapie implementacji
Jako uzupełnienie:
OWASP ASVS (Application Security Verification Standard)
Zasady dobrej praktyki – lista kontrolna
28
Dziękuję za uwagę
http://www.securing.pl e-mail: [email protected] Górka 14a 30-224 Krakówtel. (12) 4252575fax. (12) 4252593
Wojciech [email protected]. 506 184 550