The document discusses the OWASP top 10 security vulnerabilities. It summarizes Cross-Site Scripting (XSS), providing an example of how XSS can be exploited by injecting malicious scripts. It then discusses how to prevent XSS through input validation, output encoding, and using HTTP-only cookies. The document continues summarizing other top vulnerabilities like injection flaws, file execution, insecure object references, and countermeasures.

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