Java ist doch schon sicher?!

615 Aufrufe

Veröffentlicht am

Vortrag von Dominik Schadow auf dem Entwicklertag in Karlsruhe am 21.05.2014

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
615
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
10
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Java ist doch schon sicher?!

  1. 1. Java ist doch schon sicher?! Entwicklertag - 21.05.2014! Dominik Schadow - bridgingIT
  2. 2. Java Runtime Backend Services Frontend
  3. 3. Java Runtime takes care of the security baseline
  4. 4. Cross-Site! Scripting Cross-Site! Request Forgery 3rd party! library usage
  5. 5. Cross-Site Scripting (XSS)
  6. 6. Access victims’ session credentials Site defacement Undermine CSRF defense Redirects (phishing) Load scripts Data theft
  7. 7. Attacker injected code executed in web application Attacker Victim Victim DOM Based XSS Reflected XSS Stored XSS
  8. 8. Always validate all input and escape all output
  9. 9. Libraries for Cross-Site Scripting countermeasures Coverity Security Library
 github.com/coverity/coverity-security-library OWASP Java Encoder
 www.owasp.org/index.php/OWASP_Java_Encoder_Project Output escaping OWASP HTML Sanitizer
 www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project Allow selected HTML tags/ attributes
  10. 10. Content Security Policy is framework independent Blocks ALL inline scripts response.setHeader("Content-Security-Policy", "default-src 'self'; img-src *; object-src applets.sample.de; script-src scripts.sample.com; style-src *.sample.com"); Whitelist valid resource URLs response.setHeader("Content-Security-Policy- Report-Only", "default-src 'self'; report-uri CSPReporting"); Report only as test mode www.w3.org/TR/CSP
  11. 11. Session-Cookie protection via web.xml <?xml version="1.0" encoding="UTF-8"?>
 <web-app ... version="3.1">
 <!-- ... -->
 <session-config>
 <session-timeout>30</session-timeout>
 <cookie-config>
 <http-only>true</http-only>
 </cookie-config>
 <tracking-mode>COOKIE</tracking-mode>
 </session-config>
 </web-app> Tomcat 7
  12. 12. Intercept requests/ responses with OWASP ZAP www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
  13. 13. Demo
  14. 14. Content Security Policy as second layer of defense
  15. 15. Cross-Site Request Forgery (CSRF)
  16. 16. Using victims’ credentials to gain access
  17. 17. CSRF utilizes fire and forget requests 1 3 4 2
  18. 18. Stop fake requests with random anti CSRF tokens
  19. 19. CSRF protection in libraries and frameworks JavaServer Faces (improved in 2.2)
 jcp.org/en/jsr/detail?id=344 Built-in protection Spring Security 3.2
 projects.spring.io/spring-security Enterprise Security API
 www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API CSRF extension
  20. 20. Test your CSRF protection with faked tokens www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
 addons.mozilla.org/en-US/firefox/addon/groundspeed
  21. 21. Demo
  22. 22. 3rd party library usage
  23. 23. Code, libraries and configuration belong together
  24. 24. Test the functionality you rely on
  25. 25. Outdated libraries imply a false sense of security
  26. 26. Find insecure libs with OWASP Dependency Check www.owasp.org/index.php/OWASP_Dependency_Check
  27. 27. Not every vulnerability may affect your application
  28. 28. Widespread outdated libs impose a greater risk
  29. 29. Developers make the difference Java is as (in)secure as most other languages Java can’t prevent every development bug (Web) application security is always the developers’ job
  30. 30. Dominik Schadow" BridgingIT GmbH
 Königstraße 42
 70173 Stuttgart dominik.schadow@bridging-it.de 
 www.bridging-it.de " Blog blog.dominikschadow.de
 Twitter/ADN @dschadow Demo Projects
 github.com/dschadow/JavaSecurity" OWASP
 www.owasp.org" Pictures
 www.dreamstime.com

×