Transcript Web Application Security Presented by: Colin English Zerflow

Web Application Security
Presented by:
Colin English
Zerflow
Session Overview
• Web Application Security
– The Myth and The Facts
– Examples of Web Application Vulnerabilities
• Web Application Auditing & Testing
The Myth
“Our site is safe”:
– We have firewalls in place
– We encrypt our data
– We have a privacy policy
Recent News
Software bug bites U.S.
Military
— BBC, Mar 18,2003
Pressures on the Application Lifecycle
•
Time-to-Market
•
•
Complexity is Growing
•
•
•
Financial Services Application
Bringing new applications to market quickly
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)
Cyber crime on the Rise
• On average, there are 5 to 15 defects in
every 1,000 lines of code
 US Dept. of Defense and the Software
Engineering Institute
• It takes 75 minutes on average to track
down one defect. Fixing one of these
defects takes 2 to 9 hours each
 5 Year Pentagon Study
• A company with 1,000 servers can
spend $300,000 to test & deploy a patch;
most companies deploy several patches
a week
 Gartner Group
• MS $100 million TrustworthyComputing initiative: improve SW
security & reduce number of software
updates and security bulletins issued
Application Security Defects
•
Frequent
•
•
Pervasive
•
•
•
167 Audits conducted – 98% vulnerable: all had
firewalls and encryption solutions in place…
3 out of 4 business websites are
vulnerable to attack (Gartner)
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
Cost Increases Later in the Lifecycle
Security is Addressed
Cost to Fix dramatically increases
the longer you wait to test
Web Application Vulnerabilities
Data
Database
Backend Application
Frontend Application
User Interface Code
Web Server
Valid Input Invalid Input
HTML/HTTP HTML/HTTP
Invalid Data can
exploit weakness
in the application
acting as escape
holes resulting in
access to
unauthorized
accounts, O/S
network, sensitive
data and may
result in an
application denial
of service
Browser
Without any protection,
holes and backdoors exist at every layer waiting to be exploited
Types of Application Hacks
Through a browser, a hacker can use the smallest bug
or backdoor to change, or pervert,
the intent of the application
Application
Attack Types
Negative Outcome Examples
Form field: collect data
Buffer overflow
Crash servers/close business
Customer account
Cookie poisoning
Identity theft/illegal transactions
Online shopping
Hidden fields
eShoplifting
Sloppy code
Backdoors/Debug options
Download proprietary database
Text Field: collect data
Cross Site scripting
eHijacking - Get account info
Database
Backend Apps
Parameter Tampering/SQL injection
Stealth Commanding
Fraud
Site defacement
Web Server
Published Vulnerabilities
Crash site
Front end Apps
3rd Party Misconfiquration
Admin access
Web Server
Forceful Browsing
Access sensitive data
10 Types of Attacks:
Development Lifecycle
Development
Operations
APP. BUFFER OVERFLOW
COOKIE POISONING
CROSS SITE SCRIPTING
HIDDEN MANIPULATION
STEALTH COMMANDING
3RD PARTY MISCONFIG.
KNOWN VULNERABILITIES
PARAMETER TAMPERING
BACKDOORS & DEBUG OPT.
FORCEFUL BROWSING
3rd party SW
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
Hidden Field Manipulation - Example
Hidden Field Manipulation - Example
Hidden Field Manipulation - Example
Hidden Field Manipulation - Example
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).
Backdoor & Debug options - Example
Backdoor & Debug options - Example
Backdoor & Debug options - Example
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.
Cross Site Scripting - Example
Press this link to get to your bank
Underlying link: http://www.mybank.com?a=<evil javascript>
The JavaScript program collects and sends user names and passwords
1
3
Username
Password
2
Enter your login information
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
Parameter Tampering - Example
Parameter Tampering - Example
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
Web Application Hacking - Results
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
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.
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
Demo
Thank You for Your Attention