1

F5
Web
Application
Security

Radovan Gibala
Senior Solutions Architect
[Link]@[Link]
+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 Advantages of Voice, Data and

Video Integration
- With access from Internet
Profitability Increase

Data Centre Consolidation

Centralization of Applications and

Access from Internet

XML-based Web Services Mobile Applications

Access and Usage of

B2B Business Processes over Applications from Mobile
Web Services / XML (private ?) Devices
 4

Security’s Gaping Hole

“64% of the 10 million

security incidents tracked
targeted port 80.” DATA
Information Week
 5

Web Application Security

Attacks Now Look To

!Non-
Perimeter Security
Is Strong
Exploit Application
Vulnerabilities
compliant Buffer Overflow
Cross-Site Scripting
Information
SQL/OS Injection PORT 80

Cookie Poisoning
Hidden-Field Manipulation
PORT 443 !
Forced
Parameter Tampering Access to
But Is Open
!
Infrastructural
to Web Traffic
Information

High
Intelligence 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 Logic Application Optimization

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
Automated
Practice
& Targeted
Design
Testing
Methods
Only protects against Web Done periodically; only
known vulnerabilities Apps as good as the last test
Difficult to enforce; Only checks for known
especially with sub- vulnerabilities
contracted code Does it find everything?
Only periodic updated; Web
large exposure window 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
([Link] )
1. Unvalidated Input
2. Broken Access Control
3. Broken Authentication and Session Management
4. Cross Site Scripting
5. Buffer Overflow
6. Injection Flaws
7. Emproper Error Handling
8. Insecure Storage
9. Application Denial of Service
10. 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 Applications can unintentionally leak information about their configuration, internal workings,
Error Handling 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 Account credentials and session tokens are often not properly protected. Attackers
Management 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

make Sense ? Option 4
Option 2 Option 3 Application Security, Option 1
Routing, ACL Network Security Optimization & Delivery Application Core
Functionality

“A combined application delivery

BIG-IP LTM
Application
Router
controller
Firewall
and Web application
Security Manager firewall,
Web App. Database
rather than stand-alone Application Layer Server Server
Security, Acceleration,
Network Layer Session Layer
Security
products,
Security
provides a&single-vendor
Availability
Packet Filtering relationship
Stateful Inspection and performance
Pros:
• Application Fluent
Pros:
• First point of entry
improvements.
Pros:
• Experienced in
“ • Already used as SSL proxy Pros:
• Very specific to each
for applications
Cons:
• Zero application
Gartner Research • High performance Layer 7
Network security
• Has some session &
application type and
vendor
processing
fluency app protocol awareness • Stronger support for L7
• Wrong location Cons: protocol validation Cons:
• No support for SSL • No application fluency • Perfect location directly in front • Complex to manage
• Too little and • Out in DMZ / wrong of applications and servers • Costly to implement
expensive location Cons: inside each application
processing power • Not optimized for L7 • Less focus on Layer 2/3 • Error-prone
processing security • In-efficient and re-active
• Cannot filter encrypted
content
• Less focus on SSL
 20

Traditional Security Doesn’t Protect Web

Applications Looking at the wrong
thing in the wrong place

Application Network IPS

Firewall Firewall
Known Web Worms  Present Present
Unknown Web Worms  Present Present
Known Web Vulnerabilities  Present Present
Unknown Web Vulnerabilities  Present Present
Illegal Access to Web-server files  Present Present
Forceful Browsing  Present Present
File/Directory Enumerations  Present Present
Buffer Overflow  Present Present
Cross-Site Scripting  Present Present
SQL/OS Injection  Present Present
Cookie Poisoning  X X
Hidden-Field Manipulation  X X
Parameter Tampering  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
And Stops
Bad !Non-
Access Requests compliant
Information

WAF Allows
Browser
! Legitimate Requests
Unauthorised
!
Infrastructural
Access Intelligence

Bi-directional:
– Inbound: protection from generalised & targeted attacks
– Outbound: 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

Definition of Good
Browser and Bad Behaviour
 24

Selective Application Flow

Enforcement

!
ALLOWED

Username
From Acc. $ Amount
Password To Acc. Transfer

? !
!
VIOLATION
VIOLATION

This part of the site is a

financial transaction that
• Should this be a violation?
requires authentication; we
• The user may have
should enforce strict flow
bookmarked the page!
and parameter validation
• Unnecessarily enforcing flow
can lead to false positives.
 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 OBJECT FLOWS

Security
Posture
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 OBJECT FLOWS POLICY

Security TIGHTENING
Posture SUGGESTIONS
PARAMETER VALUES
Policy-Building Tools
• “Trusted IP” Learning
PARAMETER NAMES
• Live Traffic Learning
Typical
‘standard’ • Crawler
starting point OBJECT NAMES • Negative RegEx
• Template

OBJECT TYPES
 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

PCI: WAF or scan?

Timely Threat Mitigation

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. Operation mode
2. Detection Criteria
3. Suspicious Criteria
4. Prevention Policy
5. 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 White-List Server Mitigates Directory

Headers Commands Harvesting

Mitigates Brute-
Length Checks Force Attacks Rate Limits

Anti-SPAM
Data Guard Length Checks Grey-Listing

Protocol Anomaly Augments MSM L4

RFC Compliance
Exploits w/ L7
 62

Simplified Security - PSM

 63

“Stepping-Stone” Security

Application

BIG-IP ASM
App. Protocol

BIG-IP PSM
BIG-IP LTM
Transport

Network

Data Link
 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, high-
speed indexing and search
solution
Packaged 15 different ASM
specific reports
Provide visibility into attack
trends and traffic trends
Identify unanticipated threats
before exposure occurs
[Link]
alliances/security/[Link]
 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 [Link]

Overall [Link]
Technical [Link]
[Link]

F5 University [Link]/
» Login: your email
» Password: adv5tech
Partner Informaiotn
[Link]/partners
[Link]/training_services/certification/[Link]
Gartner Report [Link]

Important deployment information is available at [Link]

Data Center Virtualization [Link]
Application Traffic Management [Link]
Application Briefs [Link]
Solution Briefs [Link]
F5 Compression and Cache Test [Link]
F5 iControl Alliance Partners [Link]
F5 Technology Alliance Partners [Link]

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

Application
Delivery
At Home Network SAP
In the Office Microsoft
On the Road Oracle

Business goal: Achieve these objectives in the

most operationally efficient manner
73