SoftwareSecurity2014/Group 4/Reflection

Open Web Application Security Project - Application Security Verification Standard Project

• What difficulties did you encounter, either with the code or the ASVS? Can you think of ways to reduce or avoid these difficulties?
  • Mibew contains php files with the same names in different folders with different functionality. We think that it was intentionally structured that way to make the code flow easier to track. However, they do not have proper notations/ documentation in any of the file. At the beginning of Level 2B, it took us some time to figure out roughly the function of each file. To make sure that nothing is missed, we checked all the files manually for the requirement. We splitted the work by checking the vulnerable functions throughout the whole code. We also checked every warnings that given by Fortify for input validation. But it turned out to be a good way, since we made a well connection with the code, Fortify and ASVS. (Erik: This last sentence is a bit cryptic - not so clear what you mean by this good connection.)

• Could the ASVS be clearer, more complete, or structured in a better way?
  • ASVS should come with a better explanation regarding each requirements. Since in the beginning we were quite struggling in understanding what is each requirements lead into. Maybe by giving short explanation and an example of every requirements might be useful for further review.

• Is splitting up the work as we did,with different groups looking at different security requirement, a sensible way to split the work? Or are there more practical ways?
  • Splitting the works and digging into one requirement is more efficient in the matter of time consumed. It is also a good way for each group to have a thoroughly understanding of that specific requirement. Since the application consists of lots of code, it’s still enough workload for a group to focus on only one. And although the requirements are different with each other, that we might have lost the opportunity to take a look at the others. Still, the way of checking and work sequence can be similar, thus it’s a good way to practice.

• What could or should developers do to facilitate a security assessment? Do you think that experiencing security from the perspective of a reviewer rather than a developer has changed the way you would design or implement a web application yourself?
  • The developers should have some basic knowledge regarding the software security, e.g having a knowledge about sanitizing every input, such as whitelisting and blacklisting. The developer also need to provide the code with a proper documentation that explain the logic flow of the program execution and also some explanation about the use of the functions. The developer also need to work with the security assessor and having the perspective of the security assessor.
  • After having the experience from the perspective of a reviewer, it definitely changed the way of designing a web application ourselves. After evaluating security requirement for Mibew, we have a better understanding of the importance of security for an application. Even bigger apps could be vulnerable to different kinds of attacks. Trying to guarding against them and protecting the privacy of users have became more important nowadays. As a developer, we do not only need to make the app function perfectly, but we also should try the best to secure it from attackers.

• Any other interesting, frustating, boring, educational, etc. aspects of the whole experience.
  • In general, we think that this experiment is educational. Since, this is our first time using some code reviewer such as Fortify and RATS. We found that this tools can make the code security checking easier comparing than to do the code checking manually. Most developer would likely to missed some security requirements during coding because they might prioritize the software performance first. By using tools like Fortify, it can help the developer to find some security vulnerability on their code easily. However, we still need to check the warnings and errors that the Fortify gives, since there are also possibilities of false positive and false negative errors. (Erik: Tools like Fortify give a nice way to get started, because it gives some concrete feedback that you can start looking at to begin a security review, but was did the tool REALLY help in the end? Ie are any of the verdicts really based - in part - on its feedback?)
  • We also experience a frustrating moment because mibew, the software that we analyze for our project, didn’t come with a proper documentation of the program architecture. Therefore, we need to find out a better way to check the code in an efficient way but without missing any of the requirements.
  • The most interesting part of this project is that when we really dig into the code and find out what kind of codes that could make some software, or some website, vulnerable. We found out the importance of validating the input because one whole in an user input could lead to several security vulnerablities.
  • We also found that code scanners tools, especially Fortify, and a guidelines like ASVS help us to make the process easier for the verification and security purpose. Most of the times Fortify helped us to focus on the SQL and XSS attacks.