OWASP Top 10 for Java EE Jocelyn AUBERT

OWASP Top 10 for Java EE Jocelyn AUBERT OWASP-LU Chapter leader OWASP jocelyn. aubert@owasp. org @ YAJUG! – 2009 -05 -27 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 http: //www. owasp. org

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

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

OWASP < Open Web Application Security Project 4 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 4 Publications, articles, standards 4 Testing and training software < Open source licenses OWASP 4

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

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

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

10 Vulnerabilities < A 1 – Cross Site Scripting (XSS) < A 2 – Injection Flaws < A 3 – Malicious File Execution < A 4 – Insecure Direct Object Reference < A 5 – Cross Site Request Forgery (CSRF) < A 6 – Information Leakage and Improper Error Handling < A 7 – Broken Authentication and Session Management < A 8 – Insecure Cryptographic Storage < A 9 – Insecure Communications < A 10 – Failure to Restrict URL Access OWASP 8

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

A 1 – Cross Site Scripting (XSS) #2 <Vulnerabilities 4 Three types: § Reflected § Stored § DOM injection 4 Attacks are normally implemented in Java. Script or direct manipulation of request objects OWASP 10

SEE IN ACTION… OWASP 11

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

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

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

SEE IN ACTION… OWASP 15

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

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

A 3 – Malicious File Execution #2 <Vulnerabilities 4 Hostile data being uploaded to session files or log data 4 Accessing the default File. Servlet which returns files from the operating system OWASP 18

SEE IN ACTION… OWASP 19

See in action… String dir = s. get. Context(). get. Real. Path(“/ebanking”); String file = request. get. Parameter(“file”); File f = new File((dir + “\” + file). replace. All(“\\”, “/”)); www. url. com/ebanking? file=. . /web. xml OWASP 20

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

A 4 – Insecure Direct Object Reference #1 <Description 4 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 4 All Java EE application framework are vulnerable OWASP 22

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

SEE IN ACTION… OWASP 24

See in action… <select name=“language”> <option value=“fr”>Français</option> </select> … String language = request. get. Parameter(“language”); Request. Dispatcher rd = context. get. Request. Dispatcher(“main_” + language); rd. include(request, response); . . /etc/passwd%00 NULL BYTE INJECTION Access any file on the server’s file system OWASP 25

See in action… int cart. ID = Integer. parse. Int(request. get. Parameter(“cart. ID”)); String query = “SELECT * FROM table WHERE cart. ID=” + cart. ID; www. url. com/mysite? cart. ID=42 Try with 43, 44, 45, 46… OWASP 26

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

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

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

SEE IN ACTION… OWASP 30

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 BOB Forum administrator ALICE Forum user Best regards Alice OWASP 31

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

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

A 6 – Information Leakage and Improper Error Handling #2 <Vulnerabilities 4 Error message with too much detail § Stack traces § SQL statements 4 Improper logging of detailed messages OWASP 34

SEE IN ACTION… OWASP 35

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

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

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

A 7 – Broken Authentication and Session Management #2 <Vulnerabilities 4 Flaws in main authentication mechanism 4 But above all: § § § Logout Password management Session timeout “Remember me” Secret question OWASP 39

SEE IN ACTION… OWASP 40

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

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

A 8 – Insecure Cryptographic Storage #2 <Vulnerabilities 4 Not encrypting sensitive data 4 Using home grown algorithms 4 Insecure use of strong algorithms 4 Continued use of proven weak algorithms (DES, RC 4, etc…) 4 Hard coding keys, and storing keys in unprotected stores OWASP 43

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

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

A 9 – Insecure Communications #2 <Vulnerabilities 4 Network sniffing 4 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 4 Always use SSL with sensitive data OWASP 46

SEE IN ACTION… OWASP 47

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

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

A 10 – Failure to Restrict URL Access #2 <Vulnerabilities 4 Forced browsing 4“Hidden” URLs and files 4 Outdated security mechanism 4 Evaluating privileges only on the client OWASP 50

SEE IN ACTION… OWASP 51

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

Before concluding… < For input validation… 4 Don’t trust only client-side! § Let’s see it in action… 4 Use server-side validation… OWASP 53

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 OWASP 54

References <Top Ten project 4 http: //www. owasp. org/index. php/Category: OWASP_T op_Ten_Project <Web. Goat project 4 Deliberately insecure Java EE web application 4 Designed to teach web application security concepts 4 http: //www. owasp. org/index. php/Category: OWASP_ Web. Goat_Project OWASP 55

Going further… <The OWASP Guide to Building Secure Web Application v 2 4 http: //www. owasp. org/index. php/Category: OWASP_G uide_Project$ <OWASP Code review project 4 http: //www. owasp. org/index. php/Category: OWASP_C ode_Review_Project OWASP 56

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

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

Q&A jocelyn. aubert@owasp. org OWASP http: //www. owasp. org/index. php/Luxembourg 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 http: //www. owasp. org 59