SoftwareSecurity2014/Group 6/Reflection

Reflection on the OWASP Project

Division of tasks within the group

For the 1B verification, we worked in the group together. We ran the automated tools and then discussed and looked over the code scanning results in the group. This worked quite well as the discussion brought forth interesting aspects. However, we also divided tasks for some parts of the 1B verification since it would have taken a very long time to look at all the results together.

The level 2B verification was split by verifications (V4.1-V4.14, V9.1-V9.5) and assigned to different group members. This approach has both advantages and disadvantages. Working on the requirements individually means that everyone has to read and understand the complete code. This takes a lot of time, but it also means that more people will have a look at the code and bugs are more likely to be discovered. Also, the different people look at the code with different focus in mind, which is a good thing. On the other hand this means that there is not so much time for discussion of (possible) findings. We tried to mitigate that by going over the results in our final meeting.

Difficulties with the code

Although the documentation is good and the code is well structured, some of us still had problems finding our way through the code. However, this might be due to the fact that Roundcube is written in PHP and a few of us do not have too much experience with the language.

Difficulties with ASVS

• Many requirements are very generic and therefore provided us with some difficulties on how to apply them to Roundcube.
• A few requirements overlap. However, this is a consequence of how the requirements apply to Roundcube.

About the ASVS requirements

• It is a difficult task to specify requirements that can be applied to every web application.
• Requirements need to be generic, but within limits so as not to allow different conflicting interpretations.
• Overlaps are unavoidable when applying the requirements to specific projects. If too much effort is put into not creating any overlaps at all, gaps could be created that lead to the neglection of important aspects.
• A better description of the requirements could be given to facilitate their interpretation. For example, a third party site links ASVS requirements to entries in the OWASP Testing guide, which gives a description on what to look out for. If added to the ASVS document, information of such sort would be of help in the security assessment process. (Erik:Nice find, this blog posting)

General methods to facilitate security assessments

• Use best practices, e.g.
  • Design code to facilitate testing
  • Properly structure code and use design patterns
  • Good documentation with the ASVS requirements in mind, e.g.
    • Provide overview graphs of the application
    • Provide an overview of data flow / code paths
    • Add comments about the ASVS requirements where applicable
• Developers should have knowledge of the ASVS requirements

Lessons learned

• Consider the ASVS requirements in all stages and use them as a guideline.
• Vulnerabilities are not concentrated at one point, but are scattered throughout the entire code base and often emerge through complex interactions taking place in the code.