Upload
neovik82
View
218
Download
0
Embed Size (px)
Citation preview
8/14/2019 Path to a Secure Application
1/23
Ryan Berg
Co-Founder and Chief Scientist
March 2009
8/14/2019 Path to a Secure Application
2/23
Application security is more visible
Managers & Developers Are Being Asked Difficult Questions
What regulations and standards are required?
PCI, HIPAA, FISMA
What confidential data is at risk?
What risk threshold is tolerable?
Copyright 2009 Ounce Labs, Inc. All rights reserved.
Combating Data Theft Supporting Compliance Securing the SDLCSecuring Outsourcing
8/14/2019 Path to a Secure Application
3/23
and so are its failures
July 19, 2005 -- Visa USA Inc. and American Express Co.
are cutting ties with CardSystems, which left 40 millioncredit and debit card accounts vulnerable to hackers in one
of the biggest breaches of consumer data
Visa, Amex Cut Ties With Card Processor
ChoicePoint to Pay $15M Over Data Breach
ATLANTA Jan 26, 2006 (AP) ChoicePoint Inc. agreed Thursday to pay $15
million to settle Federal Trade Commission charges that the data
warehouser's security and record-handling procedures violated consumers'
privacy rights when thieves infiltrated the company's massive database.
Veterans Angered by File Scandal
Veterans brimmed with shock and anger yesterday at the loss of their personaldata by the Department of Veterans Affairs, but in many ways the information
security breach should not have come as a surprise.
VA Has Consistently Scored Poorly on Information Security
BJ's Settles Case with FTC over Customer Data
JUNE 17, 2005 -- After credit card data for thousands of customers was used to
make fraudulent purchases in other stores, BJ's Wholesale Club Inc. has agreed
FTC alleges weak security at wholesale club led to fraudulent sales valued in the millions
1.4 million records stolen from retailer
NEW YORK (CNN/Money) - Shoe retailer DSW this week said that it estimates
that 1.4 million of its customers' credit card records were stolen, as well as
transaction information involving 96,000 checks.
Shoe retailer DSW says customer records at 108 stores were stolen
http://money.cnn.com/http://subscribe.washpost.com/contactus.nsf/frmsubscribezip?openform&code=wchttp://abcnews.go.com/8/14/2019 Path to a Secure Application
4/23
Is this really necessary?
Whats being done isnt working
Security isnt always included
Software Engineer vs. Software Security Engineer
Coding guidelines vs. securecoding guidelines
Build Security In sounds deceptively simple
Starts with training. This class is a good place to start. Requires a commitment to change. If we agree that what we are
doing isnt working than it should be obvious that we need tochange what we are doing.
Policy is not a four letter word Requirements, Requirements, Requirements
Developers need security requirements, if not given dontassume, demand.
Have a plan before you need one
Copyright 2009 Ounce Labs, Inc. All rights reserved.
8/14/2019 Path to a Secure Application
5/23
Follow the path to secure coding
Copyright 2009 Ounce Labs, Inc. All rights reserved.
Create consistent
processes, policies,and a culture of
improved security
Large-scale design f laws
typically trump individualcoding errors
Developers must
identify all
vulnerabilities in thecode, then remediate
the greatest risks f irst
Consistency
Prioritize
remediation
Provide the
whole picture
8/14/2019 Path to a Secure Application
6/23
The answers are only found in the source code
Does the application enforce oreven use appropriate accesscontrols?
In what ways and in what placesdoes the application attempt toconnect to the network?
Is there malicious code or back
doors in your applications?
Can user inputs or outputs cancorrupt your system ?
Is customer credit cardinformation encrypted?
Is sensitive data being storedoutside of your database?
8/14/2019 Path to a Secure Application
7/23
Whereto look for vulnerabilities
IMPLEMENTATIONDESIGN
Copyright 2009 Ounce Labs, Inc. All rights reserved.
Buffer overflows,result frommismanagement
of memory Race conditions,
result from calltiming mismatches
Authentication Encryption Use of insecure external codetypes Validation of data input and
application output
8/14/2019 Path to a Secure Application
8/23
Howto look for vulnerabilities
Manual Code Review
Time-consuming, expensive,error prone
Penetration Testing
Useful but can only discern a
small sub-set possible errors
Automated Testing Tools
Copyright 2009 Ounce Labs, Inc. All rights reserved.
The most effective approach is tointegrate source code vulnerabilityscanners into the applicationdevelopment, integration and testprocess.(Gartner)
8/14/2019 Path to a Secure Application
9/23
An Interesting Aside
From Microsofts SDL http://msdn2.microsoft.com/en-us/library/ms995349.aspx
However, one finding will come as no surprise to long-timesecurity researchers: penetration testing is not the way to achievesecurity. Penetration testing is an element of the Final Security
Review (FSR) for a major software release, but product teamactivities throughout the entire lifecycle focus on threat modeling,code reviews, the use of automated tools, and fuzz testing ratherthan penetration testing. The latter measures are much morethorough in preventing or removing security bugs than the classicad hoc penetration testing.
8/14/2019 Path to a Secure Application
10/23
That wasnt really helpful
It is much more effective to look at the places in theSDLC that you can reduce risk.
Requirements
Design
Implementation
Test Deployment
8/14/2019 Path to a Secure Application
11/23
Requirements
Identifying security requirements are an integral part of thesoftware design process, and the most neglected
Just as good project requirements requires use cases, good
security requirements require abuse cases Must be able to identify all potential assets ask risk and outline
the required and acceptable mitigation requirements.
Example of a bad requirement: All sensitive data needs to be encrypted
Example of a better requirement:
All sensitive data needs to be encrypted both in transit and at rest usingno less than 256 bit AES encryption, see addendum A for the list of itemsthat are considered sensitive for this application.
8/14/2019 Path to a Secure Application
12/23
Design: Policy Definition
It is important that organizations begin to formalize secure codingguidelines.
Avoid the temptation to grade an organization, development
manager, or individual contributors, ability to deliver secure codewithout letting them know what is on the test.
Policy, in the case of security requirements, is to remove ambiguity asmuch as possible.
Examples
New development projects using C/C++ must avoid the use of all following apis:gets(), strcpy(),unbouded use the printf and sprintf family of calls etc.
All data transferred from web clients that contain customer specific informationmust be transported using SSL, and if any personal information is stored usingcookies the entire application needs to be SSL enabled.
8/14/2019 Path to a Secure Application
13/23
What Details: Threat Modeling
Threat modeling is an important aspect in developing good securityrequirements as well as designing good mitigation strategies
Aspects of threat modeling should occur in several phases of the SDLC
During Requirements Phase 1: Identifying assets at risk and business objectives Phase 2: Generate use and abuse cases
During Design
Phase 3: Identify components responsible for controlling access to and from assets identified
in Phase1. Phase 4: Identify the threats posed by Phase 2 against the components outlined in Phase 3. During Implementation & Test
Phase 5: Review application to identify weaknesses against the threats identified in Phase 4about and review mitigation and remediation efforts.
Additional resources
http://msdn2.microsoft.com/en-us/security/aa570411.aspx
http://www.projects.ncassr.org/threatmodeling/
8/14/2019 Path to a Secure Application
14/23
Design: Security Design Review
The security design review is a critical step in the SDLC. The primarygoal of this step is to verify that the policies identified in therequirements and phases 1-4 of the threat modeling exercise have theappropriate mitigation strategies identified in the applicationarchitecture.
Identify any gaps, this may include identifying new threats.
This should be done as early in the process as possible, for an agiledevelopment process every feature iteration that impacts security asidentified by the requirements needs to perform this step.
8/14/2019 Path to a Secure Application
15/23
Test: Application Vulnerability Assessment
Think of this as the verification step. This is to verify that allpolicy requirements and threats have the appropriate mitigation
in the final product.
This also enables unintended or new threats to have anotherchance of being found prior to deployment.
Leverage tools as much as possible to reduce costs.
Copyright 2009 Ounce Labs, Inc. All rights reserved.
8/14/2019 Path to a Secure Application
16/23
WhatTo Look For: The Checklist
Security-related functions
Input/Output validation and
encoding errors
Error handling and loggingvulnerabilities
Insecure Components
Coding errors
Detecting and correcting securityvulnerabilities early in theapplication development life cycle,prior to deployment andoperations, results in significantrisk and cost reduction.
Gartner
8/14/2019 Path to a Secure Application
17/23
Security-related Functions
Weak or Nonstandard Cryptography
Non-Secure Network Communications
Access Control Vulnerabilities
MD5 is no longer considered secure for highly sensitive and business criticalapplications, SHA1 is also considered broken though no practical attacks have beenidentified.
Microsoft is banning certain cryptographic functions from new computer code, citing increasinglysophisticated attack, http://www.eweek.com/article2/0,1759,1859751,00.asp
The following example was from a content management systems password resetfunction.
/**
* Generates a random 10 characters password.
** @return the generated password.
*/
public static synchronized String generate()
{
return Long.toString(Math.abs(random.nextLong()) % MAX_RANDOM_LENGTH,
Character.MAX_RADIX);}
The biggest failure in encryption is notoften the algorithm used but more oftenthan not it is the failure to properly
identify what data needs to beencrypted and making sure that theappropriate encryption is alwaysutilized.
http://www.eweek.com/article2/0,1759,1859751,00.asphttp://www.eweek.com/article2/0,1759,1859751,00.asp8/14/2019 Path to a Secure Application
18/23
Input/Output Validation and Encoding Errors
Have we not learned to NEVER trust the user, all input needs to be validated?
What is the problem with the code below?
SQL Injection Vulnerabilities
Cross-Site Scripting Vulnerabilities
OS Injection Vulnerabilities
Custom Cookie/Hidden Field Manipulation
It is not all about SQL Injectionand XSS (though those are still ahuge problem).
public void doGet( HttpServletRequest req,HttpServletResponse res )
throws IOException, ServletException{
String pageName = getParameter(pageName) !=null ? : getParameter(pageName);
log.info("Request for page: "+pageName);String forward =
"/"+pageName+"?+req.getQueryString();RequestDispatcher disp =
req.getRequestDispatcher(forward);
disp.forward( req, res );}
8/14/2019 Path to a Secure Application
19/23
Error Handling & Logging Vulnerabilities
Consider the following code example:
public void doPost( HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException{
RequestDispatcher disp = null;
String user = getParameter(user) ! =null ? :getParameter(user);String pwd = getParameter(pwd) !=null ? :getParameter(pwd);if(!validUser(user,pwd)) {
log.warn(Invalid login received from: + user + password: +pwd);
disp = req.getRequestDispatcher(/jsp/invalidLogin.jsp);} else {
log.info(Successful login attempt from: + user);disp = req.getRequestDispatcher("/jsp/loginSuccess.jsp);
}disp.forward( req, res );
}
Insecure Error Handling
Insecure or Inadequate Logging
There really are two major
issues with logging:
1. Lacking a consistentlogging framework.
2. Logging the wrong data orbreaking company policyand regulations (think: PCI)
8/14/2019 Path to a Secure Application
20/23
Insecure Components
Developers need to understand where the utilities provided by the framework begin and end whenrelated to security. Consider the following code from a .NET web application.
Registration Form Please Sign-In
Even if you have Microsofts page validation enabled (the default) you are still vulnerable.
As we focus our efforts to fix the low hanging fruit, the attacks are moving to the application layer.
There are many undocumented APIs that exist as public interfaces in the JDK or the .NETframework
Many of these interfaces may bypass internal member data validation that if used directly could
crash the JVM (or lead to more serious vulnerabilities http://www.blackhat.com/presentations/win-usa-03/bh-win-03-schoenfeld.pdf
Unsafe Native Methods
Unsupported API
Improper Use of 3rd Party Application Frameworks
8/14/2019 Path to a Secure Application
21/23
Coding Errors
Use of native libraries (System.loadLibrary, [DllImport]) can alsoexpose your web application to this more traditional style of attack.
Whats wrong with this code?
protected void doGet(HttpServletRequestrequest,HttpServletResponse response) {
InputStreamReader inStr = newInputStreamReader(request.getInputStream());
BufferedReader in = new BufferedReader(inStr);
while(in.readline()!=null) {//process the request
}}
Buffer Overflow Vulnerabilities
Format String Vulnerabilities
Denial of Service Errors
Race Conditions
Most modern day webapplications are immune tothe more traditional
overflow style of attacks,but anytime the user is ableto control data that reachesan internal system thepossibility exists.
http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf
8/14/2019 Path to a Secure Application
22/23
Follow The Path: The Checklist
Security-related functions
Weak or Nonstandard Cryptography
Non-Secure Network Communications
Application Configuration Vulnerabilities
Access Control Vulnerabilities
Input/Output validation and encoding errors
SQL Injection Vulnerabilities
Cross-Site Scripting Vulnerabilities
OS Injection Vulnerabilities
Custom Cookie/Hidden Field Manipulation
Error handling and logging vulnerabilities Insecure Error Handling
Insecure or Inadequate Logging
Insecure Components
Unsafe Native Methods
Unsupported Methods Improper use of 3rd Party Application Frameworks
Coding errors
Buffer Overflow Vulnerabilities
Format String Vulnerabilities
Denial of Service Errors Race Conditions
8/14/2019 Path to a Secure Application
23/23
Ryan Berg, Chief Scientist
For more information, download my white paper at: www.ouncelabs.com/path