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

Internal Network(Protected Machines)

DMZ Network(Internet Accessible Machines)

The Internet

Bad Person

Good Person

Company Firewall

Demonstrative WebApplication Diagram

Internet Router

Self ServiceWeb Server

Human ResourcesDatabase

• 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?

Implications

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 flawshttp://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. Cross-site scripting (80 per cent)2. SQL injection (62 per cent)3. Parameter tampering (60 per cent)4. Cookie poisoning (37 per cent)5. Database server (33 per cent)6. Web server (23 per cent)7. 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

Internal Network(Protected Machines)

DMZ Network(Internet Accessible Machines)

The Internet

Bad Person

Good Person

Company Firewall

Exchange e-Mail

ACME Corp Network

Internet Router

Web Server

User Laptop Printer

File Server User Workstation

!!

!!

!

! !

!

Best Source for Logging

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=299475http://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/2243271 (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-syslog-

overview.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=/technet/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 LachnietCISSP, CISA, MCSE, MCNE, CCSE, LPIC-1Technical Director, Security GroupAnalysts International(517) 336-1004 (voice)(517) 336-1100 (fax)mailto: mlachniet@analysts.com