4. It is broken so lets fix it
• Secure development is broken, we aren’t progressing
• Cross Site Scripting, 11 years old?
• SQL Injection, 12 years old?
• Still major problems in 2010 and for years to come
4
5. It is broken so lets fix it
Source: http://www.cvedetails.com
5
6. It is broken so lets fix it
• CVE statistics only show publicly known vulns
• They do show a lack of app sec progress though
• Around 30% of all vulnerabilities in 2005, 2006, 2007,
2008, 2009 and 2010 XSS or SQL Injection
• Only one source, lets look at another one
6
7. It is broken so lets fix it
• WASC Web Application Security Statistics
• Sanitised data from pen tests, audits etc
• Still a tiny sample size (0.006% of all websites)
• These stats also show a lack of app sec progress
• 2008 report has less sites but more vulnerabilities
7
8. It is broken so lets fix it
Source: http://www.webappsec.org/
8
9. It is broken so lets fix it
• Verizon Data Breach Investigations Report 2010
• 89% of all data breaches attributable to SQL Injection
• 2010 report released in July
• This report also shows a lack of app sec progress
9
11. The current approach
And why I think it fails to deliver secure applications
• We put the cart before the application security horse
• Security tells developers about specific vulnerabilities
• We hope they figure out how to prevent them
• Inevitably security flaws end up in live code
• Security complains when data gets stolen
11
12. The current approach
And why I think it fails to deliver secure applications
• What if we taught learner drivers in the same way?
• Instructor tells driver about the different ways to crash
• We hope the driver figures out how not to crash
• Inevitably the driver will crash
• People complain when they get crashed into
12
13. The current approach
And why I think it fails to deliver secure applications
• Training often fails to include writing secure code
• No secure coding in training == no secure coding in
the real world
• Exploiting webgoat etc is basic pen testing training
• Software Craftsmanship needs to meet security
• Less presentations and exploits more secure coding
13
14. The current approach
And why I think it fails to deliver secure applications
• Many lists of vulnerabilities
• OWASP Top 10
• White Hat Security Top 10
• SANS Top 25
• Others??
14
15. The current approach
And why I think it fails to deliver secure applications
Failure to Preserve Web Page Structure Failure to Preserve SQL Query Structure
Reliance on Untrusted Inputs in a Security Decision
Buffer Copy without Checking Size on Input Incorrect Calculation of Buffer Size
Improper Control of Filename for Include/Require Statement in PHP Program
URL Redirection to Untrusted Site Missing Encryption of Sensitive Data
Content Spoofing Allocation of Resource Without Limits or Throttling
Cross Site Request Forgery Information Leakage Injection Flaws
Cross Site Scripting Incorrect Permission Assignment for Critical Resource
Insufficient Transport Layer Protection Failure to Preserve OS Command Structure
Insufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory
Improper Access Control Insufficient Authentication Insecure Cryptographic Storage
SQL Injection Race Condition Use of Hard-coded Credentials Session Management
Insecure Direct Object Reference Improper Validation of Array Index
Information Exposure Through an Error Message Unvalidated Redirects and Forwards
Predictable Resource Location Abuse of Functionality
Failure to Restrict URL Access Download of Code Without Integrity Check
Buffer Access with Incorrect Length Value Security Misconfiguration
Broken Authentication Improper Check for Unusual or Exceptional Conditions
Unrestricted Upload of File with Dangerous Type
Integer Overflow or Wraparound Missing Authentication for Critical Function
Use of a Broken or Risky Cryptographic Algorithm
15
16. The current approach
And why I think it fails to deliver secure applications
• Many lists of vulnerabilities
• OWASP Top 10
• White Hat Security Top 10
• SANS Top 25
• Others??
• != Secure development guidance
• 45 vulnerabilities, 41 unique names
• Training courses often based these lists
16
17. Philosophical Application Security
Give a man a fish and you feed him for a day, teach him to
fish and you feed him for a lifetime.
I want to apply this to secure development education:
Teach a developer about a vulnerability and he will prevent
it, teach him how to develop securely and he will prevent
many vulnerabilities
17
18. The current approach
And why I think it fails to deliver secure applications
• Lets put the application security horse before the cart
• Security tells developers how to write secure code
• Developer doesn't need to guess anymore
• Common vulnerabilities prevented in applications
• Realistic or just a caffeine fueled dream?
18
20. The current approach
The Principleswhy I think it fails to deliver secure applications
And of Secure Development
Failure to Preserve Web Page Structure Failure to Preserve SQL Query Structure
Reliance on Untrusted Inputs in a Security Decision
Secure Communications
Buffer Copy without Checking Size on Input Incorrect Calculation of Buffer Size
Output Validation
Improper Control of Filename for Include/Require Statement in PHP Program
URL Redirection to Untrusted Site Missing Encryption of Sensitive Data
Content Spoofing Allocation of Resource Without Limits or Throttling
Input Validation
Cross Site Request Forgery and Logging
Auditing Information Leakage Injection Flaws
Cross Site Scripting Incorrect Permission Assignment for Critical Resource
Insufficient Transport Layer Protection Failure to Preserve OS Command Structure
Authorisation
Insufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory
Session Management
Improper Access Control Insufficient Authentication Insecure Cryptographic Storage
SQL Injection Race Condition Use of Hard-coded Credentials Secure Storage
Insecure Direct Object Reference Improper Validation of Array Index
Error Handling
Information Exposure Through an Error Message Unvalidated Redirects and Forwards
Predictable Resource Location Abuse of Functionality
Failure to Restrict URL Access Download of Code Without Integrity Check
Buffer Access with IncorrectAccess Value
Secure Resource Length Security Misconfiguration
Authentication
Broken Authentication Improper Check for Unusual or Exceptional Conditions
Unrestricted Upload of File with Dangerous Type
Integer Overflow or Wraparound Missing Authentication for Critical Function
Use of a Broken or Risky Cryptographic Algorithm
20
21. The Principles of Secure Development
• Input Validation
• Identify the data your application must accept
• Identify the input points data will be received through
• Define validation for each data type (content, size etc)
• Use whitelisting validation approach where possible
• Blacklisting is harder and potentially less secure
21
22. Two simple examples
• Whitelist (allow “known” good)
<td>
<input type=text runat=server id=userID>
<asp:RegularExpressionValidator runat=server
ControlToValidate= "userID"
ErrorMessage="ID must be 6-10 letters."
ValidationExpression="[a-zA-Z]{6,10}" />
</td>
• Blacklist (replace “known” bad)
public class ReplaceSingleQuotes {
public static void main(String[] args) {
String str = " ' OR 1=1-- ";
String strreplace = " " ";
String result = str.replaceAll(" ' ", strreplace);
System.out.println(result);
}
}
22
23. Demo 1
• Lack of input validation
• SQLi in FreeRealty used to bypass authentication
• Credit to Sid3^effects, April 2010
23
24. Demo 1
• SQL Injection allows users to bypass authentication
• Demo shows the SQL Injection authentication bypass
• Delete a users house listing
• I then open the source code and show/explain the
vulnerability
• I put a simple fix in place and explain this
• I carry out the same attack against the secured code
• SQL Injection fails against the secured code
24
25. The Principles of Secure Development
• Output Validation
• Identify the data your application must output
• Understand where your data should end up
• Choose the correct encoding for the data's destination
• Use whitelist validation for data returned by the app
• Not just about encoding, think credit card numbers etc
25
26. Two simple examples
• HTML Encoding
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));
• Replace credit card number
@card_masked = card_masked.sub(/^([0-9]+)([0-9]{4})$/) { '*' *
$1.length + $2 }
26
27. Demo 2
• Lack of output validation
• Stored XSS in DBHcms used to steal user cookies
• Credit to ITSecTeam, May 2010
27
28. Demo 2
• Stored XSS allows for theft of admin cookie/session
• Demo shows the theft of an admin cookie using XSS
• I show the cookie logger and captured cookie
• Demo how I can replace my cookie with the admin
cookie and “become” admin
• I show the vulnerability in the source code
• I put a simple fix in place and explain this
• I carry out the same attack against the secured code
• XSS attack fails against the secured code
28
29. The Principles of Secure Development
• Error Handling
• Even the best apps will crash at some point
• Detailed error messages can help an attacker
• Handle error conditions securely, sanitise the message
• No error handling == information leakage
29
30. Demo 3
• Lack of error handling
• Lack of error handling leads to information leakage
• Sample page by David Rook
30
31. Demo 3
• Lack of error handling leads to information leakage
• Demo shows the lack of error handling
• I show the information leakage and then the source
code
• I show the vulnerability in the source code
• I put a simple fix in place and explain this
• I carry out the request against the secured code
• The exception is handled in a secure manner
31
33. The Principles of Secure Development
• Authentication and Authorisation
• Applications often have a need to authenticate users
• Often at least two levels of authorisation
• Prevent horizontal and vertical privilege escalation
• Strong passwords and management systems
• Ensure A+A is secure, not a false sense of security
• Don’t rely on fields that are easily spoofed
• Re-authenticate users for sensitive actions
33
34. The Principles of Secure Development
• Session Management
• Used to manage authenticated users
• Ensure that your sessionID’s have sufficient entropy
• SessionID’s must not be predictable or reusable
• Never build your own session management, it will fail
• Protect sessionID’s when in transit
• Issue a new value for sensitive actions
34
35. The Principles of Secure Development
• Secure Communications
• Protect sensitive data in transit
• As with all cryptography, don’t create your own
• Don’t use broken protection mechanisms
• Don’t just SSL the logon pages, protect the session!
• Avoid mixing secure and insecure traffic on a page
35
36. The Principles of Secure Development
• Secure Storage
• Protect sensitive data when stored
• As with all cryptography, don’t create your own
• Don’t use broken protection mechanisms
• Don’t just SSL the logon pages, protect the session!
• Avoid mixing secure and insecure traffic on a page
36
37. Demo 4
• Lack of secure storage
• Passwords stored insecurely in Flat File Logon
• Credit to ViRuSMaN, February 2010
37
38. Demo 4
• Lack of strong hashing and access control lead to
usernames and passwords being disclosed
• Demo shows the weak hashes and cracking of them
• I show the vulnerability in the source code
• I put a simple fix in place and explain this
• I carry out the same attack against the secured code
• The hashes are salted (strong) and can’t be cracked
38
41. The Principles of Secure Development
• Secure Resource Access
• Obscurity != security, don’t try to hide sensitive resources
• Least privilege users for all tasks
• Store library, include, and utility files outside web root
• Securely harden servers including filesystem ACL’s
41
42. Demo 5
• Lack of secure resource access
• Local file include vulnerability in Bit Weaver 2.7
• Credit to John Leitch, July 2010
42
43. Demo 5
• Insecure server configuration exploited to steal data
from the server
• Demo a local file include attack to steal “secrets” file
• I change PHP settings and server ACL’s
• I carry out the same attack against the secured server
• The local file include attack will fail
43
45. The Principles of Secure Development
• Auditing and Logging
• Logs will be created by your application for many events
• These logs must not contain sensitive data
• They must contain sufficient information for auditing
• Logs should be sent to a central server
• If possible the logs should be stored “read only”
• Retain logs for as long as required by laws/regulatory
standards
45
46. But I need to prevent vulnerability “X”
Specific vulnerabilities for each principle
OWASP White Hat Security SANS
Input Validation Injection, Cross Site Scripting, Security Cross Site Scripting, SQL Injection, Content Unrestricted Upload of File with Dangerous
Misconfiguration, Unvalidated Redirects Spoofing Type, Failure to Preserve SQL Query
and Forwards Structure, Failure to Preserver Web Page
Structure, Failure to Preserve OS Command
Structure, URL Redirection to Untrusted Site,
Buffer Copy without Checking Size on Input,
Improper Limitation of a Pathname to a
Restricted Directory, Improper Control of
Filename for Include/Require Statement in PHP
Program, Buffer Access with Incorrect Length
Value, Improper Validation of Array Index,
Integer Overflow or Wraparound, Incorrect
Calculation of Buffer Size
Output Validation Cross Site Scripting Cross Site Scripting Failure to Preserve Web Page Structure
Error Handling Information Leakage Information Exposure Through an Error
Message, Improper Check for Unusual or
Exceptional Conditions
Authentication Broken Authentication and Session Insufficient Authorisation, Insufficient Use of Hard-coded Credentials, Incorrect
and Authorisation Management, Security Misconfiguration, Authentication, Abuse of Functionality Permission Assignment for Critical Resource,
Unvalidated Redirects and Forwards Reliance on Untrusted Inputs in a Security
Decision, Missing Authentication for Critical
Function, Improper Access Control
Session Broken Authentication and Session Cross Site Request Forgery Cross Site Request Forgery
Management Management, Cross Site Request Forgery
Secure Insufficient Transport Layer Protection Use of a Broken or Risky Cryptographic
Communications Algorithm, Missing Encryption of Sensitive Data
Secure Storage Insecure Cryptographic Storage Use of a Broken or Risky Cryptographic
Algorithm, Missing Encryption of Sensitive Data
Secure Resource Insecure Direct Object Reference, Failure to Predictable Resource Location Improper Limitation of a Pathname to a
Access Restrict URL Access, Security Restricted Directory, Improper Control of
Misconfiguration, Unvalidated Redirects Filename for Include/Require Statement in PHP
46
and Forwards Program, Allocation of Resource Without Limits
or Throttling
47. Lets redefine what secure development means
• Follow a small, repeatable set of principles
• Try not to focus on specific vulnerabilities
• Develop securely, not to prevent "hot vuln of the day"
• Integrate security, build it into the code
47
49. The principles approach is working
• Private banking development company, Switzerland
• Security lead saw the secure development principles
• Re-designed his secure development training program
• Security training costs down
• Quicker "spin up" of security trained developers
• Security within their SDLC now based on the principles
49
50. The principles approach is working
• Fortune 500 financial services company, USA
• One developer tasked with training local developers
• Had tried the “teach all the vulns” approach and it failed
• Used principles based training with .NET examples
• CSO has now implemented this approach company wide
50
51. Evolution, not revolution
• Don’t make things more difficult than they need to be
• Not a new wheel, its just a smoother, easier to use wheel
• Don’t treat security as something separate, integrate it
• A security bug is just another bug
• Secure development doesn’t have to be hard, KISS it!
51
52. We knew how to fix this in 1978!
• What happened in 1978 that is so special?
• IBM released a video discussing information security
• Remember what I said about not reinventing the
wheel?
52
53. Demo 6
• Short video from IBM in 1978
• Discusses the principles of Authentication and
Authorisation in IBM systems (1978)
• Reinforces the “don’t reinvent the wheel” statement
53
54. Demo 7
• Short video from IBM in 1978
• Discusses the principle of Secure Communications in
IBM systems (1978)
• Reinforces the “don’t reinvent the wheel” statement
54
55. Demo 8
• Short video from IBM in 1978
• Discusses the principles of Input Validation and Error
Handling in IBM systems (1978)
• Reinforces the “don’t reinvent the wheel” statement
55
56. Demo 9
• Short video from IBM in 1978
• Discusses the principles of Input Validation and Error
Handling in IBM systems (1978)
• Reinforces the “don’t reinvent the wheel” statement
56
57. We need to learn from 1978
• Those ideas from 1978 are still valid in 2010
• 1st Video – Authentication and Authorisation
• 2nd Video – Secure Communications
• 3rd & 4th Videos – Validation and Error Handling
57
58. Talk is cheap……
• What am I doing to promote this approach?
• Producing more principles of secure development info
• Helping companies who have adopted this approach
• Developing principles based security tools
58
59. Apply
• Download principles documentation from Security Ninja
• Focus secure development training on code not exploits
• Use your language/s in all code examples
• Implement principles based security code reviews
• Tie all security findings back to specific principles
• Use principles based code review tools (coming soon!)
59
60. Questions?
• Follow me, visit my websites and ask questions :)
• Security Ninja, myself and my security colleagues
www.securityninja.co.uk
@securityninja
60
