Injecting simplicity not SQL RSA Europe 2010

Injectingof Presentation Title simplicity notSQLDavid RookRealex PaymentsSession ID: AND-103Session Classification: Intermediate

Agenda It is broken so lets fix it The current approachThe Principles of Secure DevelopmentThe principles approach is working 2

It is broken so lets fix it 3

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

It is broken so lets fix itSource: http://www.cvedetails.com 5

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

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

It is broken so lets fix itSource: http://www.webappsec.org/ 8

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

The current approach 10

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

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

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

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

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 ProgramURL 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 ResourceInsufficient Transport Layer Protection Failure to Preserve OS Command StructureInsufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory Improper Access Control Insufficient Authentication Insecure Cryptographic StorageSQL Injection Race Condition Use of Hard-coded Credentials Session Management Insecure Direct Object Reference Improper Validation of Array IndexInformation Exposure Through an Error Message Unvalidated Redirects and ForwardsPredictable Resource Location Abuse of Functionality Failure to Restrict URL Access Download of Code Without Integrity CheckBuffer 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

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

Philosophical Application SecurityGive a man a fish and you feed him for a day, teach him tofish 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 preventit, teach him how to develop securely and he will preventmany vulnerabilities 17

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 doesnt need to guess anymore• Common vulnerabilities prevented in applications• Realistic or just a caffeine fueled dream? 18

The Principles of Secure Development 19

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 ProgramURL 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 ResourceInsufficient Transport Layer Protection Failure to Preserve OS Command Structure AuthorisationInsufficient Authorisation Improper Limitation of a Pathname to a Restricted Directory Session Management Improper Access Control Insufficient Authentication Insecure Cryptographic StorageSQL Injection Race Condition Use of Hard-coded Credentials Secure Storage Insecure Direct Object Reference Improper Validation of Array Index Error HandlingInformation Exposure Through an Error Message Unvalidated Redirects and ForwardsPredictable Resource Location Abuse of Functionality Failure to Restrict URL Access Download of Code Without Integrity CheckBuffer 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

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

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

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

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 datas destination • Use whitelist validation for data returned by the app • Not just about encoding, think credit card numbers etc 25

Two simple examples• HTML EncodingResponse.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

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

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

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

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

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

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

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 salt39

Admin password - salted40

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

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

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

But I need to prevent vulnerability “X” Specific vulnerabilities for each principle OWASP White Hat Security SANSInput 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 SizeOutput Validation Cross Site Scripting Cross Site Scripting Failure to Preserve Web Page StructureError Handling Information Leakage Information Exposure Through an Error Message, Improper Check for Unusual or Exceptional ConditionsAuthentication Broken Authentication and Session Insufficient Authorisation, Insufficient Use of Hard-coded Credentials, Incorrectand 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 ControlSession Broken Authentication and Session Cross Site Request Forgery Cross Site Request ForgeryManagement Management, Cross Site Request ForgerySecure Insufficient Transport Layer Protection Use of a Broken or Risky CryptographicCommunications Algorithm, Missing Encryption of Sensitive DataSecure Storage Insecure Cryptographic Storage Use of a Broken or Risky Cryptographic Algorithm, Missing Encryption of Sensitive DataSecure Resource Insecure Direct Object Reference, Failure to Predictable Resource Location Improper Limitation of a Pathname to aAccess 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

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

The principles approach is working 48

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

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

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?• Follow me, visit my websites and ask questions :)• Security Ninja, myself and my security colleagues www.securityninja.co.uk @securityninja 60

Injecting simplicity not SQL RSA Europe 2010

by Security Ninja

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Injecting simplicity not SQL RSA Europe 2010 Presentation Transcript