security vulnerabilities developers face when creating web applications neal ford application...
TRANSCRIPT
Security Vulnerabilities Developers Face
when Creating Web Applications
Neal FordApplication Architect
ThoughtWorkswww.nealford.com
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
What This Session Covers:
• Top Ten Security Vulnerabilities10. 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
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
Some Statistics
• Percentage of the 648,000 security incidents investigated by Counterpane in 2004
Denial of Service
9%
Misuse of Applications
3%
Unauthorized activity of some kind
41%
Unauthorized access
26%
Scanning21%
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
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
Top attacked ports (1/1 – 6/30, 2004)
Port (TCP) Service %
1 80 HTTP/Web 30
2 445 MS CIFS file sharing 17
3 135 MS DCE remote proc call 15
4 4662 E-donkey/P2P file sharing 7
5 6346 Gnutella/P2P file sharing 5
6 22 Secure shell/remote access 4
7 1026 Various dynamic services 3
8 113 Indent service 3
9 2745 Beagle 3
10 1025 Various dynamic services 3
Source: Symantec TMS data
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
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
Finding a Database to Hack
12
List of Sites with iSQLPlus Available
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
Now, Get List Of Users
15
Got a List of Users
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
NUMTOYMINTERVAL Vulnerability
• Here’s the query (modified to make it harmless)
'1'='2' UNION SELECT NUMTOYMINTERVAL(1,'AAAAAAAAAABBBBBBBBBBCCCCCCCCCCABCDEFGHIJKLMNOPQR' || 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
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
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
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
#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
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
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
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
#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
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
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
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
#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
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
#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
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
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
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
#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
#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
XSS Vulnerabilities
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
XSS Scenarios: Scripting via a Malicious Link
• The attacker sends an email to the victim
<A HREF=http://legitimateSite.com/registration.cgi? clientprofile=<SCRIPT>malicious code</SCRIPT>> Click here</A>
• 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
XSS Scenarios: Scripting via a Malicious Link
41
XSS Scenarios: Stealing Cookies
42
XSS Scenarios: Sending an Unauthorized Request
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
How to Protect Yourself
• Validate• Headers• Cookies• Query strings• Form fields• Hidden fields
• Use a “positive” specification
45
How to Protect Yourself
• Encode user supplied output
• Use Stinger
From: To:
< <
> >:
( (
) )
# #
& &
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
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
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
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
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
#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
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
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
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
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
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
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
#1. Unvalidated Input
• Attackers can tamper with:• URL• Query string• Headers• Cookies• Form fields• Hidden fields
• Tools exist that bypass browsers• Telnet• Achilles
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
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
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
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
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
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
Neal Ford
www.nealford.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/