1. Web Application and Information Security
February 24th, 2004
Mark Lachniet, Analysts International

2. 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) ISC^2
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

3. Agenda
Overview of application security
Web application architecture
Conceptual and logical designs
What can go wrong
Common types of web application flaws
Real world exploitation examples
How to protect your web sites
Security assessment software and practices
Conclusions
Discussion

4. Overview of Application Security
I.T. security has been around as long as computers
However, the way in which data has been stored, processed and used has changed a lot over the years
Where once there was a mainframe with a number of directly connected terminals, we now have demands for Internet access, VPN and wireless
Where once there was a physical “zone of control” that was mainly limited to the office (or the occasional dial-up) we must now provide access to data to the world at large
This has placed an increased burden on the auditor to protect the conflicting interests of the organization
An inherent conflict - Access or Security?
Greatly increased demands for technical understanding of diverse computing topics

5. The CIA Triangle
The CIA Triad

6. The CIA Triad Confidentiality Integrity Availability Encryption
Secure storage of data
Relates to privacy policy and risks
Integrity
Accuracy
Assurance that data has not been modified / corrupted
Evidenced by adequate internal controls
Availability
Server load capacity
Server redundancy / recoverability
Resilience to Denial of Service issues

7. External Pressures

8. External Pressures
In addition to the internal impetus to protect resources, there are any number of external pressures
The Gramm-Leach-Bliley Act of 1999, section requires that subject organizations “develop, implement, and maintain a comprehensive written information security program that contains administrative, technical and physical safeguards.”
The Health Insurance Portability and Accountability Act (HIPAA) calls for all subject organizations to “assess its own security needs and risks and devise, implement and maintain appropriate security to address its business requirements.”
The Sarbanes-Oxley Act requires the CEO and CFO to personally certify finances, and conclusions about the adequacy of internal controls
Freedom of Information Act (FOIA) requests must be held for certain periods of time, with specific rules

9. The User Community

10. The User Community
All of this must be done while still meeting the needs of the user community, both internal and external
Different user communities have different access requirements
Different user communities also have different risk factors
The end result is that there is a complex mix of users, requirements and security levels that must be documented, implemented, maintained and monitored
Often, the need for access in the short term compromises the need for security in the long term
Web applications are a perfect example of this, and will be our focus

11. Web Applications
Where a conventional application requires physical proximity and client software, web access is intended to be accessible to the widest possible audience
As a result, they are typically open to the entire Internet community
It is logical to assume that the larger the user community is, the more likely it is that someone may choose to analyze the security of the application
Due to the fact that a good hacker can effectively cover their tracks and anonymously probe the security of applications, there is very little risk to the hacker to do so (as compared to an attack that requires physical proximity)
Thus, web applications may require more security than others

12. 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!

13. Logical / Physical Overview
Let us pretend that we are looking at a State of Michigan web site (note: this is only pretending!!)
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 State of Michigan Human Resources HRMN system

14. Logical / Physical Overview

15. Implications
In order for this all to work, the HRMN 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?

16. 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
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!

17. Recent Example
Friday, February 13, 2004 · Last updated 8:31 p.m. PT
SACRAMENTO, Calif. -- Hackers broke into a state agency's server containing the sensitive personal information of tens of thousands of people who work as nannies, butlers, and gardeners, and those who employ them.
The hackers gained access to employee's names, Social Security numbers and wage records, and some employers' Social Security numbers, Callori said.
This is, unfortunately, more than enough information to cause harm, such as identity theft

18. Types of Flaws in Web Applications
Lets look at the statistics from the previously quoted article:
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

19. 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

20. 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

21. 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

22. 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

23. Real Life SQL Injection Example

24. 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….

25. How to Protect Yourself While Surfing
Bear in mind that most of the web sites you routinely type your address and credit card information into probably have the exact same flaws (92% of them??)
Try to use “big name” companies like Amazon.com instead of “small change” companies that may not have the resources to do security properly – ask them!
Always use a credit card. You will only be liable for the $50 or so, if that
Routinely monitor your credit – use an automated monitoring system that sends you or printed letters when someone queries your credit – that way you can catch it quickly and squash the problem
Never respond to requests to change information, view a web page, or install a piece of software! Verify!
Note: I have had my CC# changed two times now, all due to my information being compromised by poor security, but it never amounted to more than an annoyance to me
Check out Frank Abagnale’s web site:

26. How to Protect Your Organization
As an auditor, there are several things you want to consider when analyzing web applications:
Has a design of the system been validated both by app. Dev, DBA and I.T. security staff?
Has an adequate System Development Life Cycle (SDLC) been used throughout the project to promote consistent and quality code?
Have programmers been trained in secure programming standards? Is there an internal Q.C.?
Has a proper change control system been used to develop and maintain the system?
Has the system had a formal web application security assessment? Is the system “hardened”? (many internal and external resources can help with this)

27. Security Products – Web Application
Although this is a relatively new area, a number of products exist to assist an I.T. auditor
One such product, the one that is used at Analysts International, is “SPI WebInspect” from SPI Dynamics, Inc.
This product is very flexible, and can save thousands of hours of manual assessment time
Can export pieces of data, print detailed reports, and maintain full information about the scanning activity that has occurred
One of the better web application security tools available, and reasonably priced
As always, don’t take my word for it, do a product evaluation of your own

28. Security Products - Nessus
To analyze the underlying operating system and web server, you will want to use a vulnerability assessment tool
A number of tools, both commercial and open source are available
By far, the most recognized no-cost tool is Nessus
Installing and configuring Nessus requires a UNIX / Linux system, but is fairly straight-forward
For those who do not have the time or resources for UNIX, a commercial Windows version of Nessus is available from Tenable Security
Free evaluation copies of the Tenable product are available

29. 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
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
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:

30. Wrapping Up
To take this discussion back to our common theme of the day, create some assumptions
A web site similar to this may already exist in your organization
Most web sites of this type, especially internally developed ones, have not been properly assessed for web application security flaws
Statistically speaking, there may be about a 90% chance of there being such a flaw already
The user community is probably the Internet at large, and can theoretically be accessed anonymously by anyone who cares
The database contains sensitive personal information, probably sufficient for an ID thief
Therefore, one might theorize that…. This is an important issue that needs attention, and it is up to the auditors to raise awareness about it!

31. Discussion This presentation to be available at:
Mark Lachniet CISSP, CISA, MCSE, MCNE, CCSE, LPIC-1, TICSA
Technical Director, Security Group Analysts International (517) (voice) (517) (fax) mailto: