Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

How to conduct a security code review

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

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

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 http://elearning.securityinnovation.com 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