SoftwareSecurity2012/Group 11/Reflection

Reflection

What is your experience using the ASVS and the whole approach that it suggests to tackling "security verification" of web-applications? It is any use? Are things that could/should be improved?

The OWASP Application Security Verification Standard provides a list of requirements into different levels for web-application security assessments. When it comes to deal with security vulnerabilities in a web-application, it is never easy to find out what to focus on in order to check the program, even for people who actually know about such assessments. With OWASP ASVS, the requirements give a useful basis that is a really good guide and make the security issues more clear.

Therefore, this assignment was interesting and gave us another aspect of security issues. However, even though the requirements are well structured, it is not always easy to figure out what it is actually about and what it could relate to in the code itself. That is why it maybe should also provide some examples for the tricky requirements. Moreover, OWASP ASVS encourages the use of tools like we did but they have to be adapted and configured for the tested application. This is also the reason why our tasks with this standard and the tools were not always easy to perform since the results are often hard to analyze.

Another problem that we ran into was that some requirements cannot really be tracked with such tools because they call upon human logic like it is the case for Access Control. Indeed, access control issues are up to the developer, whether he wants to allow a particular user to access a function or not. Obviously, the code analyzer is not able to verify the developer’s choices.

Finally, in this project, the main use was to learn more about security vulnerabilities through this standard. But obviously, those assessments are clearly more interesting and relevant when it deals with your own application. It is therefore easier to track false positives and actual errors since it has been developed by yourself. (Erik:Ideally, we would let every group first build and then analyse their own web app, but there is not really time for this :-). I do think that reviewing other's people code (or your own code, a long time after you wrote it), though it can be frustating, it is that is really makes you realise the sort of documentation you'd like to have, and information on security-relevant design decisions that would be extremely useful to have, and which you now painfully have to figure out from the code.)

To conclude, the OWAPS ASVS was quite efficient for our requirements, even if lots of manual verifications have been required (specially for Access Control as explained above). Then, we think that this standard could rather be useful when we have to deal with customers. Indeed, it is good thing to show when the client doesn’t know anything about web-application security. It could help to determine the security level of the application but also guide the development to a certain level.

Does it make sense to split the work by having different (groups of) people looking at different requirements?

Splitting the requirements into different groups obviously leads to pros and cons. First of all, the requirements are quite numerous (at least in level 2B) and it is a lot of work for a student to deal with each of them. Moreover, several requirements won’t have anything to do with others and will deal with different pieces of code (like Cryptography and Malicious Code Search). Therefore, dividing the work for such requirements turns out quite efficient. However, knowing that a lot of groups are working on different things, it could be a problem to not be able to compare our work and results. Groups have different way to work and to deal with security issues; therefore, merging the results would have turned out efficient.

To conclude, splitting the requirements was a good thing for this assignment but if the goal was to completely correct the code, it is important to be careful that different groups won’t change the same part of the program.

What could or should developers do to facilitate a security assessment?

A program is still easy to understand when it is split into different files and functions. Moreover, it is important that the developer adds a lot of comments into his code, explaining the choices he made and the tricks he used in order to ensure the security of the application. Some annotations could also be written in order to help the verification tools to tackle security issues.

Will this experience change the way you’ll develop web-apps in the future?

In our group, few people are actually web developers and we think that OWASP ASVS could be very interesting for future web-apps. Indeed, it is not always easy to deal with security issues, especially if the application won’t be used by thousands of users. The ASC standard gives good advices and guides to get rid of such issues (choosing a level). However, our experience working on this assignment leads us to think that it will be much more efficient to assess the program while it is being developed and not after. It is even more preferable to start thinking about security early in the software cycle. This way, it is easier to spot the software security bugs and it should also save a lot of time than fixing the code later on.

Conclusion

To conclude about the whole assignment, we all learnt a lot about security issues thanks to the several tools we used and the OWASP ASVS that gives a good overview of that. However, we think that this "method" would be more efficient if it is processed upstream and if the requirements are assessed in the web-app development cycle, knowing a desired security level.

In order to fill the contract, we first divided the work according to the different tools we wanted to test and then, the requirements have been split amongst our group members in order to deal with the code review. We had several meetings on Skype and at the university (average weekly) with the object of reporting our results, organize the wiki filling and talk about the work coming.