Transcript Top 10 Security Vulnerabilities Developing Web Applications

Security Vulnerabilities Developers Face
when Creating Web Applications
Neal Ford
Application Architect
ThoughtWorks
www.nealford.com
www.thoughtworks.com
[email protected]
memeagora.blogspot.com
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
2
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
3
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/
4
Some Statistics
• Percentage of the 648,000 security incidents investigated by
Counterpane in 2004
Denial of
Service
9%
Scanning
21%
Unauthorized
access
26%
Misuse of
Applications
3%
Unauthorized
activity of
some kind
41%
5
#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
6
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
7
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
8
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)
9
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
10
Finding a Database to Hack
11
List of Sites with iSQLPlus Available
12
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
13
Now, Get List Of Users
14
Got a List of Users
15
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
16
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
17
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
18
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
19
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
20
#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”?
21
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
22
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
23
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
24
#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
25
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
26
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
27
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?
28
#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”
29
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
30
#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
31
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 --
32
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
33
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.
34
#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
35
#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
36
XSS Vulnerabilities
37
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
38
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
39
XSS Scenarios: Scripting via a Malicious Link
40
XSS Scenarios: Stealing Cookies
41
XSS Scenarios: Sending an Unauthorized Request
42
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
43
How to Protect Yourself
• Validate
•
•
•
•
•
Headers
Cookies
Query strings
Form fields
Hidden fields
• Use a “positive” specification
44
How to Protect Yourself
• Encode user supplied output
• Use Stinger
From:
To:
<
&lt;
>
&gt:
(
&#40;
)
&#41;
#
&#35;
&
&#38;
45
#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
46
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
47
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
48
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
49
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
50
#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
51
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
52
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
53
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
54
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
55
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!
56
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
57
#1. Unvalidated Input
• Attackers can tamper with:
•
•
•
•
•
•
URL
Query string
Headers
Cookies
Form fields
Hidden fields
• Tools exist that bypass browsers
• Telnet
• Achilles
58
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
59
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)
60
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
61
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
62
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
63
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
64
Questions?
Samples & slides at www.nealford.com
Neal Ford
www.nealford.com
[email protected]
memeagora.blogspot.com
This work is licensed under a Creative Commons AttributionNonCommercial-ShareAlike 2.5 license.
http://creativecommons.org/licenses/by-nc-sa/2.5/