SoftwareSecurity2012/Group 7/Reflection

For this project, we divided the workload of between the members of our group. We divided the total verification requirements listed in the ASVS document and each of us tried to provide a verdict on the requirements that were given to us, based on our analysis.

For the automatic verification portion of this project (Level 1B), we used Virtual machines and installed all the required tools as prescribed in the assignment. We started playing around with the tools and slowly began to understand the output provided by them. After looking at the requirements listed for Access Control in the ASVS document, we realized that the output produced by all the tools was mostly useless for our purpose. We would like to mention here that we thought that the output produced by RIPS was comparatively more relevant to security vulnerabilities as compared to other tools. However, even RIPS did not help us much regarding our analysis of Access Control related verification requirements. (Erik:Good point. I would go a bit further, and say that the level 1B requirement for V4.1 in a AVSVis a bit silly, as I don't see how any automated soruce code scanner could check this.)

We felt the need for additional documentation of the FluxBB project and used the tool Doxygen for this purpose. It proved to be quite useful as it displayed all the files and functions in an organized fashion which we could use to understand the code. We also used it to produce Class Diagrams for different functions which helped us to understand the links between different parts of the code. This greatly aided our manual code review process.

Some of the OWASP verification requirements like V4.9, V4.11, V4.13 were difficult for us. It was hard for us to understand what was required to provide a verdict on these requirements one way or the other. We found that it is sometimes difficult to interpret some of the requirements, in the context of the application at hand, as most of these requirements seem to be quite generic (as they are written to cover as many types of applications as possible). For example, V4.11 asks to verify whether all the access control rules are forced on the server side whereas V4.9 asks to check whether the same access control rules implied by the presentation layer are enforced on the server side. To us, it seems that V4.9 is the subset of V4.11. (Yes, V4.9 is a bit vague...)

Overall, we thought that the project was quite challenging, especially as access control checks are quite difficult to find and hence the verification requirements were somewhat difficult to prove. We tried to test the requirements to the best of our ability and we have made a conscious effort to display relevant code (wherever possible) from the application on the page which contains our Verdict on the Security Requirements to help the reader understand our findings better.

We acknowledge that for a verification requirement to fail, we only have to show one occasion where a rule is broken or violated. On the other hand, for a requirement to be passed, we ought to check the entire code (if critical pieces of code cannot be identified) and check all possible situations and traces and only then classify it as a pass. This proved to be the most challenging aspect of this project as access control checks are literally spread throughout the code. We justify a "pass" verdict with respect to the files we checked . We have tried to list the files we checked for a particular verification requirement and also try to mention the motivation behind choosing those files.

We hope that we have provided a complete review of the access control aspect of FluxBB and hope that our effort contributes to better and more secure releases of FluxBB in the future.

(Erik: I know you struggled a bit with the - admittedly vague - notions of eg. "protected functions" and "services" in V4.1 and V4.6, which might have been something to mention in your reflection here.)