Xebia Knowledge Exchange - Owasp Top Ten

2,427 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,427
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Xebia Knowledge Exchange - Owasp Top Ten

    1. 1. OWASP Security Top Ten OWASP top ten www.xebia.fr / blog.xebia.fr
    2. 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. 3. Cross Site Scripting (XSS) www.xebia.fr / blog.xebia.fr
    4. 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. 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. 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. 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. 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. 9. Injection Flaws www.xebia.fr / blog.xebia.fr
    10. 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. 11. Injection Flaws How to prevent it ?  Input validation  XSD with regular expression, min and max values, etc  JSR 303 Bean Validation 11
    12. 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. 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. 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. 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. 16. Malicious File Execution www.xebia.fr / blog.xebia.fr
    17. 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. 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. 19. Insecure Direct Object Reference www.xebia.fr / blog.xebia.fr
    20. 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. 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. 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. 23. Cross Site Request Forgery (CSRF) www.xebia.fr / blog.xebia.fr
    24. 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. 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. 26. Information Leakage and Improper Exception Handling www.xebia.fr / blog.xebia.fr
    27. 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. 28. Information Leakage and Improper Exception Handling  Sample 28
    29. 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. 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. 31. Broken Authentication and Session Management www.xebia.fr / blog.xebia.fr
    32. 32. Broken Authentication and Session Management  What ?  Web authentication and session handling have many tricks  Goal ?  Hijack user session 32
    33. 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. 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. 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. 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. 37. Insecure Cryptographic Storage www.xebia.fr / blog.xebia.fr
    38. 38. Insecure Cryptographic Storage  What ?  Cryptography has many traps  Goal ?  Steal sensitive data 38
    39. 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. 40. Insecure Communications www.xebia.fr / blog.xebia.fr
    41. 41. Insecure Communications  What ?  Unsecure communications are easy to hack  Goal ?  Steal sensitive data, hijack user session 41
    42. 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. 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

    ×