The 10 Most Critical Web Application Security Vulnerabilities Justen Stepka justen.stepka@valtira.com

1. The 10 Most Critical Web Application Security Vulnerabilities Justen Stepka justen.stepka@valtira.com

2. About Justen Stepka • Valtira product development manager • Rolecall Security Server • Simplicis Content Management Server • O’Reilly author • Java Database Programming Best Practices • Java Development Journal guest writer • Open Symphony Project Overview

3. Agenda • OWASPThe Open Web Application Security Projecthttp://www.owasp.org • Background • Top 10 list • Wrap-up

4. Introduction • Open Web Application Security Project (OWASP) • Started in 2000. • http://www.owasp.org • Advance knowledge of web application and web security issues. • Generic testing tools • Knowledge base center

5. Background • Covers top classes, types, or categories of web application vulnerabilities. • No reliable source of statistics about web application security problems. • The top ten list is in no particular order. • Ongoing effort, targeted towards largest audience possible.

6. A1 - Unvalidated Input

7. Description • Information from web request is not validated before being used by a web application. • Attackers can use these flaws to attack backend components through a web application. • Attackers can modify any of the following: • URL • Query string • Header • Cookie modification • Form

8. Environments Affected • All web servers, application servers, and web application environments are susceptible to parameter tampering.

9. Are you vulnerable • The simplest way to find tainted parameter use is to have a detailed code review. • OWASP WebScarab, submits unexpected values in HTTP request to identify tainted parameters.

10. How to protect yourself • Ensure that all parameters are validated before they are used. • Check verses exactly what input should be allowed. • ‘Negative’ approaches that involve filtering out certain bad input are no effective. • Define a ‘positive’ value specification.

11. A2 - Broken Access Control

12. Description • Access control, often called authorization, is how web applications grant access to content and functions. • Developers frequently underestimate the difficultly of implementing a reliable access control system.

13. Environments Affected • All web servers, application servers, and web application environments are susceptible to at least some of these issues.

14. Are you vulnerable • Access control policy should be clearly documented. • Detailed code review should be performed to validate the correctness of the access control implementation.

15. How to project yourself • Use an access control matrix. • Common control issues: • Insecure Ids • Path traversal • File permissions • Client side caching

16. A3 - Broken Authentication and Session Management

17. Description • Web application must establish session to keep track of the stream of request from each user. HTTP does not provide this, web application developers must create this themselves. • If the session tokens are not properly protected, an attacker can hijack an active session and assume the identity of a user.

18. Environments Affected • All web servers, application servers, and web application environments are susceptible to broken authentication and session management issues.

19. Are you vulnerable • Ensure that user’s credentials are protected at all times while they are at rest (e.g, on disk), and while they are in transit (e.g, during login).

20. How to project yourself • Careful and proper use of custom or off the shelf authentication and session management mechanisms should significantly reduce the likelihood of a problem. • Security rules: • Password strength • Password storage (hashed or encrypted) • Session ID protection • Password change controls

21. A4 - Cross Site Scripting

22. Description • Sometimes referred to as XSS. • Occur when an attacker uses a web application to send malicious code, generally in the form of a script, to a different end user. • Wide spread problem. • Type types • Stored: attacks injected code is permanently stored on the target web server (database, message forum, visitor log, comment field, etc). • Reflected attacks are delivered via another route such as an e-mail message. A user is then tricked into clicking on the malicious link or submitting data. The browser then executes the code from what is considered a ‘trusted’ server.

23. Environments Affected • All web servers, application servers, and web application environments are susceptible to cross site scripting.

24. Are you vulnerable • XSS Flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output.

25. How to project yourself • Validation of all headers, cookies, query strings, from fields, and hidden fields against a rigorous specification. • Encoding user input • < to &lt; • > to &gl; • ( to &#40; • ) to &#41; • # to &#35; • & to &#38;

26. A5 - Buffer Overflows

27. Description • By sending carefully crafted input to a web application, an attacker can cause the web application to execute arbitrary code effectively taking over the machine. • Buffer overflows are not easy to discover and even when one is discovered, it is generally extremely difficult to exploit. • Well known and documented over an array of products and components.

28. Environments Affected • All web servers, application servers, and web application environments are susceptible to buffer overflow attacks. • The notable exception being Java and J2EE environments, which are immune to these attacks (except for overflows in the JVM itself).

29. Are you vulnerable • For custom application software, all code that accepts input from the users via the HTTP request must be reviewed to ensure that it can properly handle arbitrarily large input.

30. How to project yourself • For server products and libraries, keep up with the latest bug reports for the products you are using. • Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications. • Size checking on all input.

31. A6 - Injection Flaws

32. Description • Injections flaws allow attackers to relay malicious code through a web application to another system (i.e SQL injections). • When a web application passes information from an HTTP request through as part of an external request, it must be carefully scrubbed. Otherwise the attacker can inject special (meta) characters, malicious commands, or command modifiers into the information and the web application will blindly pass these on to the external system for execution.

33. Environments Affected • Every web application environment allows that has external commands such as system calls, shell commands, and SQL request.

34. Are you vulnerable • Search the source code for all calls to external resources (e.g, system, exec, fork, Runtime.exec, SQL queries, or whatever the syntax is for making request to interpreters in your environment).

35. How to project yourself • For server products and libraries, keep up with the latest bug reports for the products you are using. • Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications. • Size checking on all input. • Ensure the web application runs with only the privileges it absolutely needs to perform its function.

36. A8 - Insecure Storage

37. Description • Encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it into a web application. • Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspect of the site. • Common mistakes: • Failure to encrypt critical data • Insecure storage of keys, certificates, and passwords • Poor sources of randomness • Inventing a new encryption algorithm • Failure to include support for encryption key changes and other required maintenance procedures.

38. Environments Affected • Most web application environments include some form of cryptographic support. In the rare case that such support is not already available, there are a wide variety of third-party products that can be added. • Only web sites that use encryption protect information in storage or transit are susceptible to these attacks.

39. Are you vulnerable • Discovering cryptographic flaws without access to the source code be extremely time consuming. • The easiest approach is to review the code to see how the cryptographic functions are implemented. A careful review of the structure, quality, and implementation of the modules should be performed. • Review should cover how keys, passwords, and other secrets are stored, protected, loaded, processed, and cleared from memory.

40. How to project yourself • The easiest way to protect against cryptographic flaws is to minimize the use of encryption and only keep information that is absolutely necessary. • Rather than storing credit card, simply require users to re-enter the numbers. • Use 1-way encryption.

41. A9 - Insecure Configuration Management

42. Description • Web server and application server configuration play a key role in the security of a web application. • Frequently, the web development group is separate from the group operating the site. • There are a wide variety of server configuration problems that can plague the security of a site: • Unpatched security flaws in the server software. • Misconfigurations that permit directory listing and traversal. • Default accounts • Debugging functions that are enabled • Improper authentication with external systems. • Overly informative error messages

43. Environments Affective • All web servers, application servers, and web application environments are susceptible to misconfiguration.

44. Are you vulnerable • Few, if any server products are secure out of the box. A server configuration for your platform should be documented and updated frequently. • Comparison to the actual deployed systems is also recommended. • Scanning products such as Nessus and Nikto.

45. How to project yourself • Standardize an application and server configuration. This configuration should be used on all hosts running the application and in the development environment as well. • Deployment guideline should cover: • Configuring all security mechanisms. • Turning off all unused services. • Setting up roles, permission, accounts, including disabling all default accounts or changing passwords. • Logging and alerts. • Maintenance

46. Wrap up • Top 10 list is a starting point. • Additional items: • Unnecessary and malicious code. • Broken thread safety and concurrent programming. • Unauthorized information gathering. • Accountability problems and weak logging. • Data corruption. • Broken caching, pooling, and reuse.