W trakcie swojej prezentacji poruszę problematykę utrzymania bezpieczeństwa aplikacji po wdrożeniu produkcyjnym z perspektywy dostawcy aplikacji. Na przykładowych aplikacjach (platforma SaaS, aplikacja tworzona zwinnie, aplikacja tworzona w waterfall) pokażę wyzwania z tym związane, w odniesieniu do konkretnej aplikacji oraz realiów, w jakich funkcjonuje. Wspólnie z uczestnikami przeanalizujemy możliwe mechanizmy mające na celu utrzymanie bezpieczeństwa aplikacji. Zastanowimy się nad optymalnym ich doborem oraz momentem, w którym warto z nich skorzystać, uwzględniając również koszt wykorzystania danego mechanizmu. Przyjrzymy się mechanizmom takim jak: • testy penetracyjne • konsultacje/szkolenia • definiowanie wymagań dotyczących bezpieczeństwa aplikacji • obsługa incydentów • narzędzia automatyczne • monitorowanie podatności w wykorzystywanych komponentach Postaramy się również wypracować odpowiedzi na poniższe pytania: • Co można zrobić wewnętrznie? • Jakie prace zlecić? • Jakich kompetencji poszukać? • Jak dobrać szkolenia? • Jakiego typu narzędzi poszukać? Chciałbym dać uczestnikom proste recepty na to, jak zadbać o utrzymanie bezpieczeństwa aplikacji, z którymi pracują.

1. Mateusz Olejarka
OWASP ASVS – ściągawka z
bezpieczeństwa dla programisty

2. Login:
OWASP Poland Chapter Board Member
Testy penetracyjne aplikacji webowych i mobilnych,
konsultacje, szkolenia.

4. Bank

5. Co wiemy?
„Razor4 twierdzi, ze do serwerów banku dostał
się pod koniec stycznia poprzez nieujawniony
błąd wynikający z braku regularnych aktualizacji
oprogramowania.”
„wstawił odwołanie do skryptu JS umieszczonego
na swoim serwerze, dzięki któremu mógł
modyfikować numery rachunków na które
przekazywane były przelewy klientów banku”
Przyczyna:
„Dziurawy” komponent
aplikacji

6. Bank + Telekom
Źródło: https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-
bankowe-klientow-sieci-play/
Przyczyna:
Do uwierzytelnienia się
do obu aplikacji
wystarczyły tylko login i
hasło

7. Instagram
Źródło: https://www.hackread.com/instagram-hacked-
researcher-gets-admin-panel-access/

8. Przyczyna:
Interfejs administracyjny
dostępny z sieci
publicznej

9. eBay
Źródło: http://www.securityweek.com/xss-flaw-exposed-ebay-users-phishing-
attacks
Przyczyna:
Serwis umożliwia używanie
JavaScript inline

10. Połączenia SSL do Facebooka
Źródło: https://www.facebook.com/notes/protect-the-
graph/analyzing-forged-ssl-certificates-in-the-
wild/1451429791763834/
Przyczyna:
Przeglądarka nie wykryła
braku HTTPS lub
sfałszowanego certyfikatu

11. Czy w tych wypadkach developerzy nie myśleli o
bezpieczeństwie?
Przecież te instytucje nie zatrudniają jednych z
najlepszych specjalistów!
Czy nie było testów bezpieczeństwa?

12. Bezpieczeństwo aplikacji ?
„Aplikacja ma opierać się
atakom i przetwarzać dane w
sposób bezpieczny, zgodnie
zasadami dobrej praktyki.
Scenariusze testów
bezpieczeństwa mają
odpowiadać współczesnym
zagrożeniom i metodom
ataków”
Czy dobrze określiliśmy
co to znaczy
„bezpieczeństwo”?
Co to w praktyce
znaczy?
Czy da się rozliczyć taką
usługę?

13. APPLICATION SECURITY
VERIFICATION STANDARD

14. OWASP ASVS
• Lista wymagań lub testów dotyczących
bezpieczeństwa aplikacji
• Może być używana przez architektów,
programistów, testerów, specjalistów
bezpieczeństwa, użytkowników końcowych w
celu zdefiniowania czym jest bezpieczna
aplikacja

15. Historia
• 2009: V 1.0 przetłumaczona na polski
• 2014: V 2.0 przetłumaczona (tylko lista)
• 2015: V 3.0

16. Możliwości użycia ASVS

17. Poziomy ASVS
Level 1:
Minimum
Wszystkie aplikacje Podatności które są
łatwe do wykrycia,
z listy OWASP Top
10 lub podobnych.
Level 2:
Standard
Aplikacje
przetwarzające dane
wrażliwe
Większość ryzyk
związanych z
aplikacjami
Level 3:
Enchanced
Naruszenie może
powodować b.duże
straty
j.w. + zasady
bezpiecznego
projektowania

18. Obszary ASVS
Architecture,
design and
threat modeling
Authentication
Session
management
Access control
Malicious input
handling
Cryptography at
rest
Error handling
and logging
Data protection
Communications
HTTP security
configuration
Malicious
controls
Business logic
Files and
resources
Mobile Web services Configuration

19. Str 14 „Applying ASVS in Practice”
• Finance and Insurance
• Manufacturing, professional,
transportation, technology,
utilities, infrastructure, and
defense
• Healthcare
• Retail, food, hospitality

20. • Podstawa do stworzenia listy zasad
bezpieczeństwa uwzględniającej specyfikę
aplikacji, organizacji i platformy.
• Przed zastosowaniem wskazana jest analiza
bezpieczeństwa aplikacji / procesu
• Deklaracja stosowania + rozszerzenia
img src: http://www.rmgnetworks.com/blog/bid/365859/Internal-communications-is-not-one-size-fits-all

21. CO NOWEGO W ASVS 3.0

22. Najważniejsze zmiany
• Uporządkowanie i deduplikacja
• Usunięcie wymagań/testów które miały
znikomy wpływ na bezpieczeństwo
• Dostosowanie do nowych technologii (REST,
HTML5, itp.)
• Nowe sekcje: WebServices, Configuration
• Promuje użycie zabezpieczeń, które są
dostępne od dłuższego czasu (2FA, CSP, HSTS)

23. PODSUMOWANIE

24. Bank

25. Bank + Telekom
Źródło: https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-
bankowe-klientow-sieci-play/

26. Instagram
Źródło: https://www.hackread.com/instagram-hacked-
researcher-gets-admin-panel-access/

27. eBay
Źródło: http://www.securityweek.com/xss-flaw-exposed-ebay-users-phishing-
attacks

28. Połączenia SSL do Facebooka
Źródło: https://www.facebook.com/notes/protect-the-
graph/analyzing-forged-ssl-certificates-in-the-
wild/1451429791763834/

29. Podsumowanie
• ASVS 3.0:
• Wywołanie zmian
– Stosowanie mechanizmów od dawna istniejących
w przeglądarkach
– Dobre praktyki dotyczące architektury i
konfiguracji
• Uporządkowanie wielu kwestii

30. Standaryzacja jest potrzebna …
… ale nie rozwiązuje wszystkich problemów

31. Q & A

32. • Czy można dostać certyfikat?
• Czy są jakieś wytyczne co do zawartości
raportu z testów?
• Czy są wytyczne co do metodyki (automaty,
pentesting, code review, blackbox /
whitebox)?

33. • Kiedy będzie polska wersja?
• Gdzie mogę zgłaszać zmiany, błędy? Jak mogę
się włączyć?
https://www.owasp.org/index.php/Category:OWASP_Applica
tion_Security_Verification_Standard_Project
– Email list
– Github: https://github.com/OWASP/ASVS -> Issues

34. • WWW: https://www.owasp.org/index.php/Poland
• Mailing list: https://lists.owasp.org/mailman/listinfo/owasp-poland
34
http://www.meetup.com/owasp-poland/
https://www.linkedin.com/groups/OWASP-Poland-8179731
@owasppoland
https://www.facebook.com/pages/OWASP-Poland-Local-Chapter