+ All Categories
Home > Documents > Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information...

Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information...

Date post: 26-Dec-2015
Category:
Upload: bernice-leonard
View: 217 times
Download: 4 times
Share this document with a friend
57
Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.
Transcript
Page 1: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

Closing the Door on Web Application Attacks

FISSEA 2004

Confidential and proprietary information ©2004, MagniFire Websystems Inc.

Page 2: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

2Confidential and proprietary information ©2004, MagniFire Websystems Inc.

2

Today’s Session

What are the risks?

Why don’t traditional solutions work?

What can be done?

Page 3: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

3Confidential and proprietary information ©2004, MagniFire Websystems Inc.

3

Ensuring 100% protection

In Israel the government has an effective way to protect sensitive data from internet hackers…

Page 4: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

4Confidential and proprietary information ©2004, MagniFire Websystems Inc.

4

However, Government Is Moving Online

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000

U.S. Dept. of the Treasury

U.S. National Aeronautics & Space Administration

U.S. Dept. of Education

U.S. Executive Branch

U.S. Dept. of State

U.S. Dept. of Labor

U.S. Dept. of Energy

U.S. Dept. of Energy

FirstGov

U.S. Central Intelligence Agency

U.S. National Archives & Records Administration

U.S. National Archives & Records Administration

Unique Audience (2002) (Source: Nielson NetRatings)

Page 5: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

5Confidential and proprietary information ©2004, MagniFire Websystems Inc.

5

Web Servers and Web Applications:Prime Targets for Attacks

“64% of the 10 million security incidents Security Focus tracked the first week of Feb 2002, targeted port 80.”(Information Week magazine)

“Nearly 70% of all attacks in the first quarter of 2002 used port 80, a common port devoted to Web traffic.”(ISS Internet Risk Impact Summary Report for 2002)

Page 6: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

6Confidential and proprietary information ©2004, MagniFire Websystems Inc.

6

What are the Risks ?

Access to user databases Social Security Numbers (CA) Police Records (MI)

Financial loss as a result of fraud

Theft of secure or sensitive information

Page 7: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

7Confidential and proprietary information ©2004, MagniFire Websystems Inc.

7

Web Applications Are The Weakest Point

System Network

Desk

top

Access

Net IDS

Host IDS & Secure OS

Firewall

Antivir

us

Appl

icatio

n

DATA

“64% of the 10 million security incidents tracked targeted port 80.”

(Information Week magazine)

Page 8: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

8Confidential and proprietary information ©2004, MagniFire Websystems Inc.

8

Major Categories of Web Application Vulnerabilities

Almost all Web applications are

exposed“From 45 applications, @stake found nearly 500 ‘significant’ security defects, with an average of at least 10 per assessment”(@Stake Study on Web application security)

Improper validation of user input by the Web application server side (relying on client side validation):

Cookie Poisoning Hidden Field Manipulation Parameter Tampering Stealth Commanding (e.g. SQL/OS Injection) Cross-site Scripting Application Buffer Overflow URL & Unicode encoding

Backdoors and Debugs option (left in the application)

Poor Session Management, Access Control & Authentication

Third Party Misconfiguration

Page 9: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

9Confidential and proprietary information ©2004, MagniFire Websystems Inc.

9

– Modifying form fields allowing damaging data to pass to the web application

– Example: Online Retail Store Changing prices and stealing goods Hidden field hacking in 3rd party shopping cart software

Hidden Field Manipulation

Page 10: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

10Confidential and proprietary information ©2004, MagniFire Websystems Inc.

10

Hidden Field Manipulation - Example

Page 11: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

11Confidential and proprietary information ©2004, MagniFire Websystems Inc.

11

Hidden Field Manipulation - Example

Page 12: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

12Confidential and proprietary information ©2004, MagniFire Websystems Inc.

12

Hidden Field Manipulation - Example

Page 13: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

13Confidential and proprietary information ©2004, MagniFire Websystems Inc.

13

Hidden Field Manipulation - Example

Page 14: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

14Confidential and proprietary information ©2004, MagniFire Websystems Inc.

14

Hidden Field Manipulation - Example

Page 15: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

15Confidential and proprietary information ©2004, MagniFire Websystems Inc.

15

Cookie Poisoning

–Modifying the cookie file causing the return of unauthorized information or enabling performance of activity on behalf of another user

–Example: Online account administration– Impersonation

Page 16: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

16Confidential and proprietary information ©2004, MagniFire Websystems Inc.

16

Cookie Poisoning - Example

Page 17: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

17Confidential and proprietary information ©2004, MagniFire Websystems Inc.

17

Cookie Poisoning - Example

Page 18: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

18Confidential and proprietary information ©2004, MagniFire Websystems Inc.

18

Cookie Poisoning - Example

Page 19: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

19Confidential and proprietary information ©2004, MagniFire Websystems Inc.

19

Cookie Poisoning - Example

Page 20: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

20Confidential and proprietary information ©2004, MagniFire Websystems Inc.

20

Cookie Poisoning - Example

Page 21: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

21Confidential and proprietary information ©2004, MagniFire Websystems Inc.

21

Buffer Overflow

–Sending too much data in a request to the application, attacking either 3rd party or internally developed code

Page 22: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

22Confidential and proprietary information ©2004, MagniFire Websystems Inc.

22

Buffer Overflow - Example

Page 23: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

23Confidential and proprietary information ©2004, MagniFire Websystems Inc.

23

Buffer Overflow - Example

Page 24: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

24Confidential and proprietary information ©2004, MagniFire Websystems Inc.

24

Buffer Overflow - Example

Page 25: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

25Confidential and proprietary information ©2004, MagniFire Websystems Inc.

25

Cross Site Scripting

– Inserting scripting languages into text fields to be displayed to other users

– Example: Add an Item Section of Web SiteSite defacement

Changing field parameters

Page 26: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

26Confidential and proprietary information ©2004, MagniFire Websystems Inc.

26

Cross Site Scripting - Example

Page 27: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

27Confidential and proprietary information ©2004, MagniFire Websystems Inc.

27

Cross Site Scripting - Example

Page 28: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

28Confidential and proprietary information ©2004, MagniFire Websystems Inc.

28

Cross Site Scripting - Example

Page 29: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

29Confidential and proprietary information ©2004, MagniFire Websystems Inc.

29

Cross Site Scripting - Example

Page 30: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

30Confidential and proprietary information ©2004, MagniFire Websystems Inc.

30

Cross Site Scripting - Example

Page 31: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

31Confidential and proprietary information ©2004, MagniFire Websystems Inc.

31

Known Vulnerabilities & Misconfiguration

– Exploiting configuration errors in 3rd party components, such as web and database servers

– Newdsn.exe can be used by an attacker to create files anywhere on your disk if they have the NTFS correct file permissions to do so. Newdsn.exe can also be used to overwrite the DSNs on existing on-line databases making the information contained in the database inaccessible. This file, getdrvrs.exe, dsnform.exe and mkilog.exe should be deleted.

Page 32: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

32Confidential and proprietary information ©2004, MagniFire Websystems Inc.

32

Known Vulnerabilities & Misconfiguration

Page 33: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

33Confidential and proprietary information ©2004, MagniFire Websystems Inc.

33

Known Vulnerabilities & Misconfiguration

Page 34: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

34Confidential and proprietary information ©2004, MagniFire Websystems Inc.

34

Parameter Tampering

– Modify the parameters being passed as part of the URL

– Example: Online Auction SiteUser Account Access

Forbidden SQL Query via wrong parameters

Page 35: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

35Confidential and proprietary information ©2004, MagniFire Websystems Inc.

35

Parameter Tampering - Example

Page 36: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

36Confidential and proprietary information ©2004, MagniFire Websystems Inc.

36

Parameter Tampering - Example

Page 37: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

37Confidential and proprietary information ©2004, MagniFire Websystems Inc.

37

Forceful Browsing

– Jumping directly to pages that can normally only be accessed through authentication mechanisms

– Example: Auction Web SiteBreaching users’ privacy

Direct file access

Page 38: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

38Confidential and proprietary information ©2004, MagniFire Websystems Inc.

38

Forceful Browsing - Example

Page 39: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

39Confidential and proprietary information ©2004, MagniFire Websystems Inc.

39

Forceful Browsing - Example

Page 40: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

40Confidential and proprietary information ©2004, MagniFire Websystems Inc.

40

Forceful Browsing - Example

Page 41: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

41Confidential and proprietary information ©2004, MagniFire Websystems Inc.

41

Reasons for Web Application Vulnerabilities Applications were written according to client-server security

standards (rely on client-side validation)

The complexity of platforms and environments makes secure coding very difficult

Web developers focus on functionality and performance, not on security

Web developers are not trained for secure programming

Bugs in Web infrastructure (OS and Web platforms) and Web applications

Web sites are changed/updated frequently

Threat is exacerbated by the availability of: Web application client-side source code (hackers gain information

for planning attacks) Widely available, free, easy to use hacking tools

Page 42: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

42Confidential and proprietary information ©2004, MagniFire Websystems Inc.

42

Existing Security Solutions are Existing Security Solutions are InadequateInadequate

Page 43: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

43Confidential and proprietary information ©2004, MagniFire Websystems Inc.

43

Traditional Security Solutions Don’t Protect Web Applications

Current solutions are not enough (CSI & FBI 2002):89% of respondents have a firewall60% of respondents used at least one Intrusion Detection SystemHowever: 40% reported system penetration from the outside 40% reported DoS attacks

Firewalls: “Firewalls offer little protection at the application layer because ports within the firewall have to be left open for communication” (IDC 2002)

Network IDS:

“Intrusion detection systems are a market failure, and vendors are now hyping intrusion prevention systems, which have also stalled. Functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic blocking, as well

as antivirus activities." (Gartner, 2003)

Page 44: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

44Confidential and proprietary information ©2004, MagniFire Websystems Inc.

44

Fundamental Problem with IPS/IDS: ‘Negative Security Logic’

How It Works: Let everything through except what can be identified as malicious traffic (based on attack signatures & traffic characteristics)

Problems Protects only against known attacks

(signature and/or characteristics are known and defined) Requires constant updating of attack signatures and / or

characteristics database Doesn’t protect against “Zero Day” attacks Doesn’t protect against attacks based on illegal user input:

Cookie Poisoning and Hidden-Field Manipulation Parameter (Form-Field) Tampering Forceful Browsing Backdoors and debug-option exploitation

Page 45: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

45Confidential and proprietary information ©2004, MagniFire Websystems Inc.

45

TrafficShield FW NIPS HIPS

Known Web Worms Yes Limited Yes YesUnknown Web Worms Yes No Limited PartialKnown Web Vulnerabilities Yes Limited Partial YesUnknown Web Vulnerabilities Yes No Limited PartialIllegal Access to Web-server files Yes Limited No YesForceful Browsing Yes No No NoFile/Directory Enumerations Yes No Limited NoBrute Force attacks Yes No No NoBuffer Overflow Yes Limited Limited PartialCross-Site Scripting Yes Limited Limited NoSQL/OS Injection Yes No No PartialCookie Poisoning Yes No No NoHidden-Field Manipulation Yes No No YesParameter Tampering Yes No No NoFlood attacks (GET, 404) Yes Limited Limited NoSSL Flooding Yes No Limited No

Traditional Security Solutions Don’t Protect Web Applications

Page 46: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

46Confidential and proprietary information ©2004, MagniFire Websystems Inc.

46

Current Application-Layer Approaches

Scanning HTML code for known breaches and then rewriting it is ineffective and costly compared to installing an application firewall.

Time-Consuming due to high rate of false positives that must be evaluated.

Ineffective since it does not find all vulnerabilities, thereby requiring additional techniques (e.g. manual code review) in order to ensure protection.

Requires Code Rewrites which are very expensive in terms of both time and resources

Slows Down Product Development since every change in the application requires new “scan & fix” iteration

Useless for 3rd party web applications since they can’t be altered

Defenseless against new threats, since it only looks for known vulnerabilities

Scan-and-Fix

Page 47: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

47Confidential and proprietary information ©2004, MagniFire Websystems Inc.

47

The Solution: The Solution: Granular & Tailored Granular & Tailored

Application-Specific SecurityApplication-Specific Security

Page 48: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

48Confidential and proprietary information ©2004, MagniFire Websystems Inc.

48

Solution Criteria Web Application Firewall Using Positive Security Logic

Model application extremely accurately

Auto configuration / customization around app

No false positives or false negatives

Minimal ongoing policy management

No latency introduced (<1 ms)

1

2

3

4

5

Page 49: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

49Confidential and proprietary information ©2004, MagniFire Websystems Inc.

49

Web Application

Model the Application Flow

Application Flow Application Flow Model

CHANGEUSER ID

Actions not known to be legal can now be blocked.

- wrong page order

- invalid parameter

- invalid value

- etc.

Page 50: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

50Confidential and proprietary information ©2004, MagniFire Websystems Inc.

50

The Application Flow Model

Legal user will request: Links existing in the Web page currently browsed

OR Web pages which are entry points to the app

Thus, a legal request to a Web page should always have two characteristics:

It should come from a link embedded in the original page browsed by the user*

It should comply with the request definition in the Web page the user is currently browsing, defining:

Request method Request parameters Request parameters values

Application Flow Model

An accurate representation of

the designed interaction

between the user and the Web application

* Unless the page requested is the entry point to the Web application.

Page 51: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

51Confidential and proprietary information ©2004, MagniFire Websystems Inc.

51

The Application Flow Model

Stateful - Tracks which pages a user is coming from, and the specific permissions associated with that context.

A request which is perfectly legal within the context of one page might be inappropriate for a user on another page

Bidirectional - Looks at server responses to the client as well as client requests to the server.

Essential to verify that the user hasn’t attempted to tamper with the credentials sent to him in his response

Granular – Complete logical rendering of the transitions between every page, including every object, every parameter of each object, and every legal value within each object parameter.

Application Flow Model

The only way to provide total

security in front of Web applications (the only way to

replace embedded security code)

Page 52: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

52Confidential and proprietary information ©2004, MagniFire Websystems Inc.

52

Hybrid Policy Generator:Creating the Application Flow Model

• Automatic analysis of Web page content.

Purpose-built crawler Complete analysis of the Web page content, including active code such as

JavaScript, ‘Learns’ all details of the interaction between the user and the Web

application.

• Iterative policy adjustment.

Examines how users interact with application over time, based on real-life traffic.

Recommends adjustments to the current policy, based on the on-line analysis on the rejected traffic.

Page 53: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

53Confidential and proprietary information ©2004, MagniFire Websystems Inc.

53

Model User Flow

Static Parameters

Active-Code Analysis

Dynamic Parameters

Accurate Security Policy

Crawler based Learning

Yes Yes Yes No No

Request based Learning

No Limited No No No

Response based Learning

Partial Yes No Yes No

Hybrid Approach

Yes Yes Yes Yes Yes

Hybrid policy generation combines crawler-based application modeling with adjustments based on real-life request analysis– Request based learning is very useful to detect missing elements in policy

– Response based learning is limited in its analysis to avoid significant latency

Hybrid Policy Generator

Page 54: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

54Confidential and proprietary information ©2004, MagniFire Websystems Inc.

54

No False Positives, No False Negatives

Constraints that prevent vulnerabilities in certain cases can cause “False Positives” in other cases

Low granular policy means

Either false positives

OR low security (false negatives) due to relaxed policy The solution: Granular Security Policy that is accurately adjusted to the

protected Web-application Constraints are adjusted to Web-application Flow Model (no need to

relax security constraints) Policy enforcement takes into account user state No False Positives (constraints are not used when they are not

applicable)

Page 55: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

55Confidential and proprietary information ©2004, MagniFire Websystems Inc.

55

Low Latency

Security Policy enforcement is translated into hash searches

Hardened Linux Appliance Ease deployment Eliminates misconfiguration Optimized performance and throughput

Scalable Architecture - Shield units can be added to handle larger traffic volumes

Automatic recovery from unit failure based on the fact that units are identical and can switch roles

Central and secure management

Page 56: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

56Confidential and proprietary information ©2004, MagniFire Websystems Inc.

56

Solution Criteria Solution

Model application extremely accurately

Auto configuration / customization around app

No false positives or false negatives

Minimal ongoing policy management

No latency introduced (<1 ms)

• Crawling & full analysis of web pages• Adjustments based on real-life traffic

• ‘Learning Mode’ automatically recommends policy adjustments based on customer activity

• Any non-recognized activity is blocked

• Automated mapping & policy suggestions• Appliance: fits into web infrastructure

• Automatic detection of website changes and suggestions for newly-tailored policy

• Network appliance with modified OS for high throughput

1

2

3

4

5

Page 57: Closing the Door on Web Application Attacks FISSEA 2004 Confidential and proprietary information ©2004, MagniFire Websystems Inc.

57Confidential and proprietary information ©2004, MagniFire Websystems Inc.

57

Thank You!

Confidential and proprietary information ©2003, MagniFire Websystems Inc.


Recommended