Transcript Slide 1

1
F5
Web
Application
Security
Radovan Gibala
Senior Solutions Architect
[email protected]
+420 731 137 223
2009
2
Agenda
Challenge Websecurity – What are the problems?
Building blocks of Web Applications
Vulnerabilities and protection strategies
Websecurity with a Web Application Firewall (WAF)
Security Policy Setups
Deployment Methods
Attacking the Application
How to mitigate the risk in Web Applications with ASM
3
Market Trends
Webalization of Critical Applications
Mission-Critical Applications
Business-Critical Applications
ERP, CRM, SCM
- With access from Internet
Advantages of Voice, Data and
Video Integration
Profitability Increase
Data Centre Consolidation
Centralization of Applications and
Access from Internet
XML-based Web Services
Mobile Applications
B2B Business Processes over
Web Services / XML
Access and Usage of
Applications from Mobile
(private ?) Devices
4
Security’s Gaping Hole
“64% of the 10 million
security incidents tracked
targeted port 80.”
Information Week
DATA
5
Web Application Security
!
Noncompliant
Information
Perimeter Security
Is Strong
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
Hidden-Field Manipulation
Parameter Tampering
!
Infrastructural
Intelligence
Attacks Now Look To
Exploit Application
Vulnerabilities
PORT 80
PORT 443
But Is Open
to Web Traffic
!
Forced
Access to
Information
High
Information
Density
=
High Value
Attack
6
Why Are Web Applications
Vulnerable?
New code written to best-practice methodology, but not
tested properly
New type of attack not protected by current methodology
New code written in a hurry due to business pressures
Code written by third parties; badly documented, poorly
tested – third party not available
Flaws in third party infrastructure elements
Session-less web applications written with client-server
mentality
7
Solution Sentences for Application
Security
Make Bug-free applications
Network Firewalls + Marketing
Tools in the Web Servers
Infrastructure Solutions
8
Traditional Alternative: Rely Exclusively on the
Developer
Application Patching
Application Optimization
Application Logic
1+1=2
Application Security
Application Scalability
Application Integration
Application Availability
Application Performance
9
Who is responsible for application
security?
Web developers?
Network Security?
Engineering services?
DBA?
10
Challenges of traditional solutions
HTTP attacks are valid requests
HTTP is stateless, application is stateful
Web applications are unique
– there are no signatures for YOUR web application
Good protection has to inspect the response as well
Encrypted traffic facilitates attacks…
Organizations are living in the dark
– missing tools to expose/log/report HTTP attacks
11
Web Application Protection Strategy
Best
Practice
Design
Methods
Only protects against
known vulnerabilities
Automated
& Targeted
Testing
Web
Apps
Difficult to enforce;
especially with subcontracted code
Only periodic updated;
large exposure window
Done periodically; only
as good as the last test
Only checks for known
vulnerabilities
Does it find everything?
Web
Application
Firewall
Real-time 24 x 7 protection
Enforces Best Practice Methodology
Allows immediate protection against
new vulnerabilities
12
Traditional Scan and Fix and Audits
Scan and Fix
–
–
–
–
–
Scanners can’t find all vulnerabilities
Scanners can’t reverse engineer the code
Scanners can’t find business logic vulnerabilities
When something is detected, it requires an immediate code change
Not a pro-active solution
Security Code Audits
–
–
–
–
Extremely expensive ($25,000 for medium to small app)
Requires preparation and availability of the dev team.
Requires iterations of audit and fix
Each fix may add more bugs to current application or may add another vulnerability…
“we only protect from what we
know,
we never protect from what we
don’t know”
13
Web Applications Increasingly
Under Attack
High information density in the core
Flaws in applications & 3rd party software
Traditional security does not protect web apps.
Gaping hole in perimeter security for web traffic
SANS (November 2006) - Top Vulnerabilities in Cross-Platform Applications
C1. Backup Software
C2. Anti-virus Software
C3. PHP-based Applications (50% of all Apache installations worldwide use php!)
C4. Database Software
...
C6. DNS Software
...
C9. Mozilla and Firefox Browsers
...
14
Application Security Lacks Test
...or: „The Point of Truth“
Simple Version:
– Does your WAF discover that the Price of an Item on an Online
Shop was changed ?
15
Support of dynamic values
16
Application Security Lacks Test
...or: „The Point of Truth“
Simple Version:
– Does your WAF discover that the Price of an Item on an Online
Shop was changed ?
Technical Version:
– OWASP
(http://www.owasp.org/index.php/OWASP_Top_Ten_Project )
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Unvalidated Input
Broken Access Control
Broken Authentication and Session Management
Cross Site Scripting
Buffer Overflow
Injection Flaws
Emproper Error Handling
Insecure Storage
Application Denial of Service
Insecure Configuration Management
17
OWASP Top 10 / January 2007
A1 – Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes user supplied data and sends it to a web
browser without first validating or encoding that content. XSS allows attackers to execute
script in the victim’s browser which can hijack user sessions, deface web sites, etc.
A2 – Injection Flaws
Injection flaws, particularly SQL injection, are common in web applications. Injection occurs
when user-supplied data is sent to an interpreter as part of a command or query. The
attacker’s hostile data tricks the interpreter into executing unintended commands or
changing data.
A3 – Insecure Remote File Include
Code vulnerable to remote file inclusion allows attackers to include hostile code and data,
resulting in devastating attacks, such as total server compromise.
A4 – Insecure Direct Object Reference
A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, database record, or key, as a URL or form
parameter. Attackers can manipulate those references to access other objects without
authorization.
A5 – Cross Site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a
vulnerable web application, which then forces the victim’s browser to perform a hostile
action to the benefit of the attacker.
A6 – Information Leakage and Improper
Error Handling
Applications can unintentionally leak information about their configuration, internal workings,
or violate privacy through a variety of application problems. Attackers use this weakness
to violate privacy, or conduct further attacks.
A7 – Broken Authentication and Session
Management
Account credentials and session tokens are often not properly protected. Attackers
compromise passwords, keys, or authentication tokens to assume other users’ identities.
A8 – Insecure Cryptographic Storage
Web applications rarely use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other crimes, such as
credit card fraud.
A9 – Insecure Communications
Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive
communications.
A10 – Failure to Restrict URL Access
Frequently, the only protection for sensitive areas of an application is links or URLs are not
presented to unauthorized users. Attackers can use this weakness to access and perform
unauthorized operations.
18
n-tier Web Application Layer
19
Where does Application Security
Option 4
make Sense ?
Option 2
Option 3
Routing, ACL
Network Security
Router
Network Layer
Security
Packet Filtering
Pros:
• First point of entry
Cons:
• Zero application
fluency
• Wrong location
• No support for SSL
• Too little and
expensive
processing power
Application Security,
Optimization & Delivery
Option 1
Application Core
Functionality
BIG-IP LTM
“A combined application
delivery
Application
Firewall
Security Manager
controller
and Web application
firewall,
Web
App. Database
Application Layer
Server Server
rather than stand-alone
Security, Acceleration,
Session Layer
products,
provides a&single-vendor
Availability
Security
Stateful Inspection and performance
Pros:
relationship
• Application Fluent
Pros:
Pros:
improvements.
“ • Already used as SSL proxy
• Very specific to each
• Experienced in
for applications
application type and
Network security
Gartner
Research • High performance Layer 7
vendor
• Has some session &
app protocol awareness
Cons:
• No application fluency
• Out in DMZ / wrong
location
• Not optimized for L7
processing
• Cannot filter encrypted
content
• Less focus on SSL
processing
• Stronger support for L7
protocol validation
• Perfect location directly in front
of applications and servers
Cons:
• Less focus on Layer 2/3
security
Cons:
• Complex to manage
• Costly to implement
inside each application
• Error-prone
• In-efficient and re-active
20
Traditional Security Doesn’t Protect Web
Looking at the wrong
Applications
thing in the wrong place
Application
Firewall
Known Web Worms
Unknown Web Worms
Known Web Vulnerabilities
Unknown Web Vulnerabilities
Illegal Access to Web-server files
Forceful Browsing
File/Directory Enumerations
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
Hidden-Field Manipulation
Parameter Tampering













Network
Firewall
IPS
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
Present
X
X
X
X
X
X
21
Negative vs. Positive Security Model
Negative Security Model
– Lock Known Attacks
– Everything else is Allowed
– Patches implementation is quick and easy (Protection against Day
Zero Attacks)
Positive Security Model
–
–
–
–
(Automatic) Analysis of Web Application
Allow wanted Transactions
Everything else is Denied
Implicit Security against New, yet Unknown Attacks (Day Zero
Attacks)
22
Application Security with a WAF
!
Unauthorised
Access
!
Browser
And Stops
Bad
Requests
!
Noncompliant
Information
WAF Allows
Legitimate Requests
Unauthorised
Access
!
Infrastructural
Intelligence
Bi-directional:
–
–
Inbound:
Outbound:
protection from generalised & targeted attacks
content scrubbing & application cloaking
Application content & context aware
High performance, low latency, high availability, high
security
Policy-based full proxy with deep inspection & Java support
Positive security augmenting negative security
Central point of application security enforcement
23
Application Security with a WAF
Intelligent Decisions
Allow Only Good
Application Behaviour;
Positive Security
Browser
Definition of Good
and Bad Behaviour
24
Selective Application Flow
Enforcement
!
ALLOWED
Username
Password
?
!
From Acc.
$ Amount
To Acc.
Transfer
!
VIOLATION
VIOLATION
• Should this be a violation?
• The user may have
bookmarked the page!
• Unnecessarily enforcing flow
can lead to false positives.
This part of the site is a
financial transaction that
requires authentication; we
should enforce strict flow
and parameter validation
25
Multiple security layers
RFC enforcement
Various HTTP limits enforcement
Profiling of good traffic:
– Defined list of allowed file types, URI’s, parameters
Each parameter is evaluated separately for:
– Pre defined value
– Length
– Character set
– Attack patterns
• looking for Pattern Matching Signatures
26
Flexible Deployment Options
Tighter
Security
Posture
OBJECT FLOWS
PARAMETER VALUES
PARAMETER NAMES
Typical
‘standard’
starting point
OBJECT NAMES
OBJECT TYPES
27
Flexible Policy Granularity
Generic Policies - Policy per object type
–
–
–
–
Low number of policies
Quick to implement
Requires little change management
Can’t take application flow into account
Optimum policy is often a hybrid
Specific Policies – Policy per object
–
–
–
–
–
–
High number of policies
More time to implement
Requires change management policy
Can enforce application flow
Tightest possible security
Protects dynamic values
28
Flexible Deployment Options
Tighter
Security
Posture
POLICY
TIGHTENING
SUGGESTIONS
OBJECT FLOWS
PARAMETER VALUES
PARAMETER NAMES
Typical
‘standard’
starting point
OBJECT NAMES
OBJECT TYPES
Policy-Building Tools
• “Trusted IP” Learning
•
•
•
•
Live Traffic Learning
Crawler
Negative RegEx
Template
29
Deployment without False positives
Easy web application implementation
– Rapid deployment policy
– Pre-configured application policies
Learning mode
– Gradual deployment
– Transparent / semi-transparent / full blocking
30
F5 Application Security Manager (ASM)
and WhiteHat Sentinel partnership
Turnkey Vulnerability Detection and Remediation Solution
31
ASM + Sentinel Benefits
Discovery and remediation within minutes
Single click policy rules (XSS, SQLi)
Targeted laser focused policy rules
No false positives
Third party policy validation
Out-of-the-box integration for fast implementation
32
ASM + WhiteHat: what and how ?
Security Policy
Internet
website
33
Timely Threat Mitigation
PCI: WAF or scan?
WAF
Manual
Scan
Assurance
34
WAF deployment with the BIG-IP
LTM & ASM
Web Servers
BIG-IP with
Firewall
ASM
Internet
Management Access
(browser)
ASM = Application Security Manager
35
Layer 7 DoS and Brute Force
Unique Attack Detection and Protection
Unwanted clients are remediated and desired clients are serviced
Improved application availability
Focus on higher value productivity while automatic controls intervene
36
Summary
ASM introduce the DoS and Brute Force
prevention engines.
The DoS prevention is anomaly based
The brute force relies on the Dos engine to
mitigate attacks
Both features have reporting page to provide
information on false positives in transparent
mode and actual attack in blocking mode
37
DoS – configuration
The configuration screen is divide into 5 main
parts:
1.
2.
3.
4.
5.
Operation mode
Detection Criteria
Suspicious Criteria
Prevention Policy
Prevention Duration
38
DoS– Operation mode
The operation mode:
– Off: the anomaly detection engine is off and will not
collecting any data.
– Transparent: the anomaly detection engine is collecting
data, writing it to report log in case threshold are
reached but will not drop connections
– Blocking: the anomaly detection engine is collecting
data, write those events to report log and will drop
connection if thresholds are reached.
39
DoS– Detection Criteria
Detection Criteria is the first phase of the DoS
detection
The Detection Criteria measurements are being
done on latency and include:
1. Latency increased by
2. Latency reached
3. Minimum Latency Threshold for detection
40
DoS– Suspicious Criteria
Suspicious Criteria is the second phase of the
DoS detection
The Suspicious Criteria measurements are being
done on TPS and include:
1. TPS increased by
2. TPS (per IP address) reached
3. TPS (per URL) reached
41
DoS– Prevention Policy
When the anomaly engine decide on the “Suspicious
Criteria” that this is a DoS attack the engine will apply
one of the prevention policies:
– Client Side Integrity Defense: ASM will send a java script in
the response to the suspicious IP. If the client is a valid
browser it will return a valid request, if it is a script, it will
not return a request and therefore malicious and connection
can be dropped.
*note: it is recommended to check the impact of Java Script on
clients before applying this policy
42
DoS– Prevention Duration
• Source IP-Based Rate Limiting: dropping connection with
specific suspicious IP if “TPS (per IP address) reached”.
Dropping the connection will stop when transaction rate
“detection interval” is equal to its transaction rate “history
interval”.
• URL-Bases Rate Limiting: dropping connection for specific
URL if “TPS (per URL) reached” . Dropping the connection
will stop when transaction rate “detection interval” is equal to
its transaction rate “history interval”.
Prevention Duration: limiting the amount of time
the prevention policy is applied.
43
DoS - Reporting
Reporting page for DoS will show events that
reached the thresholds criteria's
Some of the records might not be an actual
connection drop when in transparent mode
44
DoS - Reporting (cont.)
Only records that contain dropped request are
actual prevention
– Legitimate Latency: Displays the latency history
interval
– Detected Latency: Displays the latency detection
interval
45
DoS - Reporting (cont.)
– Current Mitigation: Displays the prevention policy that was
applied on the attack
– Previous Mitigation: Displays the previous prevention policy that
didn’t manage to mitigate the attack
– IP Addresses: list of the source IP, including XFF header
46
Brute Force
Brute Force is a new feature in ASM park city
Part of the brute force feature relies on the DoS
engine
Brute force can be define per web application
The configuration page contain few sections:
–
–
–
–
Brute Force Protection Configuration
Session-based Brute Force Protection
Dynamic Brute Force Protection
Access Validation
47
Brute Force - configuration
The Brute Force Protection Configuration defines
authentication and credentials for the system to
determine there is a brute force attempt on them
– Login URL: the explicit object the login action is being
perform. Wild card is also supported.
– Authentication type: basic , digest NTLM and HTML form
is supported. For HTML form user should define the user
name and password parameters name that the client send
as login
48
Brute Force - configuration (cont.)
Session-based Brute Force Protection enables
the user to block clients that
perform 5 login attempts with
the same session.
User can set how long they will wait until they can
re login again for the same session
Enabling this feature is via the main blocking
page.
49
Brute Force - configuration (cont.)
Dynamic Brute Force Protection.
Operation mode: enable or disable
Off: the system doesn’t collect any data.
Transparent: in case thresholds are reached will not drop
requests and will write event to repot log.
Blocking: in case thresholds are reached will drop
request and will write events to report log.
50
Brute Force - configuration (cont.)
Detection Criteria:
Failed Login Attempts increased by: ratio of detection
interval and history interval for all IP’s
Failed Login Attempts Rate reached: failed logon rate
value for all IP’s.
Minimum Failed Login Attempts: this minimum must be
reached first to prevent false positives
The “Minimum Failed Login Attempts’ is AND with
(“Failed Login Attempts increased by” OR “Failed
Login Attempts Rate reached”)
51
Brute Force - configuration (cont.)
Suspicious Criteria (per IP address)
– Failed Login Attempts increased by: ratio of detection
interval and history interval for specific IP
– Failed Login Attempts Rate reached: failed logon rate
value for specific IP.
Prevention Policy: similar to the DoS protection.
Prevention Duration: limiting the amount of time the
prevention policy is applied.
52
Brute Force - configuration (cont.)
Access Validation is a set of validation criteria for
the response of the defined login URL.
User MUST define at least on of the below:
– A string that should appear in the response
• Example: “login successful”
– A string that should NOT appear in the response
• Example: “login failed”
– Expected HTTP response status code
• Example: 200 or 302
53
Brute Force - configuration (cont.)
– Expected validation header name and value (for
example, Location header)
• Header name value pair that the app might add to a response
after the login URL request
– Expected validation domain cookie name
• Domain cookie that the app might add to a response after a
login URL request
– Expected parameter name (added to URI links in the
response)
• Parameter name that login URL response should have in the
HTML body.
54
Brute Force - Report
Brute Force report provide information on dropped
request. Some of the useful information in the report:
– Average Historical Failed Logins: Displays the average
number of failed logon attempts for the URL.
– Detected Failed Logins: Displays the average number of
failed logon attempts for the URL.
– Dropped Connections: Displays the number of connections that
were dropped.
55
Brute Force - Report (cont.)
Brute Force report provide information on dropped
request. Some of the useful information in the report:
– Current Mitigation: Displays the prevention policy that was
applied on the attack
– Previous Mitigation: Displays the previous prevention policy that
didn’t manage to mitigate the attack
– IP Addresses: list of the source IP, including XFF header
56
XML Firewall
Well formatted validation
Schema/WSDL validation
Methods selection
Attack signatures for XML platforms
Backend Parser protection
XML islands application protection
Full request Logging
57
Secerno DataWall
Real-Time database activity monitoring
and blocking
Responds to each type of threat via either logging, monitoring,
alerting, blocking or substituting.
Enables rapid application development by reducing the need for
intensive security code development
Enforces a positive-security model: Only approved behavior is
allowed
Zero false positives
58
The Integration: F5 ASM+Secerno
DataWall
Monitor & Block traffic at the web and database layers
Application sessions tracked from client to database and back.
When anomalies are detected by ASM, they are logged to both the ASM & Secerno
DataWall logs.
–
–
ASM provides user and web context of the attack to Secerno enabling complete visibility of attack from source
IP address, through HTTP page and session to SQL transaction.
Secerno can analyse the full SQL transaction to see if the query is out of policy, rather than just a fragment.
Ensures that administrators are always able to get consistent, correlated application
monitoring data.
Web tier attacks are blocked by ASM
Undetected attacks that get to the database are blocked by Secerno DataWall
Users who do not access the database via the web application (DBA’s, consultants,
and operations staff) are still controlled by Secerno, whether the access is made over
then network, remote session, SSH or keyboard.
59
How The Integration Works
Web traffic is secured with BIG-IP ASM, and
database traffic with Secerno DataWall
When a user logs into an application, BIG-IP
passes their identity to Secerno DataWall.
If a SQL attack takes place, then all context of the
attack is sent to Secerno DataWall, and user
identity is associated with the attack in reports,
based on session and the ASM cookie.
60
BIG-IP Protocol Security Module
(PSM)
Integrated Platform to Secure Application Traffic
– Protects HTTP(s), FTP, and SMTP at BIG-IP System
Speeds
Application Security Accessible for the Network
Guy
– Application Protocol, Not Application Logic
– Fully Configured after Installation
Easy Introduction to Application Security
– First Step Toward a true Application Firewall
61
Simplified Security - PSM
Enforces Mandatory
Headers
White-List Server
Commands
Mitigates Directory
Harvesting
Length Checks
Mitigates BruteForce Attacks
Rate Limits
Data Guard
Length Checks
Anti-SPAM
Grey-Listing
Protocol Anomaly
Exploits
RFC Compliance
Augments MSM L4
w/ L7
62
Simplified Security - PSM
63
“Stepping-Stone” Security
App. Protocol
Transport
Network
Data Link
BIG-IP LTM
BIG-IP PSM
BIG-IP ASM
Application
64
Only Completely Integrated
Security Solution
“Stepping Stone” Security
– TMOS/LTM Provides L2-L4
– PSM Provides L4-L7 Protocol Security
– ASM Provides Application Security
Builds on ADN Functionality
– SSL Termination
– Caching/Compression
– IPv6 Gateway
65
ASM vs. Competition
Features
F5
Barracuda
Breach
Citrix
Imperva
Signature-based Security



X

Policy-based Security





Staging area for new signatures

X
X
X
X
Content (strings) normalization


X
X
X
Pre-configured policies

X
X


XML Schema validation

X
X

X
Integration with Vuln. Scanners

X
X
X
(1)
Data center security in one unit

X
X
X
X
Monitor URIs for server latency

X
X
X
X
Cookie poisoning



(2)

Encrypted cookie support

X
X
X
X
Rate limiting


X
X
X
Dynamic parameter protection


X


Layer 7 DoS attack protection

X
X
X
X
Brute Force attack protection


X
X
X
Acceleration and security

X
X
X(3)
X
66
Reporting
67
Reporting
68
Application visibility and reporting
Monitor URIs for server latency
Troubleshoot server code that causes latency
69
Centralized Advanced Reporting
with Splunk
Centralized reporting with
Splunk’s large-scale, highspeed indexing and search
solution
Packaged 15 different ASM
specific reports
Provide visibility into attack
trends and traffic trends
Identify unanticipated threats
before exposure occurs
http://www.f5.com/solutions/technologyalliances/security/splunk.html
70
Sample Reports with Splunk
–
–
–
–
Top violations
Top violations by protocol (HTTP, FTP, SMTP)
Top HTTP violations by web application
Top attackers
–
–
–
–
–
Top attackers by protocol (HTTP, FTP, SMTP)
Top web applications attacked, alerted or blocked
Top web applications alerted by IP address
Attacks by location
Top response codes by web application
– Top alerted or blocked web application requests by time period
– Web application requests by method
– Custom ASM forensics filtering & search
71
Link Collection
Overall
Technical
www.f5.com
www.f5.com
ask.f5.com
devcentral.f5.com
F5 University
www.f5university.com/
»
»
Login:
your email
Password: adv5tech
Partner Informaiotn
www.f5.com/partners
www.f5.com/training_services/certification/certFAQ.html
Gartner Report http://mediaproducts.gartner.com/reprints/f5networks/article1/article1.html
Important deployment information is available at
Data Center Virtualization
Application Traffic Management
Application Briefs
Solution Briefs
F5 Compression and Cache Test
F5 iControl Alliance Partners
F5 Technology Alliance Partners
http://www.f5.com/solutions/deployment/
http://www.f5.com/solutions/technology/pdfs/dc_virtualization_wp.pdf
http://www.f5.com/solutions/technology/pdfs/atm_wp.pdf
http://www.f5.com/solutions/applications/
http://www.f5.com/solutions/sb/
http://www.f5demo.com/compression/index.php
http://www.f5.com/solutions/partners/iControl/
http://www.f5.com/solutions/partners/tech/
Let us know if you need any clarification or you have any further questions.
72
F5 is the Global Leader in
Application Delivery Networking
Users
Data Centre
At Home
In the Office
On the Road
Application
Delivery
Network
SAP
Microsoft
Oracle
Business goal: Achieve these objectives in the
most operationally efficient manner
73