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

OWASP

http://www.owasp.org

Bezpieczeństwo aplikacji Czy musi być aż tak źle?

Wojciech Dworakowski

OWASP Poland Chapter Leader

SecuRing 2012-10-24

OWASP

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 4

Agenda

Bezpieczeństwo aplikacji – obecny stan

Przykłady

Jak można to zrobić lepiej?

Jak może pomóc OWASP?

Podsumowanie

OWASP

Czy podatności w aplikacjach są faktycznym problemem?

Verizon Data Breach Report Investigations 2010

OWASP

Przykład 1: SQL injection

Aplikacja o znaczeniu strategicznym

Kilkadziesiąt tysięcy użytkowników

Blisko 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: Łatanie, wizerunek, spór z klientem

OWASP

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

Przykład 3: Aplikacja mobilna

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)

Gra

fika

: te

chn

ab

ob

.co

m

OWASP

Nowe technologie – nowe źródła zagrożeń

AJAX

HTML5

Aplikacje mobilne

NFC

…

OWASP

Jak można to zrobić lepiej?

Definiowanie

Projektowanie

Wytwarzanie

Wdrażanie Utrzymanie

Rosnące koszty usuwania podatności

Rosnące koszty usuwania

podatności

Wpisanie bezpieczeństwa w cały

cykl rozwojowy aplikacji SDLC (Secuity in Development Lifecycle)

OWASP

Od czego zacząć?

[rysunek: Zagrożenie / Ryzyko / Podatność / Zabezpieczenie]

Żeby planować zabezpieczenia trzeba znać zagrożenia

• …i wpływ na ryzyko

OWASP

Modelowanie zagrożeń

• Zidentyfikowanie zagrożeń

• Scenariusze ataków

• Dobranie zabezpieczeń

• Założenia dotyczące bezpieczeństwa

• Scenariusze testowe

Mo

delo

wa

nie

zag

rożeń

Niezbędne:

• Doświadczenie

• Umiejętność wczucia się w rolę atakującego

OWASP

Co dalej?

Kontrola podczas implementacji

Testy przed wdrożeniem

Szkolenie programistów

Również PM-ów, architektów, testerów

OWASP

Testowanie bezpieczeństwa

• Ważne - bo może zawieść implementacja założeń

• Na podstawie zidentyfikowanych zagrożeń

• Wg priorytetów

• NIE black-box !

• Pamiętaj o uwzględnieniu całego środowiska

• Atakowany jest cały system a nie jeden komputer / serwer / aplikacja / urządzenie / …

• Niezbędne doświadczenie

OWASP

Jak może pomóc OWASP?

DETECT PROTECT LIFE-CYCLE

Documentation Top10

ASVS

Testing Guide

Code Review Guide

Development Guide

Secure Coding Practices – Quick Reference

OpenSAMM

Tools WebScarab

Zed Attack Proxy

JBroFuzz

ESAPI

AppSensor

ModSecurity Core Ruleset

WebGoat

Education Project

~140+ Projektów https://www.owasp.org/index.php/Category:OWASP_Project

OWASP

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

OpenSAMM http://www.opensamm.org

Źródło: www.owasp.org

OWASP

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

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

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

OWASP ASVS – Poziomy weryfikacji

Źródło: OWASP ASVS http://code.google.com/p/owasp-asvs/wiki/Approach

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 + modelowanie zagrożeń i weryfikacja

projektu

Poziom 4 – Weryfikacja wewnętrzna

L3 + framework, narzędzia, etc + weryfikacja możliwości wprowadzenia

złośliwego kodu

OWASP

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 mentalność atakującego

OWASP

Zapraszamy na spotkania OWASP Poland

Wstęp wolny

Streaming

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

TBD

https://www.owasp.org/index.php/Poland Lista mailingowa

Facebook: OWASP Poland Local Chapter

Twitter: @owasppoland