OWASP Security Top Ten and ways to prevent them in Java EE

1. OWASP Security Top Ten
OWASP top ten
www.xebia.fr / blog.xebia.fr

2. OWASP Security Top Ten
 This presentation is based on
OWASP Top 10 For Java EE
The Ten Most Critical Web Application Security
Vulnerabilities For Java Enterprise Applications
http://www.owasp.org/index.php/Top_10_2007
2

3. Cross Site Scripting (XSS)
www.xebia.fr / blog.xebia.fr

4. Cross Site Scripting (XSS)
 What ?
 Subset of HTML injections
 Data provided by malicious users are rendered in web pages and
execute scripts
 Goal ?
 Hijack user session, steal user data, deface web site, etc
 Sample
 lastName: Cyrille "><script ... />
4

5. Cross Site Scripting (XSS)
How to prevent it ?
 Input Validation : JSR 303 Bean Validation
public class Person {
@Size(min = 1, max = 256)
private String lastName;
@Size(max = 256)
Be
an
@Pattern(regexp = ".+@.+.[a-z]+")
private String email;
...
}
@Controller("/person")
public class PersonController {
C
@RequestMapping(method=RequestMethod.POST)
on
tro
public void save(@Valid Person person) {
lle
r
// ...
}
}
5

6. Cross Site Scripting (XSS)
How to prevent it ?
 HTML output escaping
 JSTL
<h2>Welcome <c:out value="${person.lastName}" /></h2>
 Expression language danger DO NOT ESCAPE !!!
JS T e
N
P sc
O
EL a
<h2>Welcome ${person.lastName} NOT ESCAPED !!!
do e !
</h2>
es !!
p
 Spring MVC
» Global escaping
<web-app>
<context-param>
<param-name>defaultHtmlEscape</param-
name>
<param-value>true</param-value>
</context-param>
...
</web-app>
» Page level
<spring:htmlEscape defaultHtmlEscape="true" />
6

7. Cross Site Scripting (XSS)
How to prevent it ?
 Use HTTP Only cookies
 Cookies not accessible via javascript
 Introduced with Servlet 3.0
N igu SI
co JSE
o
nf S
w rati NI
eb o D
cookie.setHttpOnly(true);
.x n f
m or
l
O
 Since Tomcat 6.0.20 for session cookies
<Context useHttpOnly="true">
...
</Context>
 Manual workaround
response.setHeader("set-cookie", "foo=" + bar + "; HttpOnly");
7

8. Cross Site Scripting (XSS)
How to prevent it ?
 Do not use blacklist validation but blacklist
 Forbidden : <script>, <img>
 Prefer wiki/forum white list style: [img], [url], [strong]
8

9. Injection Flaws
www.xebia.fr / blog.xebia.fr

10. Injection Flaws
 What ?
 Malicious data provided by user to read or modify sensitive data
 Types of injection : SQL, Hibernate Query Language (HQL), LDAP,
XPath, XQuery, XSLT, HTML, XML, OS command injection, HTTP
requests, and many more
 Goal ?
 Create, modify, delete, read data
 Sample
 lastName: Cyrille "; INSERT INTO
MONEY_TRANSFER ...
10

11. Injection Flaws
How to prevent it ?
 Input validation
 XSD with regular expression, min and max values, etc
 JSR 303 Bean Validation
11

12. Injection Flaws
How to prevent it ?
 Use strongly typed parameterized query API
 JDBC
preparedStatement.setString(1, lastName);
 JPA
query.setParameter("lastName", lastName);
 HTTP
GetMethod getMethod = new GetMethod("/findPerson");
getMethod.setQueryString(new NameValuePair[]{new NameValuePair("lastName", lastName)});
 XML
Element lastNameElt = doc.createElement("lastName");
lastNameElt.appendChild(doc.createTextNode(lastName));
 XPath :-(
12

13. Injection Flaws
How to prevent it ? Ca
uti
on
!
 If not, use escaping libraries very cautiously !!!
 HTML
"<h2> Hello " + StringEscapeUtils.escapeHtml(lastName) + " </h2>";
 Javascript
"lastName = ‘" + StringEscapeUtils.escapeJavaScript(lastName) + "’;";
 HTTP
"/findPerson?" + URLEncoder.encode(lastName, "UTF-8");
 XML
"<lastName>" + StringEscapeUtils.escapeXml(lastName) + "</
lastName>";
 Don’t use simple escaping functions !
StringUtils.replaceChars(lastName, "’", "’’");
13

14. Injection Flaws
How to prevent it ?
 Don’t use dynamic queries at all !
if (StringUtils.isNotEmpty(lastName)) {
jpaQl += " lastName like '" + lastName + "'";
}
if (StringUtils.isNotEmpty(lastName)) {
C
JP ia
rit
criteria.add(Restrictions.like("lastName", lastName));
A AP
er
2
}
I
Map<String, Object> parameters = new HashMap<String, Object>();
JP
A
if (StringUtils.isNotEmpty(lastName)) {
1
jpaQl += " lastName like :lastName ";
Q
ue
parameters.put("lastName", lastName);
ry
}
AP
I
Query query = entityManager.createQuery(jpaQl);
for (Entry<String, Object> parameter : parameters.entrySet()) {
query.setParameter(parameter.getKey(), parameter.getValue());
}
14

15. Injection Flaws
How to prevent it ?
 Enforce least privileges
 Don’t be root
 Limit database access to Data Manipulation Language
 Limit file system access
 Use firewalls to enter-from / go-to the Internet
15

16. Malicious File Execution
www.xebia.fr / blog.xebia.fr

17. Malicious File Execution
 What ?
 Malicious file or file path provided by users access files
 Goal ?
 Read or modify sensitive data
 Remotely execute files (rootkits, etc)
 Sample
 pictureName: ../../WEB-INF/web.xml
17

18. Malicious File Execution
How to prevent it ?
 Don’t build file path from user provided data
String picturesFolder = servletContext.getRealPath("/pictures") ;
String pictureName = request.getParameter("pictureName");
File picture = new File((picturesFolder + "/" + pictureName));
 Don’t execute commands with user provided data
Runtime.getRuntime().exec("imageprocessor " + request.getParameter("pictureName"));
 Use an indirection identifier to users
 Use firewalls to prevent servers to connect to outside sites
18

19. Insecure Direct Object Reference
www.xebia.fr / blog.xebia.fr

20. Insecure Direct Object Reference
 What ?
 Transmit user forgeable identifiers without controlling them server side
 Goal ?
 Create, modify, delete, read other user’s data
 Sample
<html><body>
<form name="shoppingCart">
<input name="id" type="hidden" value="32" />
...
</form>
</body><html>
ShoppingCart shoppingCart = entityManager.find(ShoppingCart.class, req.getParameter("id"));
20

21. Insecure Direct Object Reference
How to prevent it ?
 Input identifier validation
 reject wildcards (“10%20”)
 Add server side identifiers
Criteria criteria = session.createCriteria(ShoppingCart.class);
criteria.add(Restrictions.like("id", request.getParameter("id")));
criteria.add(Restrictions.like("clientId", request.getRemoteUser()));
ShoppingCart shoppingCart = (ShoppingCart) criteria.uniqueResult();
 Control access permissions
 See Spring Security
21

22. Insecure Direct Object Reference
How to prevent it ?
 Use server side indirection with generated random
String indirectId = accessReferenceMap.getIndirectReference(shoppingCart.getId());
<html><body>
<form name="shoppingCart">
<input name="id" type="hidden" value="${indirectId}" />
...
</form>
</body><html>
String indirectId = request.getParameter("id");
String id = accessReferenceMap.getDirectReference(indirectId);
ShoppingCart shoppingCart = entityManager.find(ShoppingCart.class, id);
 See org.owasp.esapi.AccessReferenceMap
22

23. Cross Site Request Forgery (CSRF)
www.xebia.fr / blog.xebia.fr

24. Cross Site Request Forgery (CSRF)
 What ?
 Assume that the user is logged to another web site and send a
malicious request
 Ajax web sites are very exposed !
 Goal ?
 Perform operations without asking the user
 Sample
http://mybank.com/transfer.do?
amount=100000&recipientAccount=12345
24

25. Cross Site Request Forgery (CSRF)
How to prevent it ?
 Ensure that no XSS vulnerability exists in your
application
 Use a random token in sensitive forms
<form action="/transfer.do">
<input name="token" type="hidden" value="14689423257893257" /
>
<input name="amount" />
...
</form>
 Spring Web Flow and Struts 2 provide such random token mechanisms
 Re-authenticate user for sensitive operations
25

26. Information Leakage and Improper
Exception Handling
www.xebia.fr / blog.xebia.fr

27. Information Leakage and Improper Exception Handling
 What ?
 Sensitive code details given to hackers
 Usually done raising exceptions
 Goal ?
 Discover code details to discover vulnerabilities
27

28. Information Leakage and Improper Exception Handling
 Sample
28

29. Information Leakage and Improper Exception Handling
How to prevent it ?
 Avoid detailed error messages
 Beware of development mode messages !
 web.xml
<web-app>
<error-page>
<exception-type>java.lang.Throwable</exception-type>
<location>/empty-error-page.jsp</location>
</error-page>
...
</web-app>
 Tomcat
<Server ...>
<Service ...>
<Engine ...>
<Host
errorReportValveClass="com.mycie.tomcat.EmptyErrorReportValve"
...>
...
</Host>
</Engine>
</Service>
</Server>
29

30. Information Leakage and Improper Exception Handling
How to prevent it ?
 Don’t display stack traces in Soap Faults
 Sanitize GUI error messages
 Sample : “Invalid login or password”
30

31. Broken Authentication and Session
Management
www.xebia.fr / blog.xebia.fr

32. Broken Authentication and Session Management
 What ?
 Web authentication and session handling have many tricks
 Goal ?
 Hijack user session
32

33. Broken Authentication and Session Management
How to prevent it ?
 Log session initiation and sensitive data access
 Remote Ip, time, login, sensitive data & operation accessed
 Use a log4j dedicated non over-written output file
#Audit
log4j.appender.audit=org.apache.log4j.DailyRollingFileAppender
log4j.appender.audit.datePattern='-'yyyyMMdd
log4j.appender.audit.file=audit.log
log4j.appender.audit.layout=org.apache.log4j.EnhancedPatternLayout
log4j.appender.audit.layout.conversionPattern=%m %throwable{short}n
log4j.logger.com.mycompany.audit.Audit=INFO, audit
log4j.additivity.com.mycompany.audit.Audit=false
 Use out of the box session and authentication
mechanisms
 Don’t create your own cookies
 Look at Spring Security
33

34. Broken Authentication and Session Management
How to prevent it ?
 Use SSL and random token for authentication pages
 including login page display
 Regenerate a new session on successful authentication
 Use Http Only session cookies, don’t use URL rewriting
based session handling
 Prevent brute force attacks using timeouts or locking
password on authentication failures
 Don’t store clear text password, consider SSHA
34

35. Broken Authentication and Session Management
How to prevent it ?
 Use a timeout period
 Remember Me cookies must be invalidated on password
change (see Spring Security)
 Beware not to write password in log files
 Server generated passwords (lost password, etc) must
be valid only once
 Be able to distinguish SSL communications
35

36. Broken Authentication and Session Management
How to prevent it ?
 For server to server communication, use remote ip
control in addition to password validation
36

37. Insecure Cryptographic Storage
www.xebia.fr / blog.xebia.fr

38. Insecure Cryptographic Storage
 What ?
 Cryptography has many traps
 Goal ?
 Steal sensitive data
38

39. Insecure Cryptographic Storage
How to prevent it ?
 Don’t invent custom cryptography solutions
 Java offers approved algorithms for hashing, symmetric key and public
key encryptions
 Double hashing is a custom weak algorithm
 Don’t use weak algorithms
 MD5 / SHA1, etc are weak. Prefer SHA-256
 Beware of private keys storage
 Java doesn’t offer chroot mechanisms to limit private keys files access
to root
 Storing secrets on servers requires expertise
39

40. Insecure Communications
www.xebia.fr / blog.xebia.fr

41. Insecure Communications
 What ?
 Unsecure communications are easy to hack
 Goal ?
 Steal sensitive data, hijack user session
41

42. Insecure Communications
How to prevent it ?
 Use SSL with the Servlet API
request.isSecure()
<web-app ...>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>restricted web services</web-resource-name>
<url-pattern>/services/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
...
</web-app>
42

43. Insecure Communications
How to prevent it ?
 Use SSL with Spring Security
<beans ...>
<sec:http auto-config="true">
<sec:intercept-url
pattern="/services/**"
requires-channel="https"
access="IS_AUTHENTICATED_FULLY" />
</sec:http>
</beans>
43