Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zagrożenia dla aplikacji bankowych i sposoby zmniejszania ryzyka

1,763 views

Published on

Published in: Technology
  • If you’re struggling with your assignments like me, check out ⇒ www.HelpWriting.net ⇐. My friend sent me a link to to tis site. This awesome company. After I was continuously complaining to my family and friends about the ordeals of student life. They wrote my entire research paper for me, and it turned out brilliantly. I highly recommend this service to anyone in my shoes. ⇒ www.HelpWriting.net ⇐.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Zagrożenia dla aplikacji bankowych i sposoby zmniejszania ryzyka

  1. 1. Zagrożenia dla aplikacji bankowychi sposoby zmniejszania ryzyka Wojciech Dworakowski
  2. 2. Agenda Czy współczesne aplikacje są bezpieczne? Jakie są przyczyny powstawania podatności? Jakie są możliwości ograniczania ryzyka? 2
  3. 3. Czy współczesne aplikacje są „bezpieczne”?Większość aplikacji posiada istotne podatności (o znacznymwpływie na ryzyko)Dotyczy to zwłaszcza aplikacji webowych  Pięta achillesowa współczesnych systemów IT Threat rank N of Vulns N of Sites N of Sites % Sites Urgent 8918 2287 9.14% 18.77% Critical 44669 5511 45.79% 45.22% High 35375 8807 36.26% 72.27% Medium 4908 4455 5.03% 36.56% Low 3663 3618 3.75% 29.69% 24678 aplikacji przebadanych metodami testu penetracyjnego black-box, white-box oraz skanerami automatycznymi w roku 2008 (8 różnych firm) Źródło: WASC Web Application Secuirty Statistics http://projects.webappsec.org/Web-Application-Security-Statistics 3
  4. 4. Z własnych doświadczeńTesty najczęściej są zamawiane tuż przed wdrożeniemprodukcyjnym  W większości przypadków tylko testy penetracyjne  Często jest to jedyna forma weryfikacji bezpieczeństwaKluczowe podatności znajdujemy w ok. 70% badanychaplikacji 4
  5. 5. Czy podatności w aplikacjach są faktycznym problemem?Verizon Data Breach Report Investigations 2010http://www.verizonbusiness.com/resources/reports/rp_2010-data-breach-report_en_xg.pdf  Dane Verizon i US Secret Service  7 lat, 1700+ incydentów, >900 mln naruszonych rekordów danych 5
  6. 6. Co jest celem intruza?Verizon Data Breach Report Investigations 2010 6
  7. 7. 7 Verizon Data Breach Report Investigations 2010Najgroźniejsze podatności w aplikacjach
  8. 8. Przykłady – Błędna implementacja Podgląd lub modyfikacja transakcji innych użytkowników – Manipulacja identyfikatorem transakcji na formatce podglądu / edycji transakcji Obejście konieczności autoryzowania transakcji kodem SMS – Manipulacja logiką aplikacji – Przeskoczenie wymaganego kroku 8
  9. 9. Przykłady – Błędna implementacja Obejście limitów transakcyjnych Rozesłanie wrogiego kodu do innych użytkowników aplikacji Atak na aplikacje „back office” przy użyciu interfejsu „front office” 9
  10. 10. Przykłady – Błędne założenia Założenie – Autoryzacja operacji przy użyciu karty chipowej uniemożliwia atak przy zastosowaniu wrogiego kodu na stacji użytkownika Błąd – W niektórych implementacjach oprogramowanie sterownika karty zapamiętuje PIN wprowadzony przez użytkownika – Po pierwszym użyciu karty użytkownik nie musi wprowadzać PIN przy kolejnych operacjach z użyciem karty – Karta jest używana również do uwierzytelniania się („zalogowania”) Skutek – Wrogi kod / wroga strona mogą sfałszować transakcję i zostanie ona automatycznie podpisana bez wiedzy użytkownika – Zabezpieczenie jest nieskuteczne 10
  11. 11. Przykłady – Błędne założenia Autoryzacja transakcji przy użyciu kodu SMS Założenie – Telefon komórkowy jest urządzeniem zaufanym – Nie były znane masowe ataki na telefony komórkowe – Intruz musi przejąć kontrolę zarówno nad komputerem jak i telefonem użytkownika 11
  12. 12. Man in the MobileGrafika: ingbank.pl, cert.pl 12
  13. 13. Man in the MobileUwaga: Każda bankowość internetowa jest podatna na tegotypu atak  (wykorzystująca telefon do autoryzacji operacji)To nie zależy od banku i rodzaju bankowości internetowej !Istotą ataku jest nieświadomy użytkownik i jego „zarażony”komputer  Wrogi kod na komputerze skłania użytkownika do podania nr tel.  Instalacja wrogiego kodu na telefonie (za zgodą użytkownika) 13
  14. 14. Przyczyny
  15. 15. Źródła problemów - Technologia Stosunkowo młoda dziedzina oprogramowania bazująca na „starych” technologiach – HTTP/HTML nie były projektowane jako technologie do obsługi aplikacji – Nie tworzono ich z myślą o bezpieczeństwie Tradycyjne środki zabezpieczające (Firewall, IDS) nie sprawdzają się Środowiska tworzenia i uruchamiania aplikacji nie są odporne „by design” – niezależnie od tego co mówią ulotki dostawców oprogramowania 15
  16. 16. Źródła problemów – Świadomość wykonawców Niski poziom wiedzy programistów w zakresie bezpieczeństwa aplikacji Brak uwzględnienia bezpieczeństwa w procesie wytwarzania oprogramowania Brak wewnętrznych standardów „bezpiecznego programowania” Brak testów wewnętrznych 16
  17. 17. Źródła problemów – Wzrost potrzebNowe technologie  Aplikacje mobilne, Cloud computing, Web Services, …  Brak wytycznych odnośnie bezpieczeństwa aplikacji  Maleje „time to market”  Rośnie funkcjonalność  Maleje bezpieczeństwo Bezpieczeństwo Złożoność 17
  18. 18. „Wishful thinking”Zamawiający Wykonawca• Wykonawcą jest doświadczona • Zatrudniamy doświadczonych firma, z pewnością wiedzą co programistów, z pewnością robią wiedzą co robią• Ich oprogramowania używają • Nasze nowoczesne narzędzia duże firmy – oni nie pozwoliliby (famework, biblioteki) nie pozwolą sobie na niską jakość na wykorzystanie ewentualnych niedoskonałości• Testy bezpieczeństwa zaplanujemy N dni wstecz od • Nie otrzymaliśmy żadnych wdrożenia produkcyjnego / szczegółowych wytycznych – pilotażowego Pewnie ryzyko będzie ograniczone innymi metodami• Raczej nie będzie żadnych opóźnień 18
  19. 19. Syndrom „gumowego” czasu Zależność „finish to start”Testy funkcjonalne Testy Pilotaż bezpieczeństwa Go live Poprawki ! Usunięte podatności 19
  20. 20. Ograniczanie ryzyka
  21. 21. Możliwości ograniczania ryzykaReaktywne  Ograniczenie skutków  Zabezpieczenia techniczne: Firewall, IDS/IPS, WAF, …  Monitorowanie logów  Systemy „fraud detection”Proaktywne  Eliminacja przyczyn  Testowanie bezpieczeństwa aplikacji – Testy penetracyjne, Przeglądy kodu źródłowego  Eliminacja zbędnych danych i funkcji  Uwzględnienie bezpieczeństwa w cyklu rozwojowym aplikacji 21
  22. 22. Systemy „fraud detection”Wykrywanie nietypowych zdarzeń  Nierealne scenariusze korzystania z instrumentów płatniczych – Np. Zwiększona liczba przelewów w krótkim okresie czasu  Wykrywanie wzorców powtarzających się dla wielu klientów w krótkim okresie czasu Skuteczność systemu Fałszywe alarmy Ilość wykrywanych zdarzeń Koszty obsługi 22
  23. 23. Testowanie bezpieczeństwa aplikacjiDobre zrozumienie testowanej aplikacji  Identyfikacja zagrożeń przed rozpoczęciem testów  Modelowanie zagrożeńOgraniczone możliwości zastosowania narzędziautomatycznych  Automat nie jest w stanie „zrozumieć” logiki aplikacji  Nie umie rozróżnić danych „moich” od „cudzych”Produktem nie jest sam test ale raport  Forma zrozumiała nie tylko dla specjalistów  Raportowanie istotnych podatności na bieżąco 23
  24. 24. Przeglądy kodu źródłowegoProblem: Mało czasu / dużo koduNarzędzia automatyczne  Do wykrywania prostych podatności  Z reguły generują dużo „fałszywych alarmów”  Raport z narzędzi musi być zweryfikowany przez specjalistęWywiad z przedstawicielami wykonawcy  Każde twierdzenie jest sprawdzane w kodzie (dowody)  Poszukiwanie podatności czy weryfikacja stosowania dobrych praktyk?  Lista kontrolna OWASP ASVS 24
  25. 25. Dziękuję za uwagę Wojciech Dworakowski wojciech.dworakowski@securing.pl Tel.: 12 425 25 75, 506 184 550 25

×