CSC 2045 Week 04 Code Review PDF

CSC 2045 CODE REVIEW  OBJECTIVES AGENDA: WEEK 04 1. Vulnerabilities in Software Conduct thorough analysis of 2. Teaching Code Review source code using various tools and techniques...

CSC 2045 CODE REVIEW  OBJECTIVES AGENDA: WEEK 04 1. Vulnerabilities in Software Conduct thorough analysis of 2. Teaching Code Review source code using various tools and techniques 3. Introduction to Code Review 4. Benefits of Code Review Describe the purpose and 5. Code Review Preparation process of a code review 6. Code Review Considerations Describe common security 7. What to prioritize issues that result in 8. What to look for and giving vulnerabilities in the course feedback programming language. 9. Best Practices for Code Describe the purpose and Review process of a code review 10. Testing and Assert 11. Example: Zune Infinite Loop VULNERABILITIES IN SOFTWARE 1. Bugs Problem introduced during software implementation Can be easily discovered and corrected Buffer overflows, race conditions, unsafe system calls, incorrect validation 2. Flaws Problem at a much deeper level More subtle Originated from its design and being instantiated in code compartmentalization problems in design, error-handling problems, and broken or illogical access control TEACHING CODE REVIEW Read the article: o https://www.eduflow.com/blog/teaching-code-review-to- university-students What is your top take-a-away from the article? INTRODUCTION CODE REVIEW Inspection of source code from people who aren’t the author of the code. o Goal: Identify coding defects for later removal. Read the article from OWASP: o https://wiki.owasp.org/index.php/Code_Review_Introduction BENEFITS OF CODE REVIEW Find defects sooner in the lifecycle. o IBM finds 82% of defects before testing. Find defects with less effort than testing. o IBM—rev: 3.5 hrs/defect, test: 15-25 hrs/defect. Find different defects than testing. o Can identify design and requirements problems too. Educate developers about security bugs. o Developers frequently make the same mistakes. CODE REVIEW PREPARATION Read the OWASP article: o https://wiki.owasp.org/index.php/Code_Review_Preparation 1. Laying the Groundwork 2. Before We Start 3. Discovery: Gathering the Information 4. Context, Context, Context 5. The Checklist CODE REVIEW CONSIDERATIONS Tips: Problems: 1. Know your limits. 1. Requires substantial expertise in o Typical review speed area of programming and is 150-200 security to be effective.​ lines/hour. 2. Human readers are fallible and 2. Know what bugs to look will miss mistakes.​ for. 3. Code reviews are o Checklists slow. Unreviewed legacy code will take time to review.​ o Static analysis tools PRIORITIZING WHAT CODE TO REVIEW Code that is accessible w/o authentication. Code with a history of vulnerabilities. Code that handles sensitive data. Complex code. Code that changes frequently. WHAT TO LOOK FOR & GIVING FEEDBACK Bugs/Potential bugs Unclear, messy code​ o Repetitive code Bad variable/method names​ o Disagreements between Inconsistent indentation​ the code and the spec Convoluted control flow​ o Off-by-one errors Too much on one line (80 o Global variables and other characters preferred!)​ "too-large" scopes Trivial comments​ o Optimistic, Un defensive Variables used for more than programming one purpose​ o magic numbers BEST PRACTICES FOR CODE REVIEW To enhance software security through structured design, code inspection, and peer review of the code Can integrate code review in the software development process. Code reviewers: Meet with developers Determine it the code meets the secure code development criteria Should consider coding standards and code review checklists Inspect code comments, documentation, unit test plans, security requirements TESTING Unit test plans: Should include how to test the code Should demonstrate that the code meets security requirements and design/coding standards to reduce design flaws and implementation bugs Should include a test procedure, inputs, and expected outputs ASSERT OR NOT TO ASSERT (CPLUSPLUS) The assert macro is for debugging and prints an error and aborts the program. The assert macro is designed to capture programming errors, NOT user or run-time errors, since it is generally disabled after a program exits its debugging phase. Your member functions should NOT use assert as a means to validate user interaction with your class. Instead have your functions return bool true if valid and false if not valid EXAMPLE ZUNE INFINITE LOOP 12/31/08 year = 1980; while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } } else { days -= 365; year += 1; } }