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 OWASP Top 10 for Java EE Jocelyn AUBERT OWASP-LU Chapter YAJUG! –

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

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

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

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

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

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

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

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

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

OWASP SEE IN ACTION… 11

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

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

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

OWASP SEE IN ACTION… 15

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

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

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

OWASP SEE IN ACTION… 19

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

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

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

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

OWASP SEE IN ACTION… 24

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

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

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

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

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

OWASP SEE IN ACTION… 30

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

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

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

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

OWASP SEE IN ACTION… 35

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!

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

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

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

OWASP SEE IN ACTION… 40

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

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

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

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

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

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

OWASP SEE IN ACTION… 47

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

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

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

OWASP SEE IN ACTION… 51

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

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

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

OWASP References  Top Ten project  op_Ten_Project op_Ten_Project  WebGoat project  Deliberately insecure Java EE web application  Designed to teach web application security concepts  WebGoat_Project WebGoat_Project 55

OWASP Going further…  The OWASP Guide to Building Secure Web Application v2  Guide_Project$ Guide_Project$  OWASP Code review project  ode_Review_Project ode_Review_Project 56

OWASP Going further…  OWASP Testing project  esting_Project esting_Project  OWASP Java project  ava_Project ava_Project 57

OWASP 58 Contact  Web    Mailing-list  luxemburg luxemburg  Mail 

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 Q&A 59