OWASP Top 10 for Java EE

1. OWASP Top 10 for Java EE Jocelyn AUBERT OWASP-LU Chapter leader jocelyn.aubert@owasp.org @ YAJUG! – 2009-05-27

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

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

4. OWASP • 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-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. Top 10? • OWASP deliverable • Awareness document • 10 most critical web application security vulnerabilities • Lists the vulnerabilities & discusses how to protect against them

7. 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!

8. 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

9. 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

10. 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

11. SEE IN ACTION…

12. 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

13. 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

14. 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

15. SEE IN ACTION…

16. 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

17. 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

18. 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

19. SEE IN ACTION…

20. 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

21. 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

22. 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

23. 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

24. SEE IN ACTION…

25. See in action… <select name=“language”> <option value=“fr”>Français</option> </select> … 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

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

27. 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

28. 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

29. 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

30. SEE IN ACTION…

31. See in action… Hello Bob, Here find a nice picture… <img src=“http://www.forum.com/admin/deletemessage?mes_id=42” /> Best regards Alice Hello Bob, Here find a nice picture Best regards Alice ALICE Forum user BOB Forum administrator

32. 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

33. 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

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

35. SEE IN ACTION…

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

37. 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

38. 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

39. 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

40. SEE IN ACTION…

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. SEE IN ACTION…

48. 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

49. 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

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