Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote
Plynt Blog

Ten Questions to Ask Before You Jump into Code Reviews

by Priya Gangwani  | 07 Sep 2011

Someone once said to me, ‘We need to ask a million questions to understand the application!’, and that had me come up with a short list of ten questions (yeah, you heard it right!) that a code reviewer can ask to get a hang of the application’s context.

Do I hear you ask, ‘what is a context’? Context, in this sense, is the functionality of the application being reviewed. Suggesting military standard security mechanisms for an e-book application would be useless. Understanding the context of an application gives an overall idea of the impact to the company if its data is compromised. This is what defines security. 

As the OWASP Code Review guide rightly says, ‘Context is the “Holy Grail” of secure code inspection and risk assessment’. Code review is not just about reviewing code. It’s also about ensuring that the code protects the assets and confidential data that the application is entrusted with. If one understands the business correctly, then creating a threat profile and other things that follow is merely child’s play!

You may have your own set of questions, but listed below are the ten questions that should find a place in your ‘Ask the developer’ checklist.

  1. What is the purpose of the application? From what the application does to how the business benefits from it as well as the nature of the application (small business marketing software or enterprise-level applications), examining every aspect provides a new perspective. All these perspectives go a long way in defining security for a particular application.
  2. Who are its real users? Are they internal or external users? If both, are they authenticated differently? This question refers to the intended users of the application. Also, it should address the kind of users they are i.e. if they are human & technically efficient as well (the more crazy it gets, the merrier it is for us).
    Also, one often sees that if an application is meant for internal users, security is often not considered very critical. Paradoxically, most hacking attempts occur from within an organization. The idea behind such questions is to figure out the differences between these users from a security standpoint and how they are authenticated in the application. Do they use AD or LDAP to authenticate internal and external users? Does the application distinguish between internal and external users?
  3. What should be considered ‘CONFIDENTIAL’ data/assets in the application? This is most critical to security and therefore knowing the answer to this would help assess the right risk to the application. What is the impact if the information is compromised in any way?
  4. What are the different environments in which the application is deployed? Is the code given for review in the same manner as the one deployed in production? Usually, an application is deployed in the test environment along with the production environment. It is always good to know how it is deployed and if there is any difference between the various environments. The difference might be with regard to integration with other applications, presence of a web application firewall, etc. Another critical thing to be confirmed is the authenticity of the code shared for review. Is the code base complete and same as that deployed in production? One often comes across developers who don’t share configuration files, property files and the like, thinking that these might not be required to assess the security of the application.
  5. How important is this application to the enterprise? This question may seem irrelevant but it is not so. Given this perspective, the reviewer will be in a better place to suggest mitigation techniques and counter measures to the vulnerabilities identified during code review. The cost of preparation if any and the business impact derived by the exploitation of the vulnerability are two key factors that should be kept in mind before suggesting solutions. Now, you do want them to implement your suggestions and fix their application, don’t you?
  6. Is the application integrated with other applications in the company? Is the data coming from somewhere and/or going somewhere? It is critical to understand how the application interacts with external entities. Another critical understanding would be to identify trust levels that represent access rights granted by the application to external entities like web services. A trust boundary exists when a user accesses or enters data into the application, and also when an application interacts with the database.
  7. What are the entry points and exit points in this application? Entry and exit points define a trust boundary. This knowledge allows the reviewer to assess attack surfaces & come with possible threats to the application. Entry points, for example, can be:
    • Browser input
    • Cookies
    • Property files
    • External processes
    • Data feeds
    • Service responses
    • Flat files
    • Command line parameters
    • Environment variables
    Exit points, for example, can be:
    • The Search page that writes the client’s search string and its corresponding results.
    • Error Page
    • Information Page
  8. Are audit trails and logs pertaining to the application maintained somewhere? Audit trails and logs are a form of documentation, which help in reviewing various activities undertaken by various users. These can provide a means to accomplish several security-related objectives, including individual accountability, reconstruction of events (actions that occur on the computer system), intrusion detection, and problem analysis as well as evidence of the correct processing regimes within a system.
  9. Are there any security measures in place? ‘Is there something that really needs to be secured apart from ensuring that the right users access the right data?’, ‘Does the application prevent external attacks like the submission of special characters to the application’, ‘Is the application protecting the right kind of data in the right manner?’, ‘Are there roles and privileges, which define what portion of data is accessible to which user?’, ‘What operations should an authorized user be able to perform on the data?’ and ‘Is the application defensive against attacks?’ are some of the questions that are answered here!
  10. What is the architecture of the application? This should leave the reviewer with a good knowledge of the key technologies used, application frameworks, servers (database server, web server, etc.), application tiers, software used (along with the version number), and type of application (data-intensive application, service-oriented application, etc.). Gathering maximum information about the operational environment of the applications helps in assessing the right security risks. Developers should share DFDs, Use Case diagrams, Process View diagrams and others of the same kind to enable better testing.

Last but not the least, make sure that some developers are always available in case you get lost in the maze!


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.

                                                                           
 
Movable Type Appliance - Powered by TurnKey Linux