1. Closing the Door on Web Application Attacks FISSEA 2004
Confidential 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?

3. Ensuring 100% protection
In Israel the government has an effective way to protect sensitive data from internet hackers…

4. However, Government Is Moving Online
Unique Audience (2002) (Source: Nielson NetRatings)

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 used port 80, a common port devoted to Web traffic.” (ISS Internet Risk Impact Summary Report for 2002)

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

7. Web Applications Are The Weakest Point
Host IDS & Secure OS
Net IDS
System
“64% of the 10 million security incidents tracked targeted port 80.” (Information Week magazine)
Network
Application
DATA
Desktop
Access
Antivirus
Firewall

8. Major Categories of Web Application Vulnerabilities
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
Almost all Web applications are exposed
“From 45 found nearly 500 ‘significant’ security defects, with an average of at least 10 per assessment” Study on Web application security)

9. Hidden Field Manipulation
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

10. Hidden Field Manipulation - Example

11. Hidden Field Manipulation - Example

12. Hidden Field Manipulation - Example

13. Hidden Field Manipulation - Example

14. Hidden Field Manipulation - Example

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

16. Cookie Poisoning - Example

17. Cookie Poisoning - Example

18. Cookie Poisoning - Example

19. Cookie Poisoning - Example

20. Cookie Poisoning - Example

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

22. Buffer Overflow - Example

23. Buffer Overflow - Example

24. Buffer Overflow - Example

25. Cross Site Scripting
Inserting scripting languages into text fields to be displayed to other users
Example: Add an Item Section of Web Site
Site defacement
Changing field parameters

26. Cross Site Scripting - Example

27. Cross Site Scripting - Example

28. Cross Site Scripting - Example

29. Cross Site Scripting - Example

30. Cross Site Scripting - Example

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.

32. Known Vulnerabilities & Misconfiguration

33. Known Vulnerabilities & Misconfiguration

34. Parameter Tampering
Modify the parameters being passed as part of the URL
Example: Online Auction Site
User Account Access
Forbidden SQL Query via wrong parameters

35. Parameter Tampering - Example

36. Parameter Tampering - Example

37. Forceful Browsing
Jumping directly to pages that can normally only be accessed through authentication mechanisms
Example: Auction Web Site
Breaching users’ privacy
Direct file access

38. Forceful Browsing - Example

39. Forceful Browsing - Example

40. Forceful Browsing - Example

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

42. Existing Security Solutions are Inadequate

43. Traditional Security Solutions Don’t Protect Web Applications
Current solutions are not enough (CSI & FBI 2002):
89% of respondents have a firewall
60% of respondents used at least one Intrusion Detection System
However: 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)

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

45. Traditional Security Solutions Don’t Protect Web Applications
HIPS
NIPS FW
TrafficShield
Yes
Limited
Known Web Worms
Partial No
Unknown Web Worms
Known Web Vulnerabilities
Unknown Web Vulnerabilities
Illegal Access to Web-server files
Forceful Browsing
File/Directory Enumerations
Brute Force attacks
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
Hidden-Field Manipulation
Parameter Tampering
Flood attacks (GET, 404)
SSL Flooding

46. Current Application-Layer Approaches
Scan-and-Fix
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

47. The Solution: Granular & Tailored Application-Specific Security

48. Solution Criteria Web Application Firewall Using Positive Security Logic1
Model application extremely accurately
Auto configuration / customization around app
No false positives or false negatives
Minimal ongoing policy management
No latency introduced (<1 ms) 2 3 4 5

49. Model the Application Flow
Web Application
Application Flow Model
Application Flow
CHANGE
USER ID
Actions not known to be legal can now be blocked.
- wrong page order
- invalid parameter
- invalid value
- etc.

50. The Application Flow Model
An accurate representation of the designed interaction between the user and the Web application
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
* Unless the page requested is the entry point to the Web application.

51. The Application Flow Model
The only way to provide total security in front of Web applications (the only way to replace embedded security code)
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.

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.

53. Hybrid Policy Generator
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
Model User Flow
Static Parameters
Active- Code Analysis
Dynamic Parameters
Accurate Security Policy
Crawler based Learning
Yes No
Request based Learning
Limited
Response based Learning
Partial
Hybrid Approach

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)

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

56. Solution Criteria Solution
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
Model application extremely accurately
Auto configuration / customization around app
No false positives or false negatives
Minimal ongoing policy management
No latency introduced (<1 ms)

57. Thank You!
Confidential and proprietary information ©2003, MagniFire Websystems Inc.