Java runtime takes care of security baselines but cross-site scripting, cross-site request forgery, and outdated third-party libraries still pose risks. The document recommends validating all input, escaping all output, using security libraries, implementing content security policies and anti-CSRF tokens, and testing dependencies and defenses. Developers are responsible for application security.

1. Java ist doch schon sicher?!
Entwicklertag - 21.05.2014!
Dominik Schadow - bridgingIT

3. Java Runtime
Backend
Services
Frontend

4. Java Runtime takes care of the security baseline

6. Cross-Site!
Scripting
Cross-Site!
Request Forgery
3rd party!
library usage

7. Cross-Site Scripting (XSS)

8. Access victims’ session credentials
Site defacement
Undermine CSRF defense
Redirects (phishing)
Load scripts
Data theft

9. Attacker injected code executed in web application
Attacker
Victim
Victim
DOM Based
XSS
Reflected
XSS
Stored
XSS

10. Always validate all input and escape all output

11. 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

12. 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

13. 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

14. Intercept requests/ responses with OWASP ZAP
www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

15. Demo

16. Content Security Policy as second layer of defense

17. Cross-Site Request Forgery (CSRF)

18. Using victims’ credentials to gain access

19. CSRF utilizes fire and forget requests
1
3
4
2

20. Stop fake requests with random anti CSRF tokens

21. 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

22. 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

23. Demo

24. 3rd party library usage

25. Code, libraries and configuration belong together

26. Test the functionality you rely on

27. Outdated libraries imply a false sense of security

28. Find insecure libs with OWASP Dependency Check
www.owasp.org/index.php/OWASP_Dependency_Check

29. Not every vulnerability may affect your application

30. Widespread outdated libs impose a greater risk

31. 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

32. 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