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.Related posts
- 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.Add yours.closed for this post.
- June 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- January 2008
- December 2007
- November 2007
- April 2007
- March 2007
- February 2007
- January 2007
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
You can read full entries of Palisade Blog using an RSS reader. Use this link —