Injecting simplicity not SQL RSA Europe 2010

Title of Presentation

David RookRealex Payments

Session ID: AND-103Session Classification: Intermediate

Injecting simplicity not SQL

Agenda

It is broken so lets fix it

The current approach

The Principles of Secure Development

The principles approach is working

2


3


• 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

Source: http://www.cvedetails.com

5



• 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


• 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


Source: http://www.webappsec.org /

8


• 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

The current approach

10

The current approachAnd 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


• 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

• 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


• Many lists of vulnerabilities• OWASP Top 10• White Hat Security Top 10• SANS Top 25• Others??

14


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 StorageSQL 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 Check

Information Exposure Through an Error Message

Reliance on Untrusted Inputs in a Security Decision

Use of Hard-coded Credentials

Buffer Access with Incorrect Length ValueImproper 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

15


• 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

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


• 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


19


Cross Site ScriptingInjection Flaws

Security Misconfiguration

Information Leakage

Race Condition

Broken Authentication

Cross Site Request Forgery

Buffer Copy without Checking Size on Input

Insecure Direct Object Reference

Failure to Restrict URL Access

Insecure Cryptographic StorageSQL 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 Check

Information Exposure Through an Error Message

Reliance on Untrusted Inputs in a Security Decision

Use of Hard-coded Credentials

Buffer Access with Incorrect Length ValueImproper 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


Secure Communications

Input Validation

Session Management

Error Handling

Secure Storage

AuthenticationSecure Resource Access

Authorisation

Auditing and Logging

Output Validation

20


• 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

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.replaceAl l(" ' ", strreplace);System.out.println(result);}

}

22

Demo 1

• Lack of input validation• SQLi in FreeRealty used to bypass authentication• Credit to Sid3^effects, April 2010

23

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


• 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

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

Demo 2

• Lack of output validation• Stored XSS in DBHcms used to steal user cookies• Credit to ITSecTeam, May 2010

27

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


• 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

Demo 3

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

30

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

3232


• 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


• 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


• 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


• 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

Demo 4

• Lack of secure storage• Passwords stored insecurely in Flat File Logon• Credit to ViRuSMaN, February 2010

37

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

Admin password - no salt

39

Admin password - salted

40


• 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

Demo 5

• Lack of secure resource access• Local file include vulnerability in Bit Weaver 2.7• Credit to John Leitch, July 2010

42

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

4444


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

46

Specific vulnerabilities for each principle

OWASP White Hat Security SANS

Input Validation Injection, Cross Site Scripting, Security Misconfiguration, Unvalidated Redirects and Forwards

Cross Site Scripting, SQL Injection, Content Spoofing

Unrestricted Upload of File with Dangerous Type, Failure to Preserve SQL Query 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 SizeOutput 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 and Authorisation

Broken Authentication and Session Management, Security Misconfiguration, Unvalidated Redirects and Forwards

Insufficient Authorisation, Insufficient Authentication, Abuse of Functionality

Use of Hard-coded Credentials, Incorrect Permission Assignment for Critical Resource, Reliance on Untrusted Inputs in a Security Decision, Missing Authentication for Critical Function, Improper Access Control

Session Management

Broken Authentication and Session Management, Cross Site Request Forgery

Cross Site Request Forgery Cross Site Request Forgery

Secure Communications

Insufficient Transport Layer Protection Use of a Broken or Risky Cryptographic 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 Access

Insecure Direct Object Reference, Failure to Restrict URL Access, Security Misconfiguration, Unvalidated Redirects and Forwards

Predictable Resource Location Improper Limitation of a Pathname to a Restricted Directory, Improper Control of Filename for Include/Require Statement in PHP Program, Allocation of Resource Without Limits or Throttling

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


48


• 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


• 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

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

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

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

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

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

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

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

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

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

Questions?

www.securityninja.co.uk

@securityninja

• Follow me, visit my websites and ask questions :)

• Security Ninja, myself and my security colleagues

60

Date post:	24-Dec-2014
Category:	Technology
Upload:	security-ninja
View:	519 times
Download:	5 times

Injecting simplicity not SQL RSA Europe 2010

Technology