1 / 59

OWASP Top 10 for Java EE

OWASP Top 10 for Java EE. Jocelyn AUBERT OWASP-LU Chapter leader jocelyn.aubert@owasp.org. @ YAJUG! – 2009-05-27. Agenda. Who I am? OWASP? Top 10 Description In action! Security check & protection Q&A. Who I am?. Jocelyn Aubert R&D Engineer @ CRP Henri Tudor Software security

boylesh
Télécharger la présentation

OWASP Top 10 for Java EE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related