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


http://www.securityninja.co.uk


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


• 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

It is broken so lets fix it


0

1000

2000

3000

4000

5000

6000

7000

2010 2009 2008 2007 2006 2005 2004 2003 2002 2001 2000

CVE'sTotalSQLiXSS


SQLi & XSS = 33.90%SQLi & XSS = 31.65%SQLi & XSS = 29.30%


• CVE statistics only show publicly known vulns


• Only one source, lets look at another one

• 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

Source: http://www.cvedetails.com/vulnerabilities-by-types.phpTuesday, 27 July 2010

• WASC Web Application Security Statistics


• Still a tiny sample size (0.006% of all websites)

• Sanitised data from pen tests, audits etc

• These stats also show a lack of app sec progress

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

• 2008 report has less sites but more vulnerabilities


0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

2008 2007

SitesVulns



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??



Cross Site ScriptingInjection Flaws

Security Misconfiguration

Information Leakage

Race Condition

Broken Authentication

Session Management

Cross Site Request Forgery

Buffer Copy without Checking Size on Input

Insecure Direct Object Reference

Failure to Restrict URL Access

Insecure Cryptographic Storage

SQL Injection

Content Spoofing

Insufficient AuthorisationInsufficient Authentication

Abuse of FunctionalityPredictable Resource Location

Unrestricted Upload of File with Dangerous Type

Failure to Preserve SQL Query StructureFailure to Preserve Web Page Structure

Failure to Preserve OS Command Structure

URL Redirection to Untrusted Site

Insufficient Transport Layer ProtectionImproper Limitation of a Pathname to a Restricted Directory

Improper Control of Filename for Include/Require Statement in PHP Program

Incorrect Permission Assignment for Critical Resource

Download of Code Without Integrity CheckInformation Exposure Through an Error Message

Reliance on Untrusted Inputs in a Security Decision

Use of Hard-coded Credentials

Buffer Access with Incorrect Length Value

Improper Check for Unusual or Exceptional Conditions

Use of a Broken or Risky Cryptographic Algorithm

Missing Encryption of Sensitive Data

Missing Authentication for Critical FunctionInteger Overflow or Wraparound

Improper Validation of Array Index

Incorrect Calculation of Buffer Size

Unvalidated Redirects and Forwards

Allocation of Resource Without Limits or Throttling

Improper Access Control



• 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 listsTuesday, 27 July 2010

Give a man a fish and you feed him for a day, teach him to fish and you feed him for a lifetime.

Philosophical Application Security

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

I want to apply this to secure application development:


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?



Cross Site ScriptingInjection Flaws

Security Misconfiguration

Information Leakage

Race Condition

Broken Authentication

Session Management

Cross Site Request Forgery

Buffer Copy without Checking Size on Input

Insecure Direct Object Reference

Failure to Restrict URL Access

Insecure Cryptographic Storage

SQL Injection

Content Spoofing

Insufficient AuthorisationInsufficient Authentication

Abuse of FunctionalityPredictable Resource Location

Unrestricted Upload of File with Dangerous Type

Failure to Preserve SQL Query StructureFailure to Preserve Web Page Structure

Failure to Preserve OS Command Structure

URL Redirection to Untrusted Site

Insufficient Transport Layer ProtectionImproper Limitation of a Pathname to a Restricted Directory

Improper Control of Filename for Include/Require Statement in PHP Program

Incorrect Permission Assignment for Critical Resource

Download of Code Without Integrity CheckInformation Exposure Through an Error Message

Reliance on Untrusted Inputs in a Security Decision

Use of Hard-coded Credentials

Buffer Access with Incorrect Length Value

Improper Check for Unusual or Exceptional Conditions

Use of a Broken or Risky Cryptographic Algorithm

Missing Encryption of Sensitive Data

Missing Authentication for Critical FunctionInteger Overflow or Wraparound

Improper Validation of Array Index

Incorrect Calculation of Buffer Size

Unvalidated Redirects and Forwards

Allocation of Resource Without Limits or Throttling

Improper Access Control

Input Validation

Output Validation

Error Handling

Authentication

AuthorisationSession Management

Secure Communications

Secure Storage

Secure Resource Access

Auditing and Logging

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


http://www.examplesite.com/home.html?day=

http://www.examplesite.com/home.html?day=

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 10Tuesday, 27 July 2010

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

• 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.

• CISO has now implemented this approach company wide• Implemented principles based training with .NET examples


The new approach is working

Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));

• They use .NET code examples for each principle

Output 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>

Input Validation


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!


www.securityninja.co.uk@securityninja

QUESTIONS?




injecting simplicity not sql bsides las vegas 2010

Technology