How we do PCI Code Reviews

Sachin wrote about the PCI requirement for code reviews some months ago. Today, I want to discuss how we do those code reviews.

Let’s take a fictitious e-Commerce application as an example, and walk through the steps. In the process I’ll also try and answer some of the most common questions clients have about PCI code reviews.

The first step in a code review is preparing the Threat Profile.

Regular readers will remember the Threat Profile - it’s the collection of all threats to an application. A “Threat” is the goal of an adversary - it’s what he wants to achieve. We are putting ourselves in the shoes of the adversary and thinking about his goals. [For more on Threat Profiles, check out “Why We Love Threat Profiles”.

For an eCommerce applicaton, the Threat Profile might start off like this:

An adversary wants to…

• … view the shopping carts of other users
• … steal the credit cards of other users
• … change the price of products in the catalog
• … change the shipping address of another user’s order
• … deny access to other users

Our Threat Profile Repository for PCI related applications helps us prepare the threat profile quickly. Once we prepare the threat profile, we bounce it off with the client to get her feedback. Have we missed something? Have we over-emphasized a threat? That helps us finalize the threat profile.

Next, we study the code layout - first the high level blocks, then the classes, the pages and the interfaces with other applications. We are trying to get a feel of “what happens where” in the code. Remember that we will not be reading every line of code in your application - that’s ineffcient and not needed either. But we do need to get a feel of where the acton happens.

After that high level understanding, we prepare the code review plan.

The code review plan first maps each threat in the threat profile to the relevant classes and pages. Then for each of them, we specify the type of check we will do. For instance, consider the threat “An adversary wants to view the shopping carts of other users”. The relevant elements for this threat might be the class that processes shopping cart details, and the pages that request and display the shopping cart contents. What are the relevant checks? In the class that processes shopping cart details, we check (1) if it verifies that the cart requested belongs to the user, (2) if it resists a SQL Injection attack expanding the range of the SQL query, etc. Similarly, we prepare the code review plan for each of the threats.

The code review plan is conceptually similar to the Test plan we use in our penetration tests; it’s just closer to the code level now, though.

The code review plan is reviewed by a senior and then finalized. The detailed code review is next. The detailed review uses a combination of manual inspection and tool-assisted inspection. Some weaknesses like SQL Injection and Cross Site Scripting can be found efficiently with automated scanning tools. Other weaknesses related to insufficient enforcement of business logic can be found with manual inspection.

The code reviewer adheres to the code review plan, and revises it during the project when we get new ideas. As the code review progresses, he ticks off the checks to ensure we don’t miss anything.

Once the detailed review is complete, we prepare the report. The Executive Summary of the report captures the strengths and weaknesses. The detailed findings section describes each finding - the impact, how it can be exploited, the complexity and the solution. We also show the insecure code that causes the vulnerability.

• How to get the best results from your code review
• How we use automated scanners in code reviews
• How code-reviews benefit from sample test setups

Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.