1. Security Vulnerabilities Developers Face when Creating Web Applications Neal Ford Application Architect ThoughtWorks www.nealford.com www.thoughtworks.com nford@thoughtworks.com memeagora.blogspot.com

2. 2 Questions, Slides, and Samples Please feel free to ask questions anytime The slides and samples will be available at www.nealford.com I’ll show that address again at the end

3. 3 What This Session Covers: Top Ten Security Vulnerabilities 10. Insecure configuration management 9. Denial of service 8. Insecure storage 7. Improper error handling 6. Injection flaws 5. Buffer overflows 4. Cross site scripting flaws 3. Broken authentication and session management 2. Broken access control 1. Unvalidated input Other bad stuff

4. 4 History of This List Developed by OWASP (The Open Web Application Security Project) All volunteer group that provides free open-source documentation, tools, and services First list appeared in 2001 Updated every year This talk based on the 2004 list http://www.owasp.org/

5. 5 Some Statistics Percentage of the 648,000 security incidents investigated by Counterpane in 2004

6. 6 #10. Insecure Configuration Management Issues that plague the security of the site: Unpatched security flaws in the server software Server software flaws or misconfigurations that permit directory listing and directory traversal attacks Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages Improper file and directory permissions Unnecessary services enabled, including content management and remote administration

7. 7 Insecure Configuration Management Issues that plague the security of the site: Default accounts with their default passwords Administrative or debugging functions that are enabled or accessible Overly informative error messages (more details in the error handling section) Misconfigured SSL certificates and encryption settings Use of self-signed certificates to achieve authentication and man-in-the-middle protection Use of default certificates Improper authentication with external systems

8. 8 Top attacked ports (1/1 – 6/30, 2004) Port (TCP)Service % 180HTTP/Web30 2445MS CIFS file sharing17 3135MS DCE remote proc call15 44662E-donkey/P2P file sharing7 56346Gnutella/P2P file sharing5 622Secure shell/remote access4 71026Various dynamic services3 8113Indent service3 92745Beagle3 101025Various dynamic services3 Source: Symantec TMS data

9. 9 Case Study: Hacking Oracle through a Search Engine Before launching an attack, the hacker needs to know Where to attack The target’s vulnerabilities A search engine can give you both of these! The use of search engines to attack databases appeared in Wired magazine (http://www.wired.com/news/infostructure/0,1377,57897, 00.html)

10. 10 Looking for Mr. Database Typically, your database is behind a firewall From Oracle’s website: “Risk to exposure Unless you connect the database directly to the Internet (e.g., no intervening application server or firewall), a remote buffer overflow attack via the Internet is, in Oracle’s opinion, unlikely.” iSQLPlus is a utility supplied with the database for DBA interaction with the database Oracle 9i introduced a web version of iSQLPlus By default, iSQLPlus runs on Oracle’s HTTP server on port 5560 with the URL of /isqlplus

11. 11 Finding a Database to Hack

12. 12 List of Sites with iSQLPlus Available

13. 13 Logon In this case, we’re using dbsnmp/dbsnmp (better than scott/tiger because dbsnmp is a privileged account Survey’s indicate that 20-50% of install Oracle databases are running with at least one default username [source: Application Security, Inc.] A list of Oracle user name/password combinations can be found at http://www.cirt.net/cgi-bin/passwd.pl?method=showven&ven=Oracle

14. 14 Now, Get List Of Users

15. 15 Got a List of Users

16. 16 NUMTOYMINTERVAL Vulnerability Once you have located a database to hack over the web, you can use this exploit The NUMTOINTERVAL exploit was fixed by Oracle, but still isn’t isn’t included in a default install Execute the sample application page JDBCQuery.jsp with any (even non-privileged account) This exploit allows you to execute arbitrary operating system commands as the Oracle user

17. 17 NUMTOYMINTERVAL Vulnerability Here’s the query (modified to make it harmless) '1'='2' UNION SELECT NUMTOYMINTERVAL(1,'AAAAAAAAAABBBBBBBBBBCCCCCCCCCCABCDEFGHIJKLM NOPQR' || chr(59) || chr(79) || chr(150) || chr(01) || chr(141) || chr(68) || chr(36) || chr(18) || chr(80) || chr(215) || chr(21) || chr(52) || chr(35) || chr(148) || chr(01) || chr(255) ||chr(37) || chr(172) || chr(30) || chr(148) || chr(01) || chr(32) || 'echo ARE YOU SURE? >c:\Unbreakable.txt'), 1 from dual Replace the string “echo ARE YOU SURE? > c:\Unbreakable.txt” with your command of choice

18. 18 Lessons Learned? Search engines reduce the need to hackers to probe victims, meaning that attacks are harder to detect Organizations which rely solely on perimeter security are at significant risk of compromising mission critical data Perimeter security is necessary but no longer sufficient One security vendor estimates that 95% of security effort goes into perimeter security How do you prevent data access? Limit access from the external world directly to the database look at placing additional layers of defense to lock down the data right where it sits – in the database

19. 19 How to Protect Yourself Create a hardening guideline for your site Configuring all security mechanisms Turning off all unused services Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords Logging and alerts

20. 20 How to Protect Yourself Maintenance process: Monitoring the latest security vulnerabilities published Applying the latest security patches Updating the security configuration guideline Regular vulnerability scanning from both internal and external perspectives Regular internal reviews of the server’s security configuration as compared to your configuration guide Regular status reports to upper management documenting overall security posture

21. 21 #9. Denial of Service When an attacker generates so many requests, it swamps a web application or some aspect of it (like database connection pools) Hard to determine what is a legitimate DOS (or DDOS) Multiple users hitting the site simultaneously? Multiple users hitting “Reload” because of a previous problem? Have you been “Slashdotted”?

22. 22 Other Forms of DOS An attacker can lock out a legitimate user by sending invalid credentials Attacker can request a new password for a user

23. 23 How to Protect Yourself Protecting against DOS attacks is difficult Limit resources allocated to any user to a bare minimum For authenticated users, establish quotas Consider only handling 1 request per user at a time by synchronizing the user’s session Consider dropping any requests you are handling for a user if another request from the same user appears

24. 24 How to Protect Yourself For unauthenticated users Avoid unnecessary access to database or other expensive resources Consider caching the content received by unauthenticated users instead of generating it Make sure that your error handling is robust

25. 25 #8. Insecure Storage Most applications need to store information Common mistake areas: Failure to encrypt critical data Insecure storage of keys, certificates, and passwords Improper storage of secrets in memory Poor sources of randomness Poor choice of algorithm Attempting to invent a new encryption algorithm Failure to include support for encryption key changes and other required maintenance procedures

26. 26 How to Protect Yourself The easiest way is to not store information! Rather than encrypting credit cards, make users re-enter them Instead of storing encrypted passwords, use a one-way hashing function (like SHA-1) Don’t invent your own cryptography

27. 27 Cryptography in Java Java Cryptography Extension (JCE) for SDK 1.4.x (JCE 1.2.2) JCE exists as set of APIs Several implementations exist Sun’s Legion of the Bouncy Castle Others javax.crypto package in SDK 1.5

28. 28 How to Protect Yourself Make sure that secrets (keys, certificates, passwords) are securely stored The master secret should be stored in 2 locations and reassembled at run-time Email addresses Spiders crawl websites, looking for passwords http://automaticlabs.com/products/enkoderform/ Encodes email addresses as a complex looking JavaScript function Works as before, but spiders can’t harvest the address What’s the only problem with this solution?

29. 29 #7. Improper Error Handling Don’t show detailed internal error messages to the rest of the world Stack traces Database dumps Error codes Inconsistent error message also reveal information “File not found” vs. “Access denied”

30. 30 How to Protect Yourself Gracefully handle all errors Don’t reveal any internal details Log most errors In J2EE, make sure you have an error destination Keep a really detailed page for internal debugging See Tapestry for the gold standard on this Keep a “stone-faced” page for external users

31. 31 #6. Injection Flaws Allow attackers to relay malicious code through the web application to another system OS calls External programs through shell commands Calls to SQL (SQL Injection) Vulnerable any time a web application uses an interpreter of any kind

32. 32 SQL Injections Attacker must find a parameter that the web application passes through to the database Example Consider this SQL String SELECT * FROM USERS where Username = ‘user name input’ and Password = ‘password input’ With no input validation, the user can enter User name input’ -- Or Password input’ OR 1 = 1 --

33. 33 SQL Injection Because a semi-colon separates commands, attackers can supply values with semi-colon delimited attack code User input; drop table users; To exploit SQL Injection, the attacker must find a parameter These attacks generally just take patience Range from trivial to extremely severe

34. 34 How to Protect Yourself Carefully validate the data Use Stinger or custom scrubbing routines Use stored procedures or prepared statements Make sure that the web application only has the privileges it needs If you need to pass user input to an external program Scrub the input Check for and log error conditions, return codes, etc.

35. 35 #5. Buffer Overflows Attackers corrupt the execution stack of a web application Overrun a buffer (i.e., a String) Reset the pointer to the function return address to point to attacker code Generally, attacker has complete (root) access to the system Exists for any native executable language Not possible in J2EE applications (except for the JVM itself) Difficult in.NET web applications

36. 36 #4. Cross-site Scripting Flaws Occurs when an attacker uses a web application to send malicious code (usually a script) to another user Two categories Stored Injected code is permanently stored on the target server (database, message forum, visitor list, etc). Reflected Injected code is reflected off a web server, in an error message, search result, etc. Reflected attacks are delivered via another route (email message, another web server) User clicks on email message, code is reflected back to the user’s browser, executes the script

37. 37 XSS Vulnerabilities

38. 38 XSS Vulnerabilities Even brochureware sites are vulnerable Simple error pages for 404 or 500 may show the contents of the URL requested Makes them vulnerable to reflected attacks A huge number of documented XSS techniques Clever hackers use Unicode instead of “<>” tags Some attacks don’t even require “<>” tags If the attacker can make your site display a chunk of HTML Both IMG and IFRAME tags allow a new URL to load when the HTML is displayed The BadTrans worm used this technique to propagate itself using Outlook Express and Outlook’s “execute on view” feature

39. 39 XSS Scenarios: Scripting via a Malicious Link The attacker sends an email to the victim <A HREF=http://legitimateSite.com/registration.cgi? clientprofile= malicious code > Click here When an unsuspecting user clicks on this link, the URL is sent to legitimateSite.com including the malicious code If the legitimate server sends a page back to the user including the value of clientprofile, the malicious code will be executed on the client Web browser

40. 40 XSS Scenarios: Scripting via a Malicious Link

41. 41 XSS Scenarios: Stealing Cookies

42. 42 XSS Scenarios: Sending an Unauthorized Request

43. 43 XSS Consequences Range from annoyances to complete control Disclosure of a user’s session cookie Disclosure of end user files Installation of Trojan horse programs Redirecting to another site Modifying content

44. 44 How to Protect Yourself Validate Headers Cookies Query strings Form fields Hidden fields Use a “positive” specification

45. 45 How to Protect Yourself Encode user supplied output Use Stinger From:To: << >&gt: (( )) ## &&

46. 46 #3. Broken Authentication & Session Management Includes all aspects of handling user authentication and managing active sessions Particularly vulnerable are “Forgot my password”, “Password change”, etc. Subject to “walk by” attacks Should always be re-authenticated for those functions

47. 47 How to Protect Yourself Create strong passwords Log repeated failed login attempts Restrict to a certain number of attempts per unit of time Don’t record the password (failed or otherwise) in the log Don’t indicate to the user whether the user name or password was invalid Users should be informed of the time of the last successful login and number of failed attempts

48. 48 How to Protect Yourself Password change controls Always require old and new passwords If forgotten passwords are emailed, the system must force use to reauthenticate whenever the user changes their email address Otherwise, a “walk by” attack is possible Password storage Passwords should always be hashed or encrypted when stored (no matter what the storage) Hashing is better because it isn’t reversible

49. 49 How to Protect Yourself Protect credentials in transit The only effective solution is to use SSL Session ID protection Ideally, a user’s entire session should be protected via SSL Session ID can’t be grabbed off the network If you can’t use SSL Don’t include session ID’s in URLs or referrer header Session ID’s should be changed when switching to and from SSL

50. 50 How to Protect Yourself Browser caching Authentication and session ID should always be submitted via Post Authentication pages must be marked with all varieties of the no-cache tag Some browsers support autocomplete=false flag to prevent storage in autocomplete caches

51. 51 #2. Broken Access Control Access control (and authorization) covers how a web application grants access to content Many sites access control isn’t centrally located Grown over time Ad hoc rules scattered in hidden corners Remote administration is a particular problem

52. 52 How to Protect Yourself Code that implements access control must be audited Should be centralized (i.e., JAAS) Well structured Modular Find out how website is administered By developers, web designers, network staff

53. 53 How to Protect Yourself Build a web application security policy What types of users can access the system What functions and content each user can see Specific issues Insecure ID’s Forced browsing past access control checks Path traversal File permissions Client-side caching

54. 54 Forced Browsing Forced browsing past access control checks Don’t allow users to bookmark deep into your site Don’t allow unprotected content Example When using Struts, make a base action that prevents forced browsing

55. 55 Path Traversal Path traversal involves adding relative path information to requests../../target_dir/target_file /scripts/..%c0%af..%c0%afwinnt Case study: Unicode directory traversal Specific to IIS Normally, the web server blocks “../” content Didn’t handle the Unicode version “%c0%af” Allowed directory traversal via a URL /scripts/..%c0%af..%c0%afwinnt%c0%afcmd.exe

56. 56 Think J2EE is Safe from IIS Issues? If you are using a servlet engine on IIS… If you allow a path traversal or file upload… An attacker can insert an ASP page onto your site Now you have ASP security problems!

57. 57 How to Protect Yourself Strongly consider disabling web administration from the “front side” of the web application Several vulnerabilities in protocols like WebDAV have popped up Use VPN or SSH access to get to the network, then administer the web site and applications

58. 58 #1. Unvalidated Input Attackers can tamper with: URL Query string Headers Cookies Form fields Hidden fields Tools exist that bypass browsers Telnet Achilles

59. 59 Common Attacks Forced browsing past access control checks Command insertion Cross site scripting Buffer overflows Format string attacks SQL injection Cookie poisoning Hidden field manipulation

60. 60 How to Protect Yourself Parameters validated against a positive specification Data type (string, integer, real, etc…) Allowed character set Minimum and maximum length Whether null is allowed Whether the parameter is required or not Whether duplicates are allowed Numeric range Specific legal values (enumeration) Specific patterns (regular expressions)

61. 61 Positive vs. Negative Filtering Positive filtering implies a set of rules for valid input Negative filtering tries to filter out bad data Negative filters cannot be comprehensive enough Filtering out bad data is doomed to failure

62. 62 Tools Stinger A J2EE open-source project developed by Aspect Security An HTTP request validation engine for J2EE environments Build an XML document with parameter characteristics Call Stinger.validate(request) to apply the rules Handle violations

63. 63 Tools WebScarab An open-source OWASP project Records the conversations (request and response) between client and server Use WebScarab to try illegal values and see what effect it has on your application

64. 64 Summary Be careful out there! Some of these problems are automatically handled by J2EE Be diligent on your security It pays to be paranoid Take advantage of tools and frameworks Don’t think it can’t happen to you

65. Neal Ford www.nealford.com nford@thoughtworks.com memeagora.blogspot.com Questions? Samples & slides at www.nealford.com This work is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 2.5 license. http://creativecommons.org/licenses/by-nc-sa/2.5/