1. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org OWASP Top 10 for Java EE Jocelyn AUBERT OWASP-LU Chapter leader jocelyn.aubert@owasp.org @ YAJUG! – 2009-05-27

2. OWASP 2 Agenda  Who I am?  OWASP?  Top 10  Description  In action!  Security check & protection  Q&A

3. OWASP 3 Who I am?  Jocelyn Aubert  R&D Engineer @ CRP Henri Tudor  Software security  OWASP-LU Chapter leader

4. OWASP 4  Open Web Application Security Project  A open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted  Non-profit, volunteer driven organization  Provide free resources to the community  Publications, articles, standards  Testing and training software  Open source licenses

5. OWASP 5 OWASP-LU  Luxembourg Local chapter  Meetings, workshops, tutorials, barcamps (free & open to everyone)  Local mailing list  Presentations & groups  Open forum for discussion  Meet fellow InfoSec professionals  Create (Web)AppSec awareness in Luxembourg  Local projects

6. OWASP 6 Top 10?  OWASP deliverable  Awareness document  10 most critical web application security vulnerabilities  Lists the vulnerabilities & discusses how to protect against them

7. OWASP Top 10 for Java EE  Top 10 adjusted to only discuss Java EE applications!  Aim  Educate Java developers, designers, architects and organizations  Provides basic methods to protect against vulnerabilities  Only an education piece, not a standard! 7

8. OWASP 10 Vulnerabilities  A1 – Cross Site Scripting (XSS)  A2 – Injection Flaws  A3 – Malicious File Execution  A4 – Insecure Direct Object Reference  A5 – Cross Site Request Forgery (CSRF)  A6 – Information Leakage and Improper Error Handling  A7 – Broken Authentication and Session Management  A8 – Insecure Cryptographic Storage  A9 – Insecure Communications  A10 – Failure to Restrict URL Access 8

9. OWASP A1 – Cross Site Scripting (XSS) #1  Description  Most prevalent web application security issue  Occurs whenever an application takes data without validating or encoding the content  Allows attackers to execute script in the victim’s browser  Affected Environment  All Java EE application frameworks are vulnerable 9

10. OWASP A1 – Cross Site Scripting (XSS) #2  Vulnerabilities  Three types:  Reflected  Stored  DOM injection  Attacks are normally implemented in JavaScript or direct manipulation of request objects 10

11. OWASP SEE IN ACTION… 11

12. OWASP A1 – Cross Site Scripting (XSS) #3  Verifying Security  All input parameters are validated and/or encoded  Code reviews are useful to detect  Centralized validation and encoding mechanism  Protection  Combination of whitelist validation of all incoming data and appropriate encoding of all output data 12

13. OWASP A2 – Injection Flaws#1  Description  Injection occurs when user-supplied data is sent to an interpreter as part of a command or query  SQL injection is the most common  Affected environments  All Java EE application frameworks that uses interpreters are vulnerable 13

14. OWASP A2 – Injection Flaws#2  Vulnerabilities  If user input is passed into an interpreter without validation or encoding, the application is vulnerable  Check to see if user input is supplied directly to dynamic queries 14

15. OWASP SEE IN ACTION… 15

16. OWASP A2 – Injection Flaws#3  Verifying security  Verify that the user can not modify commands or queries sent to any interpreter used by the application  Code reviews are useful to detect  Protection  Avoid interpreters where possible  Enforce least privilege  Stored procedures are susceptible too  User input validation 16

17. OWASP A3 – Malicious File Execution#1  Description  Allows attackers to perform remote code execution by compromising input files or streams; commonly caused by improperly trusting input files  Affected environments  All Java EE application frameworks that allow uploaded files to be executed are vulnerable  Environments are susceptible if they allow file upload into web directories 17

18. OWASP A3 – Malicious File Execution#2  Vulnerabilities  Hostile data being uploaded to session files or log data  Accessing the default FileServlet which returns files from the operating system 18

19. OWASP SEE IN ACTION… 19

20. OWASP See in action… String dir = s.getContext().getRealPath(“/ebanking”); String file = request.getParameter(“file”); File f = new File((dir + “ \\ ” + file).replaceAll(“\\\\”, “/”));  www.url.com/ebanking?file=../../web.xml 20

21. OWASP A3 – Malicious File Execution#3  Verifying security  Automated tools have difficulty identifying parameters used in a file include  Code reviews are useful to detect  Protection  Do not allow a user defined file name to supply server-based resources  Properly configured and implemented security protocols  User input validation 21

22. OWASP A4 – Insecure Direct Object Reference#1  Description  Occurs when a developer exposes an invalidated reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter  Affected environments  All Java EE application framework are vulnerable 22

23. OWASP A4 – Insecure Direct Object Reference#2  Vulnerabilities  Exposed internal object references  Attackers use parameters tampering to change references and violate the intended but unenforced access control policy  References to database keys are frequently exposed 23

24. OWASP SEE IN ACTION… 24

25. OWASP See in action… Français … String language = request.getParameter(“language”); RequestDispatcher rd = context.getRequestDispatcher(“main_” + language); rd.include(request, response); ../../../../etc/passwd%00  NULL BYTE INJECTION  Access any file on the server’s file system 25

26. OWASP See in action… int cartID = Integer.parseInt(request.getParameter(“cartID”)); String query = “SELECT * FROM table WHERE cartID=” + cartID;  www.url.com/mysite?cartID=42 www.url.com/mysite?cartID=42  Try with 43, 44, 45, 46… 26

27. OWASP A4 – Insecure Direct Object Reference#3  Verifying security  Remove any direct object references that can be manipulated by an attacker  Difficult for both automated and manual approaches  Protection  Best protection is to avoid exposing direct object references to users  Verify authorization to all referenced objects  Ban inputs such as..\ or %00 27

28. OWASP A5 – Cross Site Request Forgery (CSRF)#1  Description  An attack that tricks the victim into loading a page that contains a malicious request  Also known as Session Riding, One-Click Attacks, Cross Site Reference Forgery, Hostile Linking, and Automation Attack  Affected environments  All Java EE application frameworks are vulnerable 28

29. OWASP A5 – Cross Site Request Forgery (CSRF)#2  Vulnerabilities  The attack may direct an user to invoke undesired function(s)  Work because the user’s authorization credential is automatically included (session cookie)  Can be combined with XSS 29

30. OWASP SEE IN ACTION… 30

31. OWASP See in action… 31 BOB Forum administrator ALICE Forum user Hello Bob, Here find a nice picture… Best regards Alice Hello Bob, Here find a nice picture Best regards Alice

32. OWASP A5 – Cross Site Request Forgery (CSRF)#3  Verifying security  Use an authorization token that is not automatically submitted by browser  Protection  Eliminate any XSS vulnerabilities in your application  Insert custom random tokens into every form and URL  Require additional login screens for sensitive data  Do not use GET requests (URLs) for sensitive data 32

33. OWASP A6 – Information Leakage and Improper Error Handling#1  Description  Applications can unintentionally leak information about their configuration, internal working, or violate privacy through a variety of application problems  Affected environments  All Java EE application frameworks are vulnerable 33

34. OWASP A6 – Information Leakage and Improper Error Handling#2  Vulnerabilities  Error message with too much detail  Stack traces  SQL statements  Improper logging of detailed messages 34

35. OWASP SEE IN ACTION… 35

36. OWASP See in action…  SQL  Failed SQL statements can reveal information on database structure  Authentication form 36 usertest xxxxxx Username Password Login Bad password for this username!

37. OWASP A6 – Information Leakage and Improper Error Handling#3  Verifying security  The goal is for the application to not leak detailed error messages  Automated and manual approaches are useful, but automated can not properly determine the meaning of the message and manual is time consuming  Protection  Use testing to generate error messages and perform ongoing evaluations in development  Disable or limit detailed error handling 37

38. OWASP A7 – Broken Authentication and Session Management#1  Description  Flaws in authentication and session management most frequently involve the failure to protect credentials and session tokens through their lifecycle  Affected environments  All Java EE application frameworks are vulnerable 38

39. OWASP A7 – Broken Authentication and Session Management#2  Vulnerabilities  Flaws in main authentication mechanism  But above all:  Logout  Password management  Session timeout  “Remember me”  Secret question 39

40. OWASP SEE IN ACTION… 40

41. OWASP A7 – Broken Authentication and Session Management#3  Verifying security  Application should properly authenticate users and protect their credentials  Automated tool have difficulty  Combination of Code reviews and Testing are effective  Protection  Maintain secure communications and credential storage  Use single authentication mechanism where applicable  Create a new session upon authentication  Ensure the logout link destroys all pertinent data  Do not expose any credentials in URL or logs 41

42. OWASP A8 – Insecure Cryptographic Storage#1  Description  Simply failing to encrypt sensitive data is very widespread  Applications that do encrypt frequently contain poorly designed cryptography, either using inappropriate ciphers or making serious mistakes using strong ciphers  Affected environments  All Java EE application frameworks are vulnerable 42

43. OWASP A8 – Insecure Cryptographic Storage#2  Vulnerabilities  Not encrypting sensitive data  Using home grown algorithms  Insecure use of strong algorithms  Continued use of proven weak algorithms (DES, RC4, etc…)  Hard coding keys, and storing keys in unprotected stores 43

44. OWASP A8 – Insecure Cryptographic Storage#3  Verifying security  Verify that the applications properly encrypts sensitive information in storage  Automated vulnerability tools are not effective  Code review is the best way to verify that an application encrypts sensitive data  Protection  Use only approved public algorithms  Check to make sure all sensitive data is being encrypted 44

45. OWASP A9 – Insecure Communications#1  Description  Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications  SSL must be used for all authenticated connections  Affected environments  All Java EE application frameworks are vulnerable 45

46. OWASP A9 – Insecure Communications#2  Vulnerabilities  Network sniffing  All authenticated traffic needs to go over SSL because HTTP includes authentication credentials or a session token with every single request; not just the actual login request  Always use SSL with sensitive data 46

47. OWASP SEE IN ACTION… 47

48. OWASP A9 – Insecure Communications#3  Verifying security  Verify that the application properly encrypts all authenticated and sensitive communications  Vulnerability scanning tools can verify that SSL is used on the front end, and can find many SSL related flaws  Code review is quite efficient for verifying the proper use of SSL for all backend connections  Protection  Always use SSL with sensitive data 48

49. OWASP A10 – Failure to Restrict URL Access#1  Description  Relying on security by obscurity to restrict URL access  Not using access control checks for URLs  Affected environments  All Java EE application frameworks are vulnerable 49

50. OWASP A10 – Failure to Restrict URL Access#2  Vulnerabilities  Forced browsing  “Hidden” URLs and files  Outdated security mechanism  Evaluating privileges only on the client 50

51. OWASP SEE IN ACTION… 51

52. OWASP A10 – Failure to Restrict URL Access#3  Verifying security  Verify that access control is enforced consistently for all URLs in the application  Automated tools have difficulty verifying URL access control  Combination of Code review and Testing are effective  Protection  Properly architecting and implementing roles for URL access  Ensure all URLs are part of this process  Do not use “hidden” URLs 52

53. OWASP Before concluding…  For input validation…  Don’t trust only client-side!  Let’s see it in action…  Use server-side validation… 53

54. OWASP Where to go from here?  Increase clients/management… awareness of web application security  Ask for secure code training  Design your features securely  Adopt coding standards  Refactor existing code to use safer constructs  Test your code for security defects  Consider joining OWASP and attending local chapter meetings 54

55. OWASP References  Top Ten project  http://www.owasp.org/index.php/Category:OWASP_T op_Ten_Project http://www.owasp.org/index.php/Category:OWASP_T op_Ten_Project  WebGoat project  Deliberately insecure Java EE web application  Designed to teach web application security concepts  http://www.owasp.org/index.php/Category:OWASP_ WebGoat_Project http://www.owasp.org/index.php/Category:OWASP_ WebGoat_Project 55

56. OWASP Going further…  The OWASP Guide to Building Secure Web Application v2  http://www.owasp.org/index.php/Category:OWASP_ Guide_Project$ http://www.owasp.org/index.php/Category:OWASP_ Guide_Project$  OWASP Code review project  http://www.owasp.org/index.php/Category:OWASP_C ode_Review_Project http://www.owasp.org/index.php/Category:OWASP_C ode_Review_Project 56

57. OWASP Going further…  OWASP Testing project  http://www.owasp.org/index.php/Category:OWASP_T esting_Project http://www.owasp.org/index.php/Category:OWASP_T esting_Project  OWASP Java project  http://www.owasp.org/index.php/Category:OWASP_J ava_Project http://www.owasp.org/index.php/Category:OWASP_J ava_Project 57

58. OWASP 58 Contact  Web  http://www.owasp.org http://www.owasp.org  http://www.owasp.org/index.php/Luxembourg http://www.owasp.org/index.php/Luxembourg  Mailing-list  http://lists.owasp.org/mailman/listinfo/owasp- luxemburg http://lists.owasp.org/mailman/listinfo/owasp- luxemburg  Mail  jocelyn.aubert@owasp.org jocelyn.aubert@owasp.org

59. Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP http://www.owasp.org Q&A jocelyn.aubert@owasp.org http://www.owasp.org/index.php/Luxembourg 59