How to conduct a security code review


Published on

This webcast describes the activities, process and tools that you need to find security problems in your code quickly and effectively.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How to conduct a security code review

  1. 1. About Security Innovation • Application and Data Security Experts Seattle – 10+ years of research on security vulnerabilities – Hundreds of assessments on world‟s most dominant How to Conduct a software, applications and development environments – Solutions for all phases of SDLC: Security Code Review secure design, development, testing and deployment Boston • Products, Services & Training – Training/eLearning on secure coding, security testing, etc. – Application Security Assessment (black and white box) – Encryption for secure data transfer and communications Jason Taylor CTO Security InnovationWhat is a Security Code Review? Why Security Code Review?• Security Engineering Activity • It can find vulnerabilities that are very difficult to discover in testing – Automated and manual inspection of code • It can be performed by your developers or your technical testers – Can start as soon as you begin development • It can be done early in the development process – Can continue through testing and release • It can be performed on every check-in, every build, or some other interval that works for your development process• Focused – Focused on security vulnerabilities • Security code review is one of the most impactful steps you can – Uses a „question list‟ to drive the inspection take toward more secure code – Only review for issues that are relevant to your applicationConducting the Code Review Goals of the Code ReviewMethodology 1. Identify Code Review Iterative Process • Create/Update a list of inspection questions Objectives – What problems are possible in the technology Inputs • e.g. should you be looking for buffer overflows? • Design documentation • Architecture diagram – What problems are possible due to the design? • Data flows • are there threat mitigations already in place? 2. Perform • Usage scenarios Preliminary Scan • Inspection questions • Identify vulnerabilities Outputs – Where in the code • Inspection questions – Under what conditions4. Review for 3. Review for • Prioritized list of problems to fix inUnique Issues Common Issues the code • Document a fix – How can the vulnerability be resolved 1
  2. 2. Tips for an Effective Review Tips for an Effective Review• Set time limits • Set clear objectives – It is easy to get stuck in a code review – Understand what issues you are looking for – Too much time in any one area may diminish returns – Understand patterns of bad code – Time-box your effort so you can move on • Review only for security – Don‟t spread yourself thin, stay focused• Break into manageable chunks – Security focus is proven to be more effective – Would you be more effective reviewing 1MLOC or 1KLOC? • Update your coding standards – Stay focused, finish quickly, find high quality bugs – Identify problems that occur repeatedly• Review iteratively – Add coding standards to address these problems – Continuous review is more effective than big-bang • Identify what‟s out of scope – Review as often as possible and make it routine – Clarify what you will not be looking for, don‟t waste timeConducting the Code Review 1. Identify Code Review ObjectivesOverviewCode Review Steps: • Code review objectives are a set of bug types you‟ll be looking for based upon the code‟s architecture and the identified threats.1. Identify code review objectives – For instance, it is not important to look for SQL injection bugs if your application has no interactions with a database.2. Perform preliminary scan • To determine the objectives, consider the following:3. Review for common security issues – Which threats identified in threat model apply to the code you‟re reviewing?4. Review for security issues unique to – Which common coding errors apply to the code you are reviewing? your application‟s design – What is the scope of your review? • Examples of Code Review Objectives – Ensure all un-trusted input to the component is passed to a validation routine before being used. – Check error handling to ensure exceptions are caught consistently and close to source. – Check cryptographic routines to ensure secrets are cleared quickly.2. Perform Preliminary Scan Static Analysis Tools Strengths and Weaknesses• Use a static analysis tool to grab low hanging fruit • Strengths – Find first set of potential vulnerabilities – Can find many common and KNOWN vulnerabilities fast – Determine hotspots where more bugs may be hiding – Good at finding bugs that are caused by single lines of code and may find bugs that span multiple lines of code in a single function• Perform a preliminary manual scan to uncover hotspots – Good at finding buffer overruns, format string problems, use of – Input and data validation architecture dangerous win32 APIs, memory leaks, etc. – Find code used for authentication and authorization – May find bugs that you miss in the manual scan – Discover code that appears especially complex – Discover code that uses cryptography • Weaknesses – False-positives can lead you on a wild goose chase – Find code that performs interop between managed and native code – Can you give a false sense of security• Goals – Limited in their ability to find bugs that span – First set of bugs multiple functions or components – Hotspots to review more closely 2
  3. 3. 3. Review for Common Issues Focus on Hotspots Hotspots in your code• Use code review objectives developed in step one • Hotspots are areas that were highlighted in your preliminary scan – Checklist or question driven approach works best – Areas of code with many „hits‟ from static analysis• Focus on hotspots – Code that mitigates a known threat – Hotspots discovered in the preliminary scan – Complex code (cyclomatic complexity measures can help) – Common security hotspots such as XSS and SQLi – Etc.• Perform control flow analysis – Review logical conditions • Use this list to focus your effort• Perform data flow analysis – Trace data from input to output – Analyze trust boundariesFocus on Hotspots Focus on HotspotsCommon Hotspots Common Hotspots• SQL Injection • Authorization – Look for un-trusted input that can modify the semantics of a SQL query – Look for permissive database access, privilege escalation, lack of separation • Sensitive Data• Cross-Site Scripting – Look for disclosure of information over the network, in files, code, error messages, memory – Look for user input echoed back as web content • Unsafe Code• Data Access – Look for code that runs at higher privileges, without interpreter protections – Look for plain-text data base connection strings and authentication to the • Hard-coded Secrets database – Look for hard-coded keys, passwords, hashes and salts• Input and Data Validation • Poor Error Handling – Look for poor exception handling, missing error code paths – Look for client-side input validation, black-list techniques• Authentication – Look for weak passwords, credentials sent in clear-text, long or semi- random sessionsFocus on Hotspots Conducting the Code ReviewCommon Hotspots Control Flow Analysis & Data Flow Analysis• Configuration Files  Manually inspect your code by tracing paths through the code that is – Look for sensitive data, connection strings, poorly configured security most likely to contain vulnerabilities features • Dataflow analysis• Cryptography – Trace data from the points of input to the – Look for failure to clear secrets, custom cryptography or improper use of points of output platform APIs – Determine trust level for input• Undocumented Public Interfaces – Look for input validation – Look for test interfaces or other undocumented interfaces that haven‟t received good documentation or test scrutiny • Control flow analysis• Threading Problems – Step through logical conditions in the code – Look for race conditions and deadlocks – Understand the conditions under which each block will execute• Memory Problems – Look for memory leaks and buffer overflows Optimized by the use of Hotspots and Code Review Objectives! 3
  4. 4. Data Flow Analysis Data Flow Analysis Trust Boundaries• Look for input sources • Trust boundary represents a layer between components or – Public interfaces data sources that represent a transition from lower trust to higher trust – User interface – Database • Use trust boundaries to determine how much you trust an input source – Sockets – Files – Pipes• Look for input sinks • The less you trust the source, the more carefully you need to validate – Where does the data exit your application as output? – Where does the data come to rest?Data Flow Analysis Data Flow AnalysisTrust Boundaries Most Common Input Validation Bugs• High Trust • Numeric underflows and overflows – Known to be good, strongly named assemblies or signed/hashed native libraries – A DB that is only used by your component and for which you can prove that all data has been • SQL injection properly validated – Network data that has been signed by a known good source (IPSec or SSL) • Cross Site Scripting • Canonicalization• Medium Trust – Libraries that have not been signed but are local to your server • Native code issues – Public interface that should only be accessible to trusted users – UI that should only be accessible to trusted users • Buffer overflows – Network data that should only be accessible to trusted users • Format strings• Low Trust – Libraries that have not signed and are located on the client – Client code, a file, a public interface or UI that is accessible to any user – Data from a network that is shared with other components or processes – Data from a database that is shared with other components or processesData Flow Analysis Data Flow AnalysisNumeric Underflows and Overflows SQL injectionLook for: a calculation causes a data value to be larger or smaller than its data type Look for: User input can impact logic of a SQL query allows Impact: Malicious user can access or modify data in your SQL databaseImpact: The value wraps to become much larger larger or smaller than its data type allows - cag te Caused when a calculation causes a data value to be or smaller than expectedExample: value to wrap-around and generally become much larger or smaller than expected Example: int[ ] filter(uint len, int[ ] numbers) { The SQL query in code looks like this. uint newLen = len * 3/4; query = “SELECT * FROM USERS WHERE USER_ID = „” + userIdFromWebPage + “‟”; int[] buf = new int[newLen]; Imagine userIdFromWebPage contains “‟ or 1=1 –“, or “‟ ;DROP TABLE users –“, or “‟ ;exec int j = 0; xp_cmdshell(„format c:‟) –“. for (int i = 0; i < len; i++) { The final query could look like this, which will result in a format of the c: drive on DB server if (i % 4 != 0) “select * FROM USERS WHERE USER_ID = „‟ ;exec xp_cmdshell(„format c:‟) –” buf[j++] = numbers[i]; } return buf; } When calculating the value for len, the code first computes len * 3 and then divides by 4. When len is large enough (~1.4 billion), len * 3 overflows and newLen gets assigned too small of a value. The result in this code will be an unhandled IndexOutOfRange exception. 4
  5. 5. Data Flow Analysis Data Flow AnalysisCanonicalization Format StringLook for: There are multiple ways to represent a resource. Validation is performed on one representation and processing is performed on another. Look for: Use of the printf family of functions on user input.Impact: You may get a resource (e.g. URL or File) other than you expected Impact: The printf family of functions will pop the stack as many times as they see “%” in the format string. Sufficient %‟s can traverse the stack, and reach any location in it. Use of %n can allow arbitrary writing of data anywhere within the stack. Example:Examples: void main (int argc, – Use of partial paths may result in a file other than what you expect being loaded. char **argv) – Alternate representation of an IP address such as dotless IP may result in a URL other { than what you expected being loaded. /* Whatever the user said, spit back! */ – Encoded characters such as %20 for space may result in a URL other than what you printf (argv[1]); expected being loaded. }Control Flow Analysis Control Flow Analysis Does the application rely on client side validation? Look for: Application relies upon client-side validation alone• Use Hotspots and Code Review Objectives: Impact: It is easy to modify or bypass client code, malicious input will reach the – Does the application rely on client side validation? server – Are there secrets or critical IP embedded in the code? Example: <html><head> – Is sensitive data being stored in predictable locations (such as temp files), or being <script language=„javascript‟> sent in clear text over the network? function validateAndSubmit(form) – Is cryptography being used? { – Are there undocumented public interfaces? if(form.elments[“path”].value.length() > 0) { – Is the component giving dependencies too much trust? form.submit(); – Is there proper and consistent error checking? } – Do error messages give away too much information? } </script> – Does your application expose sensitive information via user session? <form action=“mypage.asp” method=“post”> – Can write operations be performed with a GET request? <input type=„text‟ id=„path‟/> – Is the code multithreaded? <input type=„button‟ onclick=„validateAndSubmit(this.parent)‟>Submit</input> </form> …Control Flow Analysis Control Flow Analysisare there secrets or critical IP embedded in the code? is sensitive data stored in predictable locations or sent in clear text?Look for: Secrets are hardcoded in the application Look for: Store sensitive information in configuration files or sent over the networkImpact: Code can be decompiled, sensitive IP or hard coded secrets can be unencrypted stolen Impact: Attacker can steal sensitive information.Example:IntPtr tokenHandle = new IntPtr(0); Example:IntPtr dupeTokenHandle = new IntPtr(0); Server password stored in the ASP.NET web.config file:string userName = "joe", domainName = "acmecorp", password="p@Ssw0rd"; <connectionStrings>const int LOGON32_PROVIDER_DEFAULT = 0; <add name="Sales” providerName="System.Data.SqlClient" connectionString= "server=myserver;database=Products;uid=dbUser;pwd=dbPwd" />//This parameter causes LogonUser to create a primary token. </connectionStrings>const int LOGON32_LOGON_INTERACTIVE = 2;const int SecurityImpersonation = 2;tokenHandle = IntPtr.Zero;dupeTokenHandle = IntPtr.Zero;// Call LogonUser to obtain a handle to an access token.bool returnValue = LogonUser(userName, domainName, password,LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,ref tokenHandle); 5
  6. 6. 4. Review for Issues Unique to Your Application‟s Subject Object MatrixDesign• Is there a security architecture implemented in this application? • Are there unique roles in the application? Great location to look for bugs for several reasons: – Look for problems in the code that could allow one role to assume the – It has already been recognized that a security problem exists, that‟s why privileges of another. the custom security code was written in the first place. – Understand what the set of roles and what each role should be allowed to do. – Unlike other areas of the product, a functional bug is very likely to result in a security vulnerability.  Once the matrix has been completed, review the code for contradictions to this matrix. Even a well designed system with clearly defined roles can be broken by a bad assumption or a logical mistake in the implementation.Post Code Review Activities How Security Innovation can Help• Prioritize the bugs found • Source Code Analysis Solutions – prioritization should be based upon the impact the – Static analysis tooling bug will have on your customers – Code review as a service – Think through the maximum damage potential as well as which of your customers will be impacted • TeamMentor Security Knowledge Base• Fix the right set of bugs – Common vulnerabilities – Each bug fixed can introduce a new unknown bug – Checklists – Guidelines for writing secure code – Sometimes the bug you know is less dangerous than the bug you don‟t• Learn from your mistakes • TeamProfessor Security eLearning – Keep a running dialog within your team discussing the mistakes made, – Courses cover secure process, design, development and testing how they were found, how they were fixed. – Strive to write code that comes up clean in a code review the first time! eKnowledge Solutions for Secure Development &Source Code Analysis Solutions Code Review CxDeveloper: Next Generation Static Analysis TeamMentor: Secure Development Guidance System – Accurate: Full analysis of all application paths and variables with a near zero false positive rate – Out of the box secure development standards and best practices (maps to several compliance reqt‟s) – Scalable. 32 & 64 bit architecture for high demand environments – How-to‟s, how not-to‟s, code snippets, attacks, checklists – Extensible. Built in CxQL query language, IDE integrations, low process impact – Targeted, on-demand, context specific application security training – Affordable. Flexible licensing and great price/performance ratio – Lots of content on conducting a code reviewCode Review as a Service Software Security eLearning: – Creating Secure Code – Independent, expert eyes – How to Break Software Security – Can perform deep review or quick, baseline review – Optional remediation assistance – Fundamentals of Application Security – Introduction to Threat Modeling – Buffer/Integer Overflows 6
  7. 7. Appendix Try eLearning for free Free eLearning Course for Attending “Introduction to Threat Modeling” Contact Me Jason Taylor jtaylor@securityinnovation.comInputs - Minimum Inputs – Nice to Have• Architecture diagram • Usage Scenarios – Useful especially if you don‟t already know the architecture – How is the code used, what are the scenarios? – Can be replaced by an architecture conversation, whiteboard, etc. • Use of native code• Data flows – If you are reviewing managed code (Java/.NET) where does it call into native code? – Where are the inputs? • Reference material – How does the data flow between components? – Data schemas – Where is the data output? – API documentation – Where does it come to rest? – User documentation – Threat model 7