Transcript No Slide Title

Web Application Security
October 7th, 2004
Mark Lachniet, Analysts International
Introductions
• Mark Lachniet, Technical Director of Analyst
International’s Security Services Group
• Technical lead developing for services,
methodology, quality control, technical presales
• Certified Information Systems Auditor (CISA)
from ISACA
• Certified Information Systems Security
Professional (CISSP)
• Linux LPIC-1, Novell Master CNE, Microsoft
MCSE, Checkpoint CCSE, TruSecure ICSA, etc.
• Former I.T. director of Holt Public Schools
• Frequent speaker for local organizations
Conceptual Overview of Web Apps
• Web applications are
generally developed
in Tiers
–
–
–
–
User / Client
Web Server
Business Logic
Database
• In many cases, the
database is the same
one that holds other
critical organizational
data!
Logical / Physical Overview
• Let us pretend that we are looking at a real web site
at your location
• The purpose of the web site is to allow “self service”
access to Human Resources information:
–
–
–
–
–
Pay stubs, deductions, direct deposit bank name
Demographic information
Emergency Contact information
Education
Dependants (names, ages)
• The application was written by a combination of
internal and external programmers
• The application was written in Microsoft .NET, and
communicates with the actual Human Resources
system
Logical / Physical Overview
Demonstrative Web
Application Diagram
Self Service
Web Server
Bad Person
DMZ Network
(Internet Accessible Machines)
The Internet
Internet Router
Company Firewall
Human Resources
Database
Internal Network
(Protected Machines)
Good Person
Implications
• In order for this all to work, the HR system needs to
trust the self service web application to access data
• Thus, the program logic of the self service
application may be critically important, responsible
for ensuring that:
–
–
–
–
Users are properly authenticated
Users are authorized to use the system
Adequate logging of activity takes place
The Internet-facing components do not have known
security flaws
• In short, a part of the security of the human
resources database now lies in an Internet-facing
web application, possibly bypassing the more
established and mature database security
• What could possibly go wrong?
What Can Go Wrong???
• Frankly, a lot…..
• Secure programming practices have not really been
taught in higher education
• Productivity pressures have made security a
secondary priority
• A lot of insecure web sites have been implemented
• In fact, a recent study found that no less than 92% of
web pages surveyed over a 4-year period had serious
security flaws
http://www.vnunet.com/News/1152521
• Are you confident that your web site is within the
fortunate 8%?
• If you don’t have an explicit set of controls for
application development, security and ongoing
testing, you shouldn’t be!
Types of Flaws in Web Applications
•
Lets look at the statistics from the
previously quoted article:
1.
2.
3.
4.
5.
6.
7.
•
•
•
Cross-site scripting (80 per cent)
SQL injection (62 per cent)
Parameter tampering (60 per cent)
Cookie poisoning (37 per cent)
Database server (33 per cent)
Web server (23 per cent)
Buffer overflow (19 per cent)
My personal experience indicates that these
numbers are about right
Any one of these flaws could lead to a
disclosure of critical or protected data
Lets look at a few examples
Cross-Site Scripting
• Occurs when input from a user is not “sanitized”
before being re-displayed on a web site
• For example, an Internet guest book may allow you
to enter a message, along with the time and date that
you visited a web site
• It may be possible to craft this message in such a
way that users’ Internet browsers interpret the
message as HTML code, instead of plain text
• If this happens, person A can make it appear to
person B’s computer that a web site (presumably a
trusted one) is the source of a tricky attack
• This commonly used to do things like steal
authentication information, or redirect to a
“phishing” web site to harvest passwords, credit card
numbers or bank account numbers
Real Life Example of CSS
• While working for a customer, analyzing a well known
SSL VPN appliance, I discovered a CSS bug
• I then created a proof of concept to demonstrate this bug
• I created a (virtually) identical copy of the VPN server’s
login page, and put this on a server that I had control of
• I then created a special CSS web address (URL) that,
when entered, would redirect the user transparently to
this external web site
• The fake web site said “session has timed out, please log
in again” message, and had a place to log in again
• When the user entered their username and password on
the fake login, this information was written to disk on my
“hacker” computer, and the user was redirected back to
the *real* VPN server’s “incorrect password” page
• The end user would simply think that their session had
timed out, and that they had mis-typed their password
SQL Injection
• The next most common flaw, SQL injection, is worse
• In this case, a hacker would find a part of the application
code that did not perform proper input sanitization
• By passing special characters in form fields (e.g. a place
to type in a query or address) it is then possible to embed
additional commands for the HR database
• Since the application server is “trusted” by the back end
database, it assumes that the request is legitimate and
performs the query
• The “normal” results, as well as the database commands
entered by the hacker are displayed in the browser
• This attack can be used to completely bypass application
and database security
• In our working example, an identity thief hacker could
then print out the names, SSN#’s and addresses of all
employees and use this to steal their ID
Real Life Example of SQL Injection
• While analyzing a production Internet web site during a
WASA (Web Application Security Analysis) I discovered
a SQL injection flaw in the application code
• With this knowledge, I configured a program called “data
thief” to assist me in demonstrating the vulnerability
• Using data thief, I was able to copy the entire back-end
database, with all of the data, including usernames and
passwords, across the Internet to my computer
• Using this database of logins and passwords, I was able
to log in, and access the application as an administrator
• At that point, I also had the ability to run software on the
database server, which was on the internal, protected
network
• If I were a bad guy, I could have used this access to
compromise additional systems on the Internal network
Real Life SQL Injection Example
Other Web Application Risks
• There are a number of other risks that need to
be looked at:
–
–
–
–
Ability to bypass authentication systems
Ability to steal user “sessions”
Flaws in the underlying operating system / web server
Flaws in the “chain of trust” (relying on an additional
system for some security component such as a SSO
(Single Sign On) system)
– Flaws that allow a hacker to deny service to the
system (e.g. by using all of the licensed connections,
flooding the server, or causing a software crash)
– Reliance on client-side security (especially client-side
scripting)
• And so on….
Input Validation
• The key to fixing the vast majority of web
application flaws is proper input validation
• All client-side input should be filtered at the
server side (never trust anything coming
from the client, as it can be modified)
• Only those characters which are explicitly
expected should be allowed
• Dangerous characters such as ; ‘ , < > should
be stripped or rendered in a non-interpretable
format
• Use database stored procedures to limit the
type of data that can be inserted into a
database query (data typing)
Use of Encryption
• Any web site that is important enough to have a user
ID and password should use encryption
• In the web world, this is a SSL connection (https)
• Indicated by the presence of a locked icon in your
browser toolbar, or similar
• This will prevent the casual interception of data by a
hacker, including usernames and passwords
• To be done well, requires a valid SSL certificate
from a company such as Verisign at a cost of
approximately $400+ for your web server
• Once a user has authenticated, the remainder of the
session should be over the encrypted channel
• Any encryption is better than no encryption – even
basic 40bit SSL is too bothersome for most to break
Authentication Issues
• User authentication is critical for web servers, since
you are potentially serving a global audience
• Strong password systems (NT auth) are better than
weak (e.g. default HTTP Basic)
• Account lockout should be used to minimize the
risk of “brute force” attacks
• Strong passwords should be used (e.g. long,
complex passwords that are not in the dictionary)
• For truly important applications, use two-factor
authentication such as biometrics (fingerprint
readers) or SecurID tokens
• Consider using mandatory client certificates
(requires pushing down a certificate to the client) in
addition to a username and password
I Forgot My Password
• The “I forgot my password” feature should be
implemented securely
• Even if the question is answered correctly, the
current password should never be displayed
• Questions that are too easy (e.g. your favorite
restaurant) could be determined by stealing a
credit card bill or looking at a personal web page
(“look at the nice pictures of my favorite dog!”)
• E-mailing a complex URL with a “set new
password” web page is better
• This “invitation” to reset should be time limited
(e.g. 30 minutes or similar) because it may
linger in someone’s inbox
Data Caching Issues
• Many web sites (e.g. portals) are accessed from
public locations such as libraries and coffee shops
• This activity may leave remnants of sensitive data on
the workstation caches
• To minimize this risk, the web site should:
– Use cache-control directives
– Ensure that URL’s (left in browser history, in
index.dat in IE) do not have a user ID or
password embedded in it
– Use a graphical PIN type login (this requires
clicking, and cannot be captured by a keylogger)
• There should be a remote access policy that requires
a certain level of security (A/V) and conduct
(practices) for users
Cookie Management
• Cookies are small pieces of information that are stored on
the local workstation
• Come in two varieties – persistent and non-persistent
(stored to disk, or just in RAM)
• They typically contain a user ID, or perhaps a web site
preference (e.g. show me the U.S. version of CNN.com)
• They are tied to a domain such as cnn.com and cannot be
accessed or modified by servers in other domains
• Are often used for session tracking, for example holding a
temporary session ID
• Cookies can be viewed and intercepted in transit (using a
protocol analyzer) and programmed into a hacker’s
computer
• If they are used for security purposes, can be a problem
• Best practices suggest linking a cookie to a source IP
address, but this is not perfect (imagine a shared firewall)
Logging and Auditing
• Most web applications have very poor logging
capabilities by default
• Logging is required in order to create an audit trail
• Logging may also be required by some regulations as
well, depending on usage
• Logging is essential for forensic purposes (catching and
prosecuting a hacker or terminating a bad employee)
• Logs should be reviewed on a periodic basis, and
documentation maintained about the fulfillment of these
duties (e.g. a written log that duties have been done)
• Ideally, an automated tool will be used to sift through the
logs and identify exceptions
• Log data must be gathered from multiple levels,
including network, OS, web server, application and
database
Common Sources Network Data
NetIQ (Web Trends) Firewall Suite
• Converts large amounts of firewall data into handy charts
and graphs
• Tracks both “packet” and “web browsing” data
Microsoft Windows Logging
• Microsoft products use their own logging system
• There are a number of disparate places for logs:
– Windows Event Log (MMC plugin)
– Internet Information Systems Logs (www, FTP,
SMTP)
– DHCP server logs
– Microsoft Exchange
– DNS logs, etc. etc.
• Because of this, it is difficult to set up centralized
logging for Windows machines “out of the box”
(note: UNIX has the same problem)
• Fortunately, a number of products have been created
to help us with this task
Windows Event Log Example
The Event ID is a
critical component
that you can search
for
Supplemental
information can
also be useful
Windows Event Log Example Cont.
• The previous was a perfect example of
something you might want to know about
• Not even this level of information is available by
default – it must be manually configured on
most systems (Windows 2003 may be an
exception)
• !! The default level of logging is useless!!
• No system should be “green lighted” unless
there is some kind of formal system hardening
methodology that includes adequate logging of
the operating system
• Also, note that the event log only tracks some
events, and does not include web servers, etc.
Configure Event Viewer Settings
• Within the event viewer, you need to set:
– The size of the event log
– What happens when the event log reaches maximum
size (overwrite, rollover, nothing)
– How many days to store the logs for before rolling
over
• There is also the option to “hard stop” the server if it
cannot log – this may be needed for high-security
systems. See:
http://www.microsoft.com/technet/treeview/default.asp
?url=/technet/columns/security/askus/aus1101.asp
Windows Event Logging
• For a list of Windows event ID’s check out:
http://support.microsoft.com/?kbid=299475
http://support.microsoft.com/?kbid=301677
• There are a variety of things that you can audit for:
–
–
–
–
–
Login / logout
Account management (create, delete, modify)
Directory service access
Object access (files, printers)
Use of privileges (backup)
• Yet, there are many things you can’t monitor with
event log:
– Internet Information Server
– Microsoft Exchange, etc.
Web Server Logging
• The web server (IIS, Apache, etc.) also logs a lot of
data that is useful for tracking abuse
• Often the only way to track a session to a source IP
address
• Ensure that maximal logging is configured
• Back up logs regularly (to another machine, to tape,
etc.)
• Use log analysis tools where possible (e.g. Web
Trends log analyzer) to identify unusual activity
• Use time synch on all devices to facilitate log
analysis between multiple systems such as web
servers and firewalls
Application Layer Logging
• Applications should be explicitly written to
include logging routines – it is usually the
only place it can be done
• Things to log (from OWASP):
– Login and logout of users
– Critical transactions (eg. fund transfer across
accounts)
– Failed login attempts
– Account lockouts
– Violation of policies
• Including User ID, timestamp, source IP
address, action taken, error codes, etc.
Database Layer Logging
• Databases can also maintain a log of activity
• This may introduce a system overhead, but it
might be better on the database than on the
application server
• Carefully target logging to critical events
(database permission functions) and data (SSN#,
financial data, etc.)
• Consider logging to an external source, in case
the server is hacked and the records are removed
• There are often “rollback” or transaction logs
that are kept as part of disaster recovery systems
Prevention Strategies
• Only purchase products that have had some kind of
security analysis (work this into the RFP process)
• Good luck finding any  (never trust a vendor!!)
• Use secure coding standards for internally developed
applications (and send your people to training!!!)
• Use Intrusion Prevention Systems, either host based
(e.g. Entercept) or applicance based (e.g. Symantec
Gateway) to catch abuse*
• Perform web application security assessments against
the application – you can hire companies to do this, or
you can learn to do it yourself
• Use “defense in depth” to put as many barriers to
hacking as possible (e.g. separate web servers from DB
servers through a firewall, use strong authentication
such as SecurID, etc.)
Security Best Practices
• A lot of information is available for programmers,
auditors and I.T. staff on web application security issues
• The most referenced one is the Open Web Application
Security Project at http://www.owasp.org
• OWASP has specific guidelines for what programmers
should and shouldn’t do, as well as detailed information
on what the issues are and how they can be detected
• For more information on how to go about assessing an
application using accepted methods, check out “Open
Source Security Testing Methodology Manual” at
http://www.isecom.org/projects/osstmm.shtml
• A number of product-specific web sites for major vendors
also exist. A good one for both theory and practice is the
Microsoft “Building Secure ASP .NET Applications”
600pg PDF at:
http://www.microsoft.com/downloads/details.aspx?displaylang
=en&FamilyID=055FF772-97FE-41B8-A58C-BF9C6593F25E
Links
http://www.doit.wisc.edu/security/resources/bestpract/logging.
asp (windows settings)
http://www.sans.org/rr/papers/index.php?id=1100 (using Kiwi
in a Cisco and Microsoft environment)
http://www.sans.org/rr/papers/index.php?id=1101 (Syslog in a
Microsoft environment)
http://www.owasp.org (best practices in web application
development)
http://www.databasejournal.com/features/mssql/article.php/22
43271 (Enhanced SQL Security auditing)
http://www.winsyslog.com/en/FAQ/index.php (syslog products
for Windows)
http://www.campin.net/syslog-ng/faq.html (Syslog NG
products)
http://www.loganalysis.org/ (web site / listserve dedicated to
log analysis)
http://www.loganalysis.org/sections/audit/tbird-syslogoverview.pdf (overview of Syslog in general)
More Links
http://windows.about.com/library/tips/bltip316.htm (turning
on logging of DHCP)
http://www.microsoft.com/technet/treeview/default.asp?url=/te
chnet/columns/security/askus/aus1101.asp (enabling
auditing on Windows)
http://www.jsiinc.com/SUBI/tip4100/rh4108.htm (list of
security events to audit for)
http://www.eiqnetworks.com/products/systemanalytics.shtml
(commercial product to analyze Windows and UNIX
logs)
http://www.mwagent.com/en/ (MonitorWare)
http://www.sans.org/rr/papers/index.php?id=201 (Effective
logging and the use of the Kiwi syslog utility)
Discussion
• This presentation to be available at:
http://lachniet.com/powerpoint
Mark Lachniet
CISSP, CISA, MCSE, MCNE, CCSE, LPIC-1
Technical Director, Security Group
Analysts International
(517) 336-1004 (voice)
(517) 336-1100 (fax)
mailto: [email protected]