Security For Application Development
-
Upload
6502programmer -
Category
Technology
-
view
82 -
download
3
description
Transcript of Security For Application Development
![Page 1: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/1.jpg)
Mike Tetreault, CISSP, CSSLP 1
An Overview of the OWASP Top Ten and Threat Modeling
SECURITY ESSENTIALS FOR APPLICATION DEVELOPMENT
12/17/2013
![Page 2: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/2.jpg)
Mike Teterault, CISSP, CSSLP 2
Who is Mike Tetreault?Over twenty years of IT experiencePrimarily applications, but also includes network, server, and database administration
Security backgroundLifelong interest in physical and data securitySecurity is the one constant across all of my rolesCertification Activities○ 2003 – Certified Information Systems Security Professional (CISSP)○ 2008 – Microsoft Certified Information Technology Professional – SQL Server 2005○ 2009 – Certified Secure Software Lifecycle Professional (CSSLP)○ 2013 – Passed Healthcare Information Security and Privacy Practitioner (HCISPP) exam
Introduction
12/17/2013
![Page 3: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/3.jpg)
Mike Teterault, CISSP, CSSLP 312/17/2013
Why focus on web applications?We all have them and we all use themThis is why they have the largest threat profile
Why are web applications everywhere?Quickly installed and updatedWork across devices and operating systems
Why is this bad?Data is accessible from anywhereClients do some hidden processing
This is what leads to vulnerabilities
Presentation Overview
![Page 4: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/4.jpg)
Mike Teterault, CISSP, CSSLP 412/17/2013
According to the 2013 Global Information Security Workfors Study by (ISC)2, 69% of the over 12,000 IT professionals surveyed believe that application vulnerabilities are the number one security issue for 2013.
Yahoo CISO departed in January 2013 in wake of a massive Cross Site Scripting (XSS) attack that turned Yahoo Mail into a spam factory.
Heartland Payment Systems suffered a SQL injection attack in 2008 which cost them $170 million, by their own admission.
2013 Ponemon Institute puts the overall cost of a data breach at $188 per record.
Why It Matters
![Page 5: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/5.jpg)
Mike Teterault, CISSP, CSSLP 5
OWASP Top Ten For 2013
12/17/2013
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
![Page 6: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/6.jpg)
Mike Teterault, CISSP, CSSLP 612/17/2013
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
![Page 7: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/7.jpg)
Mike Teterault, CISSP, CSSLP 712/17/2013
How Popular is SQL Injection?
![Page 8: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/8.jpg)
Mike Teterault, CISSP, CSSLP 812/17/2013
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.
What it looks like:http://example.com/saleitems?jsessionid=2P0OCLPSKHCJUN2JVdest=Hawaii
How to mitigate: 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
![Page 9: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/9.jpg)
Mike Teterault, CISSP, CSSLP 912/17/2013
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.
What it looks like:page += "<input name='creditcard' type='TEXT' value='" +
request.getParameter("CC") + "'>"; How to mitigate:
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)
![Page 10: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/10.jpg)
Mike Teterault, CISSP, CSSLP 1012/17/2013
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.
What it looks like:Valid: http://example.com/app/accountInfo?acct=myacctNot Valid: http://example.com/app/accountInfo?acct=notmyacct
How to mitigate: 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
![Page 11: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/11.jpg)
Mike Teterault, CISSP, CSSLP 1112/17/2013
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.
How to mitigate: 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
![Page 12: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/12.jpg)
Mike Teterault, CISSP, CSSLP 1212/17/2013
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.
How to mitigate: 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
![Page 13: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/13.jpg)
Mike Teterault, CISSP, CSSLP 1312/17/2013
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.
What it looks like: http://example.com/app/getappInfo http://example.com/app/admin_getappInfo
How to mitigate: 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
![Page 14: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/14.jpg)
Mike Teterault, CISSP, CSSLP 1412/17/2013
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.
What it looks like: 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" /> How to mitigate:
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
![Page 15: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/15.jpg)
Mike Teterault, CISSP, CSSLP 1512/17/2013
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.
How to mitigate: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
![Page 16: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/16.jpg)
Mike Teterault, CISSP, CSSLP 1612/17/2013
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.
How to mitigate: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
![Page 17: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/17.jpg)
Mike Teterault, CISSP, CSSLP 1712/17/2013
First, are there any questions about the OWASP top ten vulnerabilities?
Web applications present a big targetBroad profile with rich data
Where do you begin with your security efforts? Enter: Threat Modeling!
What now?
![Page 18: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/18.jpg)
Mike Teterault, CISSP, CSSLP 1812/17/2013
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?
![Page 19: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/19.jpg)
Mike Teterault, CISSP, CSSLP 1912/17/2013
Identify your security objectivesAll 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 CategoriesIdentityFinancialReputationPrivacy and RegulatoryAvailability Guarantees
How do you start?
![Page 20: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/20.jpg)
Mike Teterault, CISSP, CSSLP 2012/17/2013
Application OverviewUnderstand 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?
![Page 21: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/21.jpg)
Mike Teterault, CISSP, CSSLP 2112/17/2013
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
![Page 22: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/22.jpg)
Mike Teterault, CISSP, CSSLP 2212/17/2013
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
![Page 23: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/23.jpg)
Mike Teterault, CISSP, CSSLP 2312/17/2013
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
![Page 24: Security For Application Development](https://reader035.fdocuments.net/reader035/viewer/2022081403/554bddcdb4c905ac708b55aa/html5/thumbnails/24.jpg)
Mike Teterault, CISSP, CSSLP 2412/17/2013
Twitter: @6502 Email: [email protected] Resources:
OWASP – The Open Web Application Security Project○ https://www.owasp.org/
Threat Modeling, Frank Swiderski and Window Snyter, Microsoft Press, June 2004Threat Modeling Web Applications, J.D. Meier, Alex Mackman, Blaine Wastell,
Microsoft Press, May 2005Mailing 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