Threat Modeling for Web Applications (and other duties as assigned)

An Overview of the OWASP Top Ten Web
Application Risks and Threat Modeling
THREAT MODELING FOR WEB
APPLICATIONS (AND OTHER
DUTIES AS ASSIGNED)

10/28/2016 Mike Tetreault, CISSP, CSSLP, HCISPP
⦿ Who is Mike Tetreault?
● Twenty five years of IT experience
● Primarily web application development and team leadership, but also
includes network, server, and database administration
⦿ Security background
● Lifelong interest in physical and data security
● Security is the one constant across all of my roles
● Certification Activities
○ 2003 – Certified Information Systems Security Professional (CISSP)
○ 2009 – Certified Secure Software Lifecycle Professional (CSSLP)
○ 2013 – Healthcare Information Security and Privacy Practitioner (HCISPP)
Introduction
2

⦿ Why focus on web applications?
● We all have them and we all use them
● This is why they have the largest threat profile
⦿ Why are web applications everywhere?
● Quickly installed and updated
● Work across devices and operating systems
⦿ Why is this bad?
● Data is accessible from anywhere
● Clients do some hidden processing
⦿ This is what leads to vulnerabilities
Presentation Overview
3

⦿ According to the 2015 Global Information Security Workforce
Study by (ISC)2, 72% of the over 14,000 IT professionals
surveyed believe that application vulnerabilities are the
number one security issue for 2013.
⦿ Heartland Payment Systems suffered a SQL injection attack
in 2008 which cost them $170 million, by their own
admission.
⦿ 2016 “Cost of Data Breach” study by IBM and Ponemon puts
the overall cost of a data breach at $154 to $158 per record.
Why It Matters
4

OWASP Top Ten Web Application Security Risks
5
Injection Sensitive Data Exposure
Broken Data Authentication
and Session Management
Missing Function Level
Access Control
Cross-Site Scripting (XSS) Cross-Site Request Forgery
Insecure Direct Object
References
Using Components With
Known Vulnerabilities
Security Misconfiguration
Unvalidated Redirects and
Forwards

⦿ What it is:
● Injection flaws, such as SQL, OS, and LDAP injection occur when
untrusted data is sent to an interpreter as part of a command or
query. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper
authorization.
⦿ What it looks like:
● String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
⦿ How to mitigate:
● Keep untrusted data separate from commands and queries.
● Use a safe API with parameterized inputs.
● Scrub inputs to escape special characters (eg, SQL’s ‘:’ operator).
A1: Injection
6

How Popular is SQL Injection?
7

⦿ What it is:
● Application functions related to authentication and session
management are often not implemented correctly, allowing
attackers to compromise passwords, keys, or session tokens, or to
exploit other implementation flaws to assume other users’ identities.
● http://example.com/saleitems?
jsessionid=2P0OCLPSKHCJUN2JVdest=Hawaii
● Use a single set of strong authentication and session management
controls that has a simple interface for developers.
● Strong efforts should also be made to avoid Cross-Site Scripting (XSS)
flaws which can be used to steal session IDs.
A2: Broken Data Authentication and Session
Management
8

⦿ What it is:
● XSS flaws occur whenever an application takes untrusted data and
sends it to a web browser without proper validation or escaping.
XSS allows attackers to execute scripts in the victim’s browser
which can hijack user sessions, deface web sites, or redirect the
user to malicious sites.
● page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>";
● Properly escape all untrusted (ie, user supplied) data based on the
HTML context (body, attribute, JavaScript, CSS, or URL) that the
data will be placed into.
A3: Cross-Site Scripting (XSS)
9

⦿ What it is:
● A direct object reference occurs when a developer exposes a
reference to an internal implementation object, such as a file,
directory, or database key.
● Valid: http://example.com/app/accountInfo?acct=myacct
● Not Valid: http://example.com/app/accountInfo?acct=notmyacct
● Use per-user or per-session indirect references.
○ This means that the reference is only valid for a single user or
session, and means nothing to a different user or session.
A4: Insecure Direct Object References
10

⦿ What it is:
● Good security requires having a secure configuration defined and
deployed for the application, frameworks, application server, web
server, database server, and platform. Secure settings should be
defined, implemented, and maintained, as defaults are often
insecure. Additionally, software should be kept up to date.
● Maintain a repeatable hardening process that makes it fast and
easy to deploy another environment that is properly locked down.
● Implement a process for keeping abreast of and deploying all new
software updates and patches in a timely manner.
A5: Security Misconfiguration
11

⦿ What it is:
● Many web applications do not properly protect sensitive data.
Attackers may steal or modify such weakly protected data to
conduct credit card fraud, identity theft, or other crimes.
Sensitive data deserves extra protection such as encryption at rest
or in transit, as well as special precautions when exchanged with
the browser.
● Encrypt all sensitive data at rest and in transit.
● Use standard algorithms with proper key management.
● Do not store sensitive data unnecessarily.
● Disable autocomplete and caching on pages that collect or display
sensitive information.
A6: Sensitive Data Exposure
12

⦿ What it is:
● Most web applications verify function level access rights before making that
functionality visible in the UI. However, applications need to perform the same access
control checks on the server when each function is accessed. If requests are not
verified, attackers will be able to forge requests in order to access functionality without
proper authorization.
● http://example.com/app/getappInfo
● http://example.com/app/admin_getappInfo
● Implement a consistent and easy to analyze authorization module in your application.
○ Consider the process for managing entitlements to make sure it can be easily updated and
audited.
○ The default state should be “deny all” with explicit authorizations.
● Don’t rely on presentation logic alone to hide options from the user.
○ Authorization checks must also be implemented in the controller or business logic.
A7: Missing Function Level Access Control
13

⦿ What it is:
● A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included
authentication information, to a vulnerable web application. This allows the attacker to
force the victim’s browser to generate requests the vulnerable application thinks are
legitimate requests from the victim.
● http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
● Embedded link in malicious page: <img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />
● Include a unique token, individual to each user or session, in every page as a hidden
field.
○ Verify that this token is returned with every request. If it is not, destroy the session and force
the user to reauthenticate.
● Require an explicit user authentication for high-value transactions.
○ This ensure the user is aware of the activity.
A8: Cross-Site Request Forgery
14

⦿ What it is:
● Components, such as libraries, frameworks, and other software
modules, almost always run with full privileges. If a vulnerable
component is exploited, such an attack can facilitate serious data
loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a
range of possible attacks and impacts.
● Don’t use external, third-part components. It’s not realistic, but it
will work.
● Identify all components and versions you are using. Keep up to
date with both releases by the components maintainers and
identified vulnerabilities on security mailing lists and databases.
A9: Using Components with Known
Vulnerabilities
15

⦿ What it is:
● Web applications frequently redirect and forward users to
other pages and websites, sometimes using untrusted data to
determine the destination pages. Without proper validation,
attackers can redirect victims to phishing or malware sites,
or use forwards to access unauthorized pages.
● Don’t use redirects or forwards.
● If you do have to, use tokens instead of the URL or a portion
of the URL. This allows server-side code to translate the
mapping to the target URL.
A10: Unvalidated Redirects and Forwards
16

⦿ First, are there any questions about the OWASP Top
Ten vulnerabilities?
⦿ Web applications present a big target
● Broad profile with rich data
⦿ Where do you begin with your security efforts?
⦿ Enter: Threat Modeling!
What now?
17

⦿ A systematic approach for understanding, classifying,
and assigning risk to threats and vulnerabilities
⦿ Security becomes what it should be: A cost/benefit
analysis.
⦿ Based on two different classification schemes:
● STRIDE
○ STRIDE classifies threat
● DREAD
○ DREAD classifies risks
What is Threat Modeling?
18

⦿ Identify your security objectives
● All security can be characterized as being related to
Confidentiality, Integrity, or Availability.
● An objective can be tied to one or all of those characteristics
⦿ High Level Objective Categories
● Identity
● Financial
● Reputation
● Privacy and Regulatory
● Availability Guarantees
How do you start?
19

⦿ Application Overview
● Understand the Components, Data Flows, and Trust Boundaries.
● UML Use Case diagrams are handy for this.
⦿ Decompose the Application
● Identify the features and modules with security impacts.
● Understand:
○ How data enters the module.
○ How the module validates and processes the data.
○ Where the data flows.
○ How the data is stored.
○ What fundamental decisions and assumptions are made by the module.
⦿ Now that you know what the application looks like, you can
classify its threats using the STRIDE model.
What does the application look like?
20

⦿ Spoofing
● Users cannot become another user or assume their attributes.
⦿ Tampering
● Applications should never send internal data to users, and should always verify inputs before
storing or processing it.
⦿ Repudiation
● An application needs to be able to prove that authorized activities are initiated by authenticated
users.
⦿ Information Disclosure
● Applications should only store sensitive data if proper controls are in place.
⦿ Denial Of Service
● Large, resource-intensive queries should only be accessible to properly authorized and
authenticated users.
⦿ Elevation of Privileges
● Users should only be able to access information and processing capabilities appropriate for their
role in a system.
⦿ Each threat receives a DREAD score.
STRIDE – Characterizing Known Threats
21

⦿ Each threat is scored on a 1-10 scale, added together, and divided by 5.
⦿ Damage
● If a threat exploit occurs, how much damage will it cause?
⦿ Reproducibility
● How easy is it to reproduce a threat exploit?
⦿ Exploitability
● How difficult are the steps needed to exploit the threat?
⦿ Affected Users
● How many users are affected if a threat is exploited?
⦿ Discoverability
● How easy is it to discover the threat?
● Often set to 10 by default, with the assumption that it will be discovered.
DREAD – Classifying, Quantifying, Comparing,
and Prioritizing Risk
22

⦿ Analyze the DREAD score for each threat
⦿ Understand the remediation for each threat, and what you need
to do with the risk presented by each:
● Acceptance – Not all security is “worth it”
○ You don’t spend $50,000 on security controls for a hot dog cart.
● Avoidance – Just don’t do it
○ Not typically feasible in application development.
● Limitation – Take steps to minimize risk
○ Most common risk management strategy.
○ Example: Disk drives may fail, so we maintain RAID and backups.
● Transference – Let someone else take the risk
○ Outsource common functions that are not a core competency .
○ Purchasing insurance can be an option.
Next Steps
23

⦿ Let’s say you have a space station, and it has a highly
exploitable exhaust port… What would its DREAD score
look like?
⦿ Or you have a big invading space ship, and you allow
unauthenticated access to your network (and don’t
have host security)…
⦿ If you run a highly virtualized environment with
potentially hostile VM’s, be sure you monitor hosts
breaking out of the sandbox (and take quick action).
Other Uses!
24

⦿ Twitter: @6502
⦿ Email: mike@macrocosmictech.com
⦿ Resources:
● OWASP – The Open Web Application Security Project
○ https://www.owasp.org/
● Threat Modeling, Frank Swiderski and Window Snyder, Microsoft Press,
June 2004
● Threat Modeling Web Applications, J.D. Meier, Alex Mackman, Blaine
Wastell, Microsoft Press, May 2005
● Mailing Lists and other resources:
○ Common Vulnerabilities and Exposures Database - http://cve.mitre.org
○ Microsoft Security Response Center
○ SANS – http://www.sans.org
Questions / Comments / Resources
25

Threat Modeling for Web Applications (and other duties as assigned)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Threat Modeling for Web Applications (and other duties as assigned)

Similar to Threat Modeling for Web Applications (and other duties as assigned) (20)

Recently uploaded

Recently uploaded (20)

Threat Modeling for Web Applications (and other duties as assigned)