Secure the Application Layer
Sebastien Deleersnyder
OWASP Foundation
March 2015
1

Overview
2

Sebastien Deleersnyder?
– 5 years developer experience
– 15+ years information security
experience
– Consultant & managing partner
Toreon
– Belgian OWASP chapter founder
– OWASP volunteer
– www.owasp.org
– Co-organizer www.BruCON.org

OWASP World
OWASP is a worldwide free and
open community focused on
improving the security of
application software.
Our mission is to make
application security visible so
that people and organizations
can make informed decisions
about application security risks.
Everyone is free to participate in
OWASP and all of our materials
are available under a free and
open software license.
The OWASP Foundation is a
501c3 not-for-profit charitable
organization that ensures the
ongoing availability and support
for our work.

|5
Agenda
• Why application security matters
• OWASP top 10 v2013
• Mobile, Cloud, IoT Security
• Software Assurance Maturity Model
• Application security resources

Why application security
matters?

Web Application Security Problem
• 75% of attacks are aimed straight at the application layer (GARTNER)
• 92% are application vulnerabilities instead of network vulnerabilities (NIST)
• Recent examples (2011-2012):
Citibank breached using
simple URL manipulation.
200,000 customer accounts
compromised.
Rabobank knocked offline
by DDOS attack
Caused outage of Dutch
central payment system
Elantis held to ransom over hacked
customer data Target Shares Tumble As Retailer
Reveals Cost Of Data Breach
(148M $) – 70 M customer data
leaked

Hacktivism

|9
e-Crime Inc
• Online Extortion
• Phishing
• Denial of Service
• Credit Card Stealing
• Bot Infection
• Bot-net pharming
• Sell phishing tools
• ...
See the Web Hacking Incidents Database on
http://www.webappsec.org/projects/whid/

|10
State actors
• Track users
• Drive-by downloads
• Social engineering
• Tapping Telcos
• Hacking Telcos (BICS)
• Crypto backdoors
• Industrial espionage
"Electronic devices are increasingly embedded in everything from
vehicles to guided missiles, and are often integrated into systems
which are difficult and costly to update or upgrade as new threats
or vulnerabilities are identified with increasing speed and widely
ranging tempo," he explained. "These factors represent
malefactors impacting our warfighting systems.“ …
Army.mil/News - Lt. Gen. Edward C. Cardon

|11
Myth
Myth: we are secure because we have a firewall
75% of Internet Vulnerabilities are at Web
Application Layer *
*Gartner Group (2002 report)

|12
Source: Jeremiah Grossman, BlackHat 2001

last century technology

|14
• Myth 2 - we are secure because we use SSL
– only secures data in transit
– does not solve vulnerabilities on:
• Web server
• Browser
Myth

|15
Firewall
Hardened OS
Web Server
App Server
Firewall
Databases
LegacySystems
WebServices
Directories
HumanResrcs
Billing
Custom Developed
Application Code
APPLICATION
ATTACK
You can’t use network layer protection (firewall, SSL, IDS,
hardening) to stop or detect application layer attacks
NetworkLayerApplicationLayer
Your security “perimeter” has huge
holes at the application layer

|16
Trends
• Business demands more bells and whistles
• Internal applications get ‘web-enabled’ and
are exposed to Intranet or Internet
• Increasing complexity of software
• Rush software out without adequate testing
• Poor security training and awareness

OWASP Top 10

OWASP Top 10
• OWASP Top 10 Web
Application Security Risks
• 2013 Release
• A great start, but not a
standard
|1
8

OWASP Top Ten (2013 Edition)
19

OWASP Top 10 Risk Rating Methodology
Threat
Agent
Attack
Vector
Weakness Prevalence
Weakness
Detectability
Technical Impact Business Impact
?
Easy Widespread Easy Severe
?Average Common Average Moderate
Difficult Uncommon Difficult Minor
2 1 1 2
1.3 * 2
2.6 weighted risk rating
XSS Example
1
2
3

A1 – Injection
•Tricking an application into including unintended commands in the data sent to an
interpreter
Injection means…
•Take strings and interpret them as commands
•SQL, OS Shell, LDAP, XPath, Hibernate, etc…
Interpreters…
•Many applications still susceptible (really don’t know why)
•Even though it’s usually very simple to avoid
SQL injection is still quite common
•Usually severe. Entire database can usually be read or modified
•May also allow full database schema, or account access, or even OS level access
Typical Impact

example : SQL-injection attack
Select user_information
from user_table
where username=’input username’ and
password=’input password’
Web Server Application Server
User Database
User
https
Select user_information
from user_table
where username=’’ or 1=1 -- ‘ and
password=’abc’
DEMO

Go shopping …
• … A federal grand jury on Monday
indicted Albert Gonzalez and two
unidentified Russian accomplices on
charges related to data intrusions at
Heartland, Hannaford Bros., 7-Eleven and
three other retailers. Gonzalez is alleged
to have masterminded an international
operation that stole a staggering 130
million credit and debit card numbers
from those companies.
• … Court documents filed in connection
with Monday's indictment spelled out
how Gonzalez and his accomplices used
SQL injection attacks to break into
Heartland's systems and those of the
other companies.
http://www.computerworld.com/article/2527185/security0/sql-injection-attacks-led-to-heartland--hannaford-breaches.html

A2 – Broken Authentication and Session Management
•Means credentials have to go with every request
•Should use SSL for everything requiring authentication
HTTP is a “stateless” protocol
•SESSION ID used to track state since HTTP doesn’t
•and it is just as good as credentials to an attacker
•SESSION ID is typically exposed on the network, in browser, in logs, …
Session management flaws
•Change my password, remember my password, forgot my password, secret question,
logout, email address, etc…
Beware the side-doors
•User accounts compromised or user sessions hijacked
Typical Impact

Session Fixation Attack
DEMO

A3 – Cross-Site Scripting (XSS)
•Raw data from attacker is sent to an innocent user’s browser
Occurs any time…
•Stored in database
•Reflected from web input (form field, hidden field, URL, etc…)
•Sent directly into rich JavaScript client
Raw data…
•Try this in your browser – javascript:alert(document.cookie)
Virtually every web application has this problem
•Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or malware
site
•Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior on
vulnerable site and force user to other sites
Typical Impact

XSS Definition
• XSS = Cross-site Scripting
• Web application vulnerability
• Injection of code into web pages viewed by others

Cross-Site Scripting (XSS)
Example:
User input is retrieved from the “name” parameter
http://myserver.com/XSS.jsp?name=Pieter
Result (HTML returned to the browser):
...
<h1>Hello Pieter</h1>
...
Input is embedded inside the HTML response:
..
Out.print(“<h1>”+request.getParameter(“name”)+”</h1>”);
..

Cross-Site Scripting (XSS)
Abused by the attacker:
Attacker inserts javascript code at the “username” parameter
http://myserver.com/XSS.jsp?name=<script>code</script>
Result (HTML returned to the browser):
...
<h1>Hello <script>code</script></h1>
...
Input is embedded inside the HTML response:
..
Out.print(“<h1>”+request.getParameter(“name”)+”</h1>”);
..
DEMO

XSSED.ORG
30

Browser Exploitation Framework

A4 – Insecure Direct Object References
• This is part of enforcing proper “Authorization”, along with
A7 – Failure to Restrict URL Access
How do you protect access to your data?
• Only listing the ‘authorized’ objects for the current user, or
• Hiding the object references in hidden fields
• … and then not enforcing these restrictions on the server side
• This is called presentation layer access control, and doesn’t work
• Attacker simply tampers with parameter value
A common mistake …
• Users are able to access unauthorized files or data
Typical Impact

Insecure Direct Object References Illustrated
• Attacker notices his
acct parameter is
6065
?acct=6065
• He modifies it to a
nearby number
?acct=6066
• Attacker views the
victim’s account
information
https://www.onlinebank.com/user?acct=6065

A5 – Security Misconfiguration
•All through the network and platform
•Don’t forget the development environment
Web applications rely on a secure foundation
•Think of all the places your source code goes
•Security should not require secret source code
Is your source code a secret?
•All credentials should change in production
Configuration Management must extend to all parts of the application
•Install backdoor through missing network or server patch
•XSS flaw exploits due to missing application framework patches
•Unauthorized access to default accounts, application functionality or data, or unused but
accessible functionality due to poor server configuration
Typical Impact

Hardened OS
Web Server
App Server
Framework
Security Misconfiguration Illustrated
App Configuration
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
Test Servers
QA Servers
Source Control
Development
Database
Insider

Serving up malware
A quick Google Safe Browsing search of TechCrunch Europe's site shows suspicious activity twice over the last 90 days.
"Of the 128 pages we tested on the site over the past 90 days,
58 page(s) resulted in malicious software being downloaded and installed without user consent.”
(sep 2010)
Reason: unpatched WordPress

A6 – Sensitive Data Exposure
•Failure to identify all sensitive data
•Failure to identify all the places that this sensitive data gets stored
•Databases, files, directories, log files, backups, etc.
•Failure to identify all the places that this sensitive data is sent
•On the web, to backend databases, to business partners, internal communications
•Failure to properly protect this data in every location
Storing and transmitting sensitive data insecurely
•Attackers access or modify confidential or private information
•e.g, credit cards, health care records, financial data (yours or your customers)
•Attackers extract secrets to use in additional attacks
•Company embarrassment, customer dissatisfaction, and loss of trust
•Expense of cleaning up the incident, such as forensics, sending apology letters,
reissuing thousands of credit cards, providing identity theft insurance
•Business gets sued and/or fined
Typical Impact

Insecure Cryptographic Storage Illustrated
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
1
Victim enters credit card
number in form
2Error handler logs CC details
because merchant gateway
is unavailable
4 Malicious insider
steals 4 million credit
card numbers
Log files
3Logs are accessible to all
members of IT staff for
debugging purposes

Leaking customer data?
• customer data, 77 Million compromised.
(potentially CCs as well)
39

Ook in België!
http://nl.wikipedia.org/wiki/Datalek

A7 – Missing Function Level Access Control
• This is part of enforcing proper “authorization”, along with
A4 – Insecure Direct Object References
How do you protect access to URLs (pages)?
• Displaying only authorized links and menu choices
• This is called presentation layer access control, and doesn’t work
• Attacker simply forges direct access to ‘unauthorized’ pages
A common mistake …
• Attackers invoke functions and services they’re not authorized for
• Access other user’s accounts and data
• Perform privileged actions
Typical Impact

Failure to Restrict URL Access Illustrated
• Attacker notices the
URL indicates his role
/user/getAccounts
• He modifies it to
another directory
(role)
/admin/getAccounts, or
/manager/getAccounts
• Attacker views more
accounts than just
their own
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts

A8 – Cross Site Request Forgery (CSRF)
• An attack where the victim’s browser is tricked into issuing a command to a
vulnerable web application
• Vulnerability is caused by browsers automatically including user authentication data
(session ID, IP address, Windows domain credentials, …) with each request
Cross Site Request Forgery
• What if a hacker could steer your mouse and get you to click on links in your online
banking application?
• What could they make you do?
Imagine…
• Initiate transactions (transfer funds, logout user, close account)
• Access sensitive data
• Change account details
Typical Impact

CSRF Illustrated
page 44

Browser
example.bank.com bad.site.com
<img src=“…”>
<img src=
"https://example.bank.com/transfer?
account=Pieter&amount=1000000&for=Attacker">
1
4 3
2
$$$
5
4
CSRF Illustrated
DEMO

SAMY XSS Worm

A9 – Using Known Vulnerable Components
47
• Some vulnerable components (e.g., framework libraries) can be identified
and exploited with automated tools
• This expands the threat agent pool beyond targeted attackers to include
chaotic actors
Vulnerable Components Are Common
• Virtually every application has these issues because most development teams don’t
focus on ensuring their components/libraries are up to date
• In many cases, the developers don’t even know all the components they are using,
never mind their versions. Component dependencies make things even worse
Widespread
• Full range of weaknesses is possible, including injection, broken access control, XSS ...
• The impact could range from minimal to complete host takeover and data
compromise
Typical Impact

1
10
100
1,000
10,000
100,000
1,000,000
10,000,000
100,000,000
Everyone Uses Vulnerable Libraries29 MILLION
vulnerable
downloads in
2011
Libraries 31
Library
Versions
1,261
Organizations 61,807
Downloads 113,939,358
Vulnerable
Download
26%
Safe
Download
74%
https://www.aspectsecurity.com/news/press/the-unfortunate-reality-of-insecure-libraries

Automation Example for Java – Use
Maven ‘Versions’ Plugin
Output from the Maven Versions Plugin – Automated Analysis of Libraries’ Status
against Central repository
Most out of Date! Details Developer Needs
This can automatically be run EVERY TIME software is built!! 49

A10 – Unvalidated Redirects and Forwards
• And frequently include user supplied parameters in the destination URL
• If they aren’t validated, attacker can send victim to a site of their choice
Web application redirects are very common
• They internally send the request to a new page in the same application
• Sometimes parameters define the target page
• If not validated, attacker may be able to use unvalidated forward to bypass
authentication or authorization checks
Forwards (aka Transfer in .NET) are common too
• Redirect victim to phishing or malware site
• Attacker’s request is forwarded past security checks, allowing unauthorized
function or data access
Typical Impact

Unvalidated Redirect Illustrated
3
2
Attacker sends attack to victim via email or webpage
From: Internal Revenue Service
Subject: Your Unclaimed Tax Refund
Our records show you have an unclaimed
federal tax refund. Please click here to initiate
your claim.
1 Application redirects
victim to attacker’s site
Request sent to vulnerable site,
including attacker’s destination site
as parameter. Redirect sends victim
to attacker site
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
4 Evil site installs malware on
victim, or phish’s for private
information
Victim clicks link containing unvalidated parameter
Evil Site
http://www.irs.gov/taxrefund/claim.jsp?year=2006&
… &dest=www.evilsite.com

Jobs by CNN?
• http://ads.cnn.com/event.ng/Type=click&Redirect=http:/bit.ly/cP–XW
52

Mobile, Cloud, IoT Security

Mobile Threat Model
• Platforms vary with mileage
• Very different from traditional web app model due to
other use cases and usage patterns
• Must consider more than the ‘apps’
• Remote web services
• Platform integration (iCloud, C2DM)
• Device (in)security considerations
5

5
Mobile Attack Surface

Mobile Threat Model
5

5
Mobile top 10 risks
Only 1% of consumers feel safe using mobile payments
* http://www.net-security.org/secworld.php?id=17767

work in progress
• OWASP Mobile Security Project
• Roadmap:
– Threat Model
– Top 10 Mobile Risks
– Top 10 Mobile Controls
– Platform-Specific Guidance
– Training (goat droid)
– Cheat Sheets
– Security Testing Methodologies

Critical threats to cloud security:
1. Data Breaches
2. Data Loss
3. Account Hijacking
4. Insecure APIs
5. Denial of Service
6. Malicious Insiders
7. Abuse of Cloud Services
8. Insufficient Due Diligence
9. Shared Technology Issues
* The Notorious Nine 2013 - CSA

Cloud hacks / incidents

Considering cloud storage / services?
Mandatory reading:
• Security Guidance 3.0
• Cloud Control Matrix (CCM) 3.0
by Cloud Security Alliance (CSA) cloudsecurityalliance.org

Internet of Things Top 10 - Complete IoT Review
• Review all aspects of Internet of Things
• Top Ten Categories
• Covers the entire device
• Without comprehensive coverage like
this it would be like getting your physical
but only checking one arm
• We must cover all surface area to get a
good assessment of overall security

Software Assurance Maturity
Model (SAMM)
|63

“Build in” software assurance
64
Design Build Test Production
vulnerability
scanning -
WAF
security testing
dynamic test
tools
coding guidelines
code reviews
static test tools
security
requirements /
threat modeling
reactiveproactive
Secure Development Lifecycle
(SAMM)

We need a Maturity Model
An organization’s
behavior
changes slowly
over time
Changes must be
iterative while
working toward
long-term goals
There is no
single recipe that
works for all
organizations
A solution must
enable risk-based
choices tailored to
the organization
Guidance related
to security
activities must
be prescriptive
A solution must
provide enough
details for non-
security-people
Overall, must be
simple, well-
defined, and
measurable
OWASP Software
Assurance
Maturity Model
(SAMM)

SAMM Security Practices
• From each of the Business Functions, 3 Security Practices are defined
• The Security Practices cover all areas relevant to software security
assurance
• Each one is a ‘silo’ for improvement
66

Under each Security Practice
• Three successive Objectives under each Practice define how it can be
improved over time
• This establishes a notion of a Level at which an organization fulfills a given
Practice
• The three Levels for a Practice generally correspond to:
• (0: Implicit starting point with the Practice unfulfilled)
• 1: Initial understanding and ad hoc provision of the Practice
• 2: Increase efficiency and/or effectiveness of the Practice
• 3: Comprehensive mastery of the Practice at scale

Per Level, SAMM defines...
• Objective
• Activities
• Results
• Success Metrics
• Costs
• Personnel
• Related Levels

Three successive Objectives under each Practice
69

Education & Guidance
Resources:
• OWASP Top 10
• OWASP Education
• WebGoat
Give a man a fish and you feed him for a day;
Teach a man to fish and you feed him for a lifetime.
Chinese proverb
70

Secure Coding Practices Quick Reference Guide
• Technology agnostic coding practices
• What to do, not how to do it
• Compact, but comprehensive checklist format
• Focuses on secure coding requirements, rather
then on vulnerabilities and exploits
• Includes a cross referenced glossary to get
developers and security folks talking the same
language
https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
71

Code Review
Resources:
• OWASP Code Review Guide
SDL Integration:
• Multiple reviews defined as deliverables in your SDLC
• Structured, repeatable process with management support
• Reviews are exit criteria for the development and test phases
72

OWASP Cheat Sheets
https://www.owasp.org/index.php/Cheat_Sheets
73

Code review tooling
Code review tools:
• OWASP LAPSE (Security scanner for Java EE
Applications)
• MS FxCop / CAT.NET (Code Analysis Tool for .NET)
• Agnitio (open source Manual source code review
support tool)
74

Security Testing
Resources:
• OWASP ASVS
• OWASP Testing Guide
SDL Integration:
• Integrate dynamic security testing as part of you
test cycles
• Derive test cases from the security requirements
that apply
• Check business logic soundness as well as
common vulnerabilities
• Review results with stakeholders prior to release
75

Security Testing
• Zed Attack Proxy (ZAP)
• Automated & manual scanner to find
vulnerabilities
Features:
• Intercepting proxy
• Automated scanner
• Passive scanner
• Brute force scanner
• Spider
• Fuzzer
• Port scanner
• Dynamic SSL Certificates
• API
• Beanshell integration
76

Web Application Firewalls
Network
Firewall
Web
Application
Firewall
Web
Server
Web client
(browser)
Malicious web traffic
Legitimate web traffic
Port 80
– ModSecurity: Worlds No 1 open source Web Application
Firewall
– www.modsecurity.org
• HTTP Traffic Logging
• Real-Time Monitoring and Attack Detection
• Attack Prevention and Just-in-time Patching
• Flexible Rule Engine
• Embedded Deployment (Apache, IIS7 and Nginx)
• Network-Based Deployment (reverse proxy)
– OWASP ModSecurity Core Rule Set Project, generic, plug-n-play
set of WAF rules
77
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

The OWASP Enterprise Security API
Custom Enterprise Web Application
Enterprise Security API
Authenticator
User
AccessController
AccessReferenceMap
Validator
Encoder
HTTPUtilities
Encryptor
EncryptedProperties
Randomizer
ExceptionHandling
Logger
IntrusionDetector
SecurityConfiguration
Existing Enterprise Security Services/Libraries
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
78

SAMM Quick Start
ASSES
questionnaire
GOAL
gap analysis
PLAN
roadmap
IMPLEMENT
OWASP
resources

Asses
• SAMM includes assessment worksheets for
each Security Practice

Goal
• Gap analysis
• Capturing scores from detailed assessments
versus expected performance levels
• Demonstrating improvement
• Capturing scores from before and after an
iteration of assurance program build-out
• Ongoing measurement
• Capturing scores over consistent time frames for
an assurance program that is already in place

Plan
• Roadmaps: to make the “building blocks” usable.
• Roadmaps templates for typical kinds of
organizations
• Independent Software Vendors
• Online Service Providers
• Financial Services Organizations
• Government Organizations
• Tune these to your own targets / speed

150+ OWASP Projects
PROTECT
Tools: AntiSamy Java/:NET, Enterprise Security API (ESAPI), ModSecurity Core Rule Set
Project
Docs: Development Guide, .NET, Ruby on Rails Security Guide, Secure Coding
Practices - Quick Reference Guide
DETECT
Tools: JBroFuzz, Lice CD, WebScarab, Zed Attack Proxy
Docs: Application Security Verification Standard, Code Review Guide, Testing
Guide, Top Ten Project
LIFE CYCLE
SAMM, WebGoat, Legal Project
83

Application security resources

Hard Copy

Hard Copy
• The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws -
Dafydd Stuttard
• Secure Programming with Static Analysis – Brian Chess, Jacob West
• The Art of Software Security Assessment – Mark Dowd, John McDonald , Justin Schuh
• The Security Development Lifecycle – Michael Howard
• Threat Modeling – Frank Swiderski, Window Snyder
• Securing Web Services with WS-Security – Rosenberg & Remy
• Core Security Patterns – Steel, Nagappan & Ray Lai
• Security Metrics – Andrew Jaquith
• Secure Programming with Static Analysis – Brian Chess, Jacob West
• The Art of Software Security Assessment – Mark Dowd, John McDonald , Justin Schuh
• The Security Development Lifecycle – Michael Howard
• Threat Modeling, designing for security – Adam Shostack
• Securing Web Services with WS-Security – Rosenberg & Remy
• Core Security Patterns – Steel, Nagappan & Ray Lai
• Security Metrics – Andrew Jaquith
|86

www.owasp.org
|87
87

|88
Other web sites
• www.webappsec.org
• www.cgisecurity.com
• buildsecurityin.us-cert.gov
• www.cert.org
• www.sans.org
• samate.nist.gov
• Tools
– www.owasp.org/index.php/Phoenix/Tools

|89
Mailing Lists
• OWASP Project Mailing lists
• Secure Coding List
• WebAppSec@securityfocus.com
• websecurity@webappsec.org (WASC)
• SANS NewsBites

90
AppSec RSS Feed
feeds.feedblitz.com/OWASP

Twitter
• @owasp_be
• @ivanristic
• @johnwilander
• @briankrebs
• @psiinon
• @krvw
• @0x6D6172696F
• @mikko
• @jeremiahg
• @DinisCruz
• @w3af
• @owasp
• @pdp
• @vanderaj

OWASP 24/7
https://soundcloud.com/owasp-podcast

OWASP Video
www.youtube.com/owaspglobal

SAMM Roadmap
Friday – User Day
• Talks
• Training
• Topic roundtables
9
Saturday – Project Day
•Publish SAMM v1.1
•Workshops
•Road map
owasp.org/index.php/OWASP_SAMM_Summit_2015

Key notes:
• Troy Hunt
• Simon Bennets
• Frank Breedijk
• Joshua Corman
• Tobias Gondrom
• Jim Manico
• Steve Lord
• Matt Tesauro

Belgium Chapter
• Meetings
• Local Mailing List
• Presentations & Groups
• Open forum for discussion
• Meet fellow InfoSec professionals
• Create (Web)AppSec awareness
• Local projects?
http://www.owasp.org/index.php/Belgium

Get involved
• Use and donate (feed)back!
• Attend chapter meetings
• Contribute to projects
• Donate resources
• Sponsor chapters / projects
• Become Member

98
That’s it…
seba@owasp.org
@SebaDele
Sebastien.deleersnyder@Toreon.com
Thank you!