• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Xebia Knowledge Exchange - Owasp Top Ten
 

Xebia Knowledge Exchange - Owasp Top Ten

on

  • 2,262 views

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

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

Statistics

Views

Total Views
2,262
Views on SlideShare
2,257
Embed Views
5

Actions

Likes
1
Downloads
22
Comments
0

3 Embeds 5

http://www.slideshare.net 2
http://www.linkedin.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Xebia Knowledge Exchange - Owasp Top Ten Xebia Knowledge Exchange - Owasp Top Ten Presentation Transcript

  • OWASP Security Top Ten OWASP top ten www.xebia.fr / blog.xebia.fr
  • 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
  • Cross Site Scripting (XSS) www.xebia.fr / blog.xebia.fr
  • 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
  • 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
  • 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
  • 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
  • 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
  • Injection Flaws www.xebia.fr / blog.xebia.fr
  • 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
  • Injection Flaws How to prevent it ?  Input validation  XSD with regular expression, min and max values, etc  JSR 303 Bean Validation 11
  • 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
  • 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
  • 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
  • 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
  • Malicious File Execution www.xebia.fr / blog.xebia.fr
  • 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
  • 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
  • Insecure Direct Object Reference www.xebia.fr / blog.xebia.fr
  • 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
  • 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
  • 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
  • Cross Site Request Forgery (CSRF) www.xebia.fr / blog.xebia.fr
  • 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
  • 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
  • Information Leakage and Improper Exception Handling www.xebia.fr / blog.xebia.fr
  • 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
  • Information Leakage and Improper Exception Handling  Sample 28
  • 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
  • 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
  • Broken Authentication and Session Management www.xebia.fr / blog.xebia.fr
  • Broken Authentication and Session Management  What ?  Web authentication and session handling have many tricks  Goal ?  Hijack user session 32
  • 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
  • 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
  • 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
  • Broken Authentication and Session Management How to prevent it ?  For server to server communication, use remote ip control in addition to password validation 36
  • Insecure Cryptographic Storage www.xebia.fr / blog.xebia.fr
  • Insecure Cryptographic Storage  What ?  Cryptography has many traps  Goal ?  Steal sensitive data 38
  • 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
  • Insecure Communications www.xebia.fr / blog.xebia.fr
  • Insecure Communications  What ?  Unsecure communications are easy to hack  Goal ?  Steal sensitive data, hijack user session 41
  • 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
  • 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