Secure code review: A practice to enhance user experience by protecting user from attack

Introduction

Laymen explanation

If you are writing a mobile app, then you will be concerned about user experience. What will you do for user experience? A easy to look and use app will be your desire. Isn't it? You are right. Now I will ask will security is considered as part of user experience? You may ask how come security be part of user experience? I will tell the story of a user whose account is hacked because of insecure software which he was using.

This document talks in this respect.

Technical explanation

Security code review is the process of auditing the source code for an application to verify that the proper security controls are present, that they work as intended, and that they have been invoked in all the right places. Code review is a way of ensuring that the application has been developed so as to be “self-defending” in its given environment.

Code review is probably the single-most effective technique for identifying security flaws. When used together with automated tools and manual penetration testing, code review can significantly increase the cost effectiveness of an application security verification effort.

Purpose of secure code reviews

A secure code review serves to detect all the inconsistencies that weren’t found in other types of security testing – and to ensure the application’s logic and business code is sound. Reviews can be done via both manual and automated methods.

Security area covered

Code reviews focus on finding flaws in each of the following areas:

• Authentication,

• authorization,

• security configuration,

• session management,

• logging,

• data validation,

• error handling, and

• encryption

Stages of secure code review

Identify code review objectives

In this stage, reviewer understands the code environment and scope of review. Below is the list of criteria

• Code: The language(s) used, the features and issues of that language from a security perspective. The issues one needs to look out for and best practices from a security and performance perspective.

• Context: The working of the application being reviewed. All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be over-kill, and out of context. What type of data is being manipulated or processed and what would the damage to the company be if this data was compromised. Context is the “Holy Grail” of secure code inspection and risk assessment…we’ll see more later.

• Audience: The intended users of the application, is it externally facing or internal to “trusted” users. Does this application talk to other entities (machines/services)? Do humans use this application?

• Importance: The availability of the application is also important. Shall the enterprise be affected in any great way if the application is “bounced” or shut down for a significant or insignificant amount of time?

Perform review

Below 3 items are repeated for multiple iterations

• Perform preliminary analysis

• Identify common vulnerabilities

• Identify vulnerabilities applicable for the code environment

Best practices

• Produce code review checklists to ensure consistency between reviews and by different developers

• Ensure a positive security culture by not singling out developers

• Review code each time a meaningful change in the code has been introduced. Don't wait till the release time

• A mix of human review and tool use is best to detect all flaws

• Continuously monitor and track patterns of insecure code

Selection criteria to decide on static analysis tool

• • Requirement: Must support your programming language, but not usually a key factor once it does.

  • Types of vulnerabilities it can detect (out of the OWASP Top Ten?) (plus more?)

  • How accurate is it? False Positive/False Negative rates?

    • • Does the tool have an OWASP Benchmark score?

  • Does it understand the libraries/frameworks you use?

  • Does it require a fully buildable set of source?

  • Can it run against binaries instead of source?

  • Can it be integrated into the developer's IDE?

  • How hard is it to setup/use?

  • Can it be run continuously and automatically?

  • License cost for the tool.

Reference

https://www.owasp.org/index.php/Code_Review_Introduction

https://www.checkmarx.com/2016/02/05/5-best-practices-perfect-secure-code-review/

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

https://www.slideshare.net/MaureenR/how-to-conduct-a-security-code-review