Injecting simplicity not SQL BSides Las Vegas 2010

David Rook

Injecting simplicity not SQL

SecurityBSides, Las Vegas

Tuesday, 27 July 2010

if (slide == introduction)
System.out.println("I’m David Rook");

• Security Analyst, Realex Payments, Ireland
CISSP, CISA, GCIH and many other acronyms

• Security Ninja (www.securityninja.co.uk)

• Speaker at many security conferences

• Nominated for blog awards for Security Ninja

• A mentor for the InfoSecMentors project

• I like to make, break and fix things


About this Presentation

• What this presentation isn’t
– A technical discussion about one specific vulnerability
– No 0 days, new attacks or new vulnerabilities
– Just a moaning session

• What this presentation is:
– A look at a simpler approach to secure development
– A positive approach to secure development education
– How other companies have implemented this approach


Agenda

• It is broken so lets fix it

• The current approach

• The Principles of Secure Development

• The principles approach is working


It is broken so lets fix it

• Secure development is broken, we aren’t progressing

• SQL Injection, 10 years old?

• Cross Site Scripting, 11 years old?

• Still major problems in 2010 and for years to come



SQLi & XSS = 33.90%
29.30%
31.65%
7000

6000

5000 CVE's
Total
SQLi
4000 XSS

3000

2000

1000

0
2010 2009 2008 2007 2006 2005 2004 2003 2002 2001 2000


• 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

Source: http://www.cvedetails.com/vulnerabilities-by-types.php


• 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

Source: http://projects.webappsec.org/Web-Application-Security-Statistics


100000

90000

80000
Sites
70000 Vulns
60000

50000
40000
30000
20000
10000
0

2008 2007

The current approach
(And why I think it fails to deliver secure applications)

• We put the cart before the application security horse

• Security guys tell developers about specific vulnerabilities
• We hope they figure out how to prevent them
• Inevitably security flaws end up in live code
• Security guys complain when data gets stolen



• What if we taught 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



• Many lists of vulnerabilities

• OWASP Top 10
• White Hat Sec Top 10
• SANS Top 25
• Others??


Failure to Preserve Web Page Structure Failure to Preserve SQL Query Structure
Reliance on Untrusted Inputs in a Security Decision
Missing Encryption of Sensitive Data Incorrect Calculation of Buffer Size
Improper Control of Filename for Include/Require Statement in PHP Program
URL Redirection to Untrusted Site Buffer Copy without Checking Size on Input
Content Spoofing Allocation of Resource Without Limits or Throttling
Cross Site Request Forgery Information Leakage Injection Flaws
Cross Site Scripting Improper Check for Unusual or Exceptional Conditions
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
Race Condition Use of Hard-coded Credentials Session Management
Insecure Direct Object Reference Improper Validation of Array Index
Information Exposure Through an Error Message Abuse of Functionality
Predictable Resource Location Download of Code Without Integrity Check
Failure to Restrict URL Access Unvalidated Redirects and Forwards
Buffer Access with Incorrect Length Value Security Misconfiguration
SQL Injection Unrestricted Upload of File with Dangerous Type
Broken Authentication Missing Authentication for Critical Function
Integer Overflow or Wraparound
Use of a Broken or Risky Cryptographic Algorithm
Incorrect Permission Assignment for Critical Resource


• Many lists of vulnerabilities

• OWASP Top 10
• White Hat Sec Top 10
• SANS Top 25
• Others??

• != Secure development guidance

• 45 vulnerabilities, 41 unique names

• Training courses etc based on these lists

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 application development:

Teach a developer about a vulnerability and he will
prevent it, teach him how to develop securely and
he will prevent many vulnerabilities.


What we need to do

• Put the application security horse before the cart

• Security guys tell 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?


Principles 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
Missing Encryption of Sensitive Data Incorrect Calculation of Buffer Size
Output Validation
Improper Control of Filename for Include/Require Statement in PHP Program
URL Redirection to Untrusted Site Buffer Copy without Checking Size on Input
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 Improper Check for Unusual or Exceptional Conditions
Insufficient Transport Layer Protection Failure to Preserve OS Command Structure
Authorisation
Insufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory
Session Management Insecure Cryptographic Storage
Improper Access Control Insufficient Authentication
Race Condition Use of Hard-coded Credentials Session Management
Insecure Direct Object Reference Improper Validation of Array Index
Error Handling Secure Resource Access
Information Exposure Through an Error Message Abuse of Functionality
Predictable Resource Location Download of Code Without Integrity Check
Failure to Restrict URL Access Unvalidated Redirects and Forwards
Buffer Access with Incorrect Length Value Security Misconfiguration
SQL Injection Authentication
Unrestricted Upload of File with Dangerous Type
Broken Authentication Missing Authentication for Critical Function
Integer Overflow or Wraparound
Secure Storage a Broken or Risky Cryptographic Algorithm
Use of
Incorrect Permission Assignment for Critical Resource

The Principles of Secure Development

• Input Validation

• Identify the data your application must accept and all input points
• Create regex’s to validate each data type (content and size)
• For example, a credit card number data type: d{12,16}$
• Use whitelisting for validation where possible
• Blacklisting approach harder and potentially less secure
• Blacklist example, replacing single quotes:
s.replaceAll(Pattern.quote(" ' "),
Matcher.quoteReplacement(" " "))


Demo 1

• Lack of input validation

• SQL injection in FreeRealty can be used to bypass authentication
• Credit to Sid3^effects, April 2010



• Output Validation

• Identify and define the data your application must output
• Understand where (i.e. in a URL) your data should end up
• Choose the correct output encoding for the data's destination
• Proper encoding means this attack:
www.examplesite.com/home.html?day=<script>alert(document.cookie)</script>
Becomes:
day=%3Cscript%3Ealert%28document.cookie%29%3C/script%3E


Demo 2

• Lack of output validation

• Stored XSS in DBHcms can be used to steal user cookies
• Credit to ITSecTeam, May 2010



• Error Handling

• Even the best apps will crash at some point, be prepared!
• Crashes/errors can help an attacker if you don’t handle them
• Handle error conditions securely, sanitise the message sent
• No error handling == information leakage
Microsoft OLE DB Provider for ODBC
Drivers(0x80040E14)
[Microsoft][ODBC SQL Server Driver]
[SQL Server]Invalid column name

/examplesite/login.asp, line 10

Demo 3

• Lack of error handling

• Lack of error handling leads to information leakage
• Sample page by David Rook



• Authentication and Authorisation

• Even simple apps often have a need to authenticate users
• Often at least two levels of authorisation
• Need to prevent horizontal and vertical privilege escalation
• Implement strong passwords and management systems
• Ensure A+A is secure, not a false sense of security (CAPTCHA?)
• Don’t rely on fields that are easily spoofed (referrer field)
• Re-authenticate users for sensitive actions (i.e. funds transfer)



• Session Management

• Used to manage authenticated users, no need to re-auth
• You need to 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 (i.e. SSL/TLS!)
• Issue a new value for sensitive actions (i.e. funds transfer)



• Secure Communications

• Protect data (i.e. CC no, passwords, sessionID’s) in transit
• As with all crypto, don’t create your own
• Don’t use broken protection mechanisms (i.e. SSLv2)
• Don’t just use SSL/TLS for logon pages, protect the session!
• Try to avoid mixing secure and insecure traffic on a page



• Secure Storage

• Protect data (i.e. CC no, passwords, sessionID’s) when stored
• As with all crypto, don’t create your own
• Don’t use broken protection mechanisms (i.e. DES)
• Don’t store data in places where you can’t confidently secure it
• Strong protection mechanisms, how strong should it be?
• Store, rotate and destroy encryption keys securely


Demo 4

• Lack of secure storage

• Passwords hashed and stored insecurely in Flat File Logon
• Credit to ViRuSMaN, February 2010


Admin password hash - no salt


Admin password hash - salted



• 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 of the web root
• Securely harden servers including filesystem ACL’s


Demo 5

• Lack of secure resource access

• Local file include vulnerability in Bit Weaver 2.7
• Credit to John Leitch, July 2010



• Auditing and Logging

• Logs will be created by your application for many events
• These logs must not contain sensitive data (i.e. CC numbers)
• They must contain sufficient information for auditing purposes
• Logs should be sent to a central server and not locally stored
• If possible the logs should be stored “read only”
• Retain logs for as long as required by laws/regulatory standards


But I need to prevent vulnerability "X"


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"

• Build security into the code, don’t try to bolt it on at
the end


The principles approach is working

• Private banking development company, Switzerland
• Application Security lead saw the secure development principles
• Re-designed secure development training for his company
• Security training costs down, quicker "spin up" of developers
• Security within their SDLC now based on the principles
• In his own words:
You released the "secure development principles" at a time I had issues with
my dev teams in how to teach them secure development. Your approach
convinced me to look in another direction, not trying to teach every
vulnerability but finding the basic principles that help prevent their
existence. At that time, this was genius for me: most of my training since
has been inspired by your secure development principles.


The new approach is working

They modified the principles matrix to match their own terminology


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
• Implemented principles based training with .NET examples
• CISO has now implemented this approach company wide
• In his own words:
I have given a training in the past but I think I gave too much details about
example vulnerabilities such a XSS, SQL Injection, etc... While I think it
educated the developers about vulnerabilities I don't think they
changed how they code. My goal this time was to simplify. The plan is to
give the basics such as the principles and then since we are a .NET shop I
would give some example slides of how to do things in .NET.


The new approach is working

• They use .NET code examples for each principle
Input Validation
<form id="WebForm" method="post" runat="server">
<asp:TextBox id="txtName" runat="server"></asp:TextBox>
<asp:RegularExpressionValidator id="nameRegex" runat="server"
ControlToValidate="txtName"
ValidationExpression="^[a-zA-Z'.s]{1,40}$"
ErrorMessage="Invalid name">
</asp:regularexpressionvalidator>
</form>
Output Validation
Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));


Evolution, not revolution

• Don’t make things more difficult than they need to be

• This isn’t a new wheel, its just a smoother, easier to use wheel
• Don’t treat security as something separate, integrate it
• By integrating security fully a security bug is just another bug
• Secure development doesn’t have to be hard, KISS it!


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?


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 and 4th Videos – Validation and Error Handling


Talk is cheap......

• What am I doing to promote this approach?

• Producing more principles of secure development documentation
• Helping companies who have adopted this approach
• The Security Ninja security code review tool


Security Ninja security code review tool

• A tool based on the principles for code reviews

• Tool for performing security code reviews based on the principles


Security Ninja security code review tool

• A tool based on the principles for code reviews

• Tool for performing security code reviews based on the principles
• First version will be released soon
• It will be free for anyone to download and use
• See me today if you want a demo or a play with the tool!


QUESTIONS?
www.securityninja.co.uk
@securityninja


Injecting simplicity not SQL BSides Las Vegas 2010

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (8)

Similaire à Injecting simplicity not SQL BSides Las Vegas 2010

Similaire à Injecting simplicity not SQL BSides Las Vegas 2010 (20)

Plus de Security Ninja

Plus de Security Ninja (10)

Dernier

Dernier (20)

Injecting simplicity not SQL BSides Las Vegas 2010