Web Application Security Presented by: Colin English Zerflow

1. Web Application Security Presented by: Colin English Zerflow

3. The Myth “Our site is safe”: We have firewalls in place We encrypt our data We have a privacy policy

4. Worldwide problemWorldwide problem

5. Pressures on the Application Lifecycle Time-to-Market Bringing new applications to market quickly Complexity is Growing Increasing application lifecycle complexity Increasing Business Risks Driven by Security Defects Hacker activity increasing Government scrutiny and regulation increasing Liability precedents for security defects Costs Escalate Dramatically the longer you wait to Find and Fix Bad software costs the economy $59.5 billion a year- cost of breakdowns and repairs (Nat. Institute of Standards & Technology, May 2002) STEVE ORRIN: We all know that there are pressures on the application lifecycle. Let’s review the facts: Time to market demands are ever increasing – bringing new apps up quickly while not compromising their usability and ‘cool factor’ is imperative. Budgets are tight in today’s economic environment and expenses are closely monitored. Unfortunately, this doesn’t translate into a lessening of the market’s expectation for new applications. At the end of the day, the question facing most development teams is ‘How do we meet the functional specification on time with the resources available?” Application complexity is growing – as applications grow in size complexity is added at every step. Businesses and the market expect new applications to perform, meet the functional spec, deploy quickly – and to be secure. And while the deployment pace speeds up, so does the scale and complexity of the sites the new applications are being deployed on. This increases the number and type of potential points of failure within an application --- any one of which could be the source of an enormous problem for the enterprise. Increasing Business Risks Driven by Security Defects. As more business gets done on the web, the risks posed by security defects in deployed applications are accelerating. Hackers are increasingly active and sophisticated about how they choose and target their victims. Dealing with this threat effectively is not trivial. Growing government scrutiny and regulations, including GLBA and HIPAA. With the increase in the value of information and assets accessible through the Web, governments around the world are creating laws and regulations to protect consumers from online fraud and theft. Compliance to U.S. laws like HIPAA and GLBA are for the first time putting the issue of application security into the CEO’s office and board rooms of the largest enterprises in the world. Failure to comply can come at an enormous cost. And finally, recent court activity relating to liability protection for bad software has added new areas of risk for all businesses. Simply put, it doesn’t look like Caveat Emptor (buyer beware) will be sufficient to protect companies from liability claims and class action lawsuits. Enterprises must take systematic and significant measures to ensure that the applications under their domain do not directly or indirectly lead to harm of the customer or the shareholders. Add to this the fact that cost escalates dramatically the longer you wait to find and fix defects, and it is clear things need to change (NEXT SLIDE) STEVE ORRIN: We all know that there are pressures on the application lifecycle. Let’s review the facts: Time to market demands are ever increasing – bringing new apps up quickly while not compromising their usability and ‘cool factor’ is imperative. Budgets are tight in today’s economic environment and expenses are closely monitored. Unfortunately, this doesn’t translate into a lessening of the market’s expectation for new applications. At the end of the day, the question facing most development teams is ‘How do we meet the functional specification on time with the resources available?” Application complexity is growing – as applications grow in size complexity is added at every step. Businesses and the market expect new applications to perform, meet the functional spec, deploy quickly – and to be secure. And while the deployment pace speeds up, so does the scale and complexity of the sites the new applications are being deployed on. This increases the number and type of potential points of failure within an application --- any one of which could be the source of an enormous problem for the enterprise. Increasing Business Risks Driven by Security Defects. As more business gets done on the web, the risks posed by security defects in deployed applications are accelerating. Hackers are increasingly active and sophisticated about how they choose and target their victims. Dealing with this threat effectively is not trivial. Growing government scrutiny and regulations, including GLBA and HIPAA. With the increase in the value of information and assets accessible through the Web, governments around the world are creating laws and regulations to protect consumers from online fraud and theft. Compliance to U.S. laws like HIPAA and GLBA are for the first time putting the issue of application security into the CEO’s office and board rooms of the largest enterprises in the world. Failure to comply can come at an enormous cost. And finally, recent court activity relating to liability protection for bad software has added new areas of risk for all businesses. Simply put, it doesn’t look like Caveat Emptor (buyer beware) will be sufficient to protect companies from liability claims and class action lawsuits. Enterprises must take systematic and significant measures to ensure that the applications under their domain do not directly or indirectly lead to harm of the customer or the shareholders. Add to this the fact that cost escalates dramatically the longer you wait to find and fix defects, and it is clear things need to change (NEXT SLIDE)

7. Application Security Defects Frequent 3 out of 4 business websites are vulnerable to attack (Gartner) Pervasive 75% of hacks occur at the Application level (Gartner) Undetected QA testing tools not designed to detect security defects in applications Manual patching - reactive, time consuming and expensive Dangerous When exploited, security defects destroy company value and customer trust STEVE ORRIN: All of this should lead you to demand better application security. But, if you still need more facts, lets review some more data points: Web application attacks are now more frequent. In Q1 2002, Sanctum found serious security defects in applications in 100% of the commercial sites we audited; The attacks are more expensive to recover from. Costs to patch are high, and the cost of a lost reputation is impossible to quantify. The attacks are more pervasive. A F50 Sanctum customer found serious security defects in over 700 of its deployed applications Finally, the attacks are growing more dangerous, and they usually go undetected. When we look closer at what was actually able to be manipulated on the sites we audited, it is quite scary. In 31% of the sites, full control and access was achieved. In 25% of the sites, privacy was breached, and in 3% of the sites, the entire site was able to be deleted. These are serious problems. Next slide STEVE ORRIN: All of this should lead you to demand better application security. But, if you still need more facts, lets review some more data points: Web application attacks are now more frequent. In Q1 2002, Sanctum found serious security defects in applications in 100% of the commercial sites we audited; The attacks are more expensive to recover from. Costs to patch are high, and the cost of a lost reputation is impossible to quantify. The attacks are more pervasive. A F50 Sanctum customer found serious security defects in over 700 of its deployed applications Finally, the attacks are growing more dangerous, and they usually go undetected. When we look closer at what was actually able to be manipulated on the sites we audited, it is quite scary. In 31% of the sites, full control and access was achieved. In 25% of the sites, privacy was breached, and in 3% of the sites, the entire site was able to be deleted. These are serious problems. Next slide

8. Cost Increases Later in the Lifecycle Security is Addressed As you can see from this slide the relative costs associated with waiting to detect and fix defects increases at a staggering rate from one stage to the next. By the time an application has been deployed, a defect found in it can cost as much as 100X as much to fix than if it had been caught during the development and testing process. This is measured in terms of lost time, resources and lost business as the result of the application being down.As you can see from this slide the relative costs associated with waiting to detect and fix defects increases at a staggering rate from one stage to the next. By the time an application has been deployed, a defect found in it can cost as much as 100X as much to fix than if it had been caught during the development and testing process. This is measured in terms of lost time, resources and lost business as the result of the application being down.

9. Each layer of the application has its own unique vulnerabilities. A vulnerability fixed at one layer may still be exploited at another layer. An exploit at any layer of the application effects the integrity and behavior for the entire application The bottom line, Code and Content Change every day – and contain bugs and backdoors at every layer (NEXT SLIDE) Each layer of the application has its own unique vulnerabilities. A vulnerability fixed at one layer may still be exploited at another layer. An exploit at any layer of the application effects the integrity and behavior for the entire application The bottom line, Code and Content Change every day – and contain bugs and backdoors at every layer (NEXT SLIDE)

10. In the Web application layer, we see 10 major types of application level hacks that can occur with varying degreed of impact on the business ranging from site defacement to eHijacking to downloading the company’s proprietary database. For example, in a text field used to collect data from a customer, a hacker may be able to insert a script that eHijacks customer information from the site through a vulnerability called cross site scripting. (HIGHLIGHT A FEW EXAMPLES)In the Web application layer, we see 10 major types of application level hacks that can occur with varying degreed of impact on the business ranging from site defacement to eHijacking to downloading the company’s proprietary database. For example, in a text field used to collect data from a customer, a hacker may be able to insert a script that eHijacks customer information from the site through a vulnerability called cross site scripting. (HIGHLIGHT A FEW EXAMPLES)

11. 10 Types of Attacks: Development Lifecycle

12. Hidden Field Manipulation Vulnerability explanation: The application sends data to the client using a hidden field in a form. Modifying the hidden field damages the data returning to the web application Why Hidden Field Manipulation: Passing hidden fields is a simple and efficient way to pass information from one part of the application to another (or between two applications) without the use of complex backend systems. As a result of this manipulation : The application acts according to the changed information and not according to the original data Also could be an example of 3rd party missconfigurationAlso could be an example of 3rd party missconfiguration

16. Hidden Field Manipulation - Example

17. Backdoor & Debug options Vulnerability explanation: The application has hidden debug options that can be activated by sending a specific parameter or sequence Why Backdoor and Debug options: Leaving debug options in the code enables developers to find and fix bugs faster Developers leave backdoors as a way of guaranteeing their access to the system As a result of this manipulation : Activation of the hidden debug option allows the hacker to have extreme access to the application (usually unlimited).

21. Cross Site Scripting Vulnerability explanation: A third party creates a link (or sends an email) and the URL contains a parameter with a script – once the user connects, the site runs this script Why Cross Site Scripting: Many parameters are implanted within the HTML of following responses, while not checking their content for scripts. As a result of this manipulation: “Virtual hijacking” of the session. Any information flowing between the legitimate user and site can be manipulated or transmitted to the evil 3rd party.

22.

23. Parameter Tampering Vulnerability explanation: Parameters are used to obtain information from the client. This information can be changed in a site’s URL parameter Why Parameter Tampering: Developers focus on the legal values of parameters and how they should be utilized. Little if any attention is given to the incorrect values As a result of this manipulation : The application can perform a function that was not intended by its developer like giving access to customer information

26. The Missing Piece Protection for the application itself Applications are vulnerable Developers lack tools and know how to build secure applications No amount of QA testing will capture all the security vulnerabilities Systematic failures in the application can be engineered by hackers

27. Web Application Hacking - Results

28. Auditing & Testing The process Coverage of relevant business process Full inspection of client side scripts and comments Full inspection of application interfaces Analysis of potential vulnerabilities Testing of potential vulnerabilities Check for installation of known patches The knowledge Complete understanding of the application logic Complete knowledge of application manipulation methods Awareness of all the known patches issues Complete understanding of most secure configuration of all tools

29. Auditing – The Problem Multiple points of people failure Development, QA, Operations, Vendor software, Outsourcing New third party bugs discovered every day site exposed during patch latency Site Complexity many line of codes and application interactions Compressed application development cycle time to market needs will impact development and QA Distributed Knowledge Any single person does not have all the knowledge needed for a full audit.

30. What is a Viable Solution? VIABLE = Positive Security Model: Assessment: bullet-proof applications before production Application Firewalls: block, log and alert against known/unknown attacks Behavioral/ Policy-based Automatically builds a policy in real time for the site Allows only intended business interactions Maintains intended application behavior e.g., Code Red and Nimda blocked without updates or rules Not Viable = Negative Security Model: Signature/Rules-based – Blocks known attacks based on signatures, heuristics or rules e.g., - need patch installed or signatures written to block Code Red & Nimda

31.