Presentation is loading. Please wait.

Presentation is loading. Please wait.

Web Application and Information Security

Similar presentations


Presentation on theme: "Web Application and Information Security"— Presentation transcript:

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:


Download ppt "Web Application and Information Security"

Similar presentations


Ads by Google