SoftwareSecurity2014/Group 11/Reflection

Reflection

Code

Dificulties

What difficulties did you encounter, either with the code or the ASVS? Can you think of ways to reduce or avoid these difficulties?

• There is a lot of difference in the level of knowledge over the language PHP and experience on reviews in general. This makes it harder to do the reviews or even read the code. While others that have a lot of experience on these fields find it perhaps very boring.

• PHP applications are difficult to analyze, as strictly speaking the same code does not always execute the same way on different application servers. So the actual configuration of the PHP interpreter as well as the server would need to be factored in as well. Running Fortify on a Java project gives a better quality report of the code.

• Developing in PHP gives so much flexibility, that it can make it so hard to read the code. Also, the complexity of bigger PHP projects seem to increase exponentially.

(Erik:Good points)

(Erik:It looks like Joomla does use a structured approacj to input validation, even if it is hard to find how and where it does things.)

Solutions

• There is no real solution. You can not be 100% sure that all students know the language.

• Use Java based applications instead of PHP (but this spoils a lot of the fun because there is so much PHP applications available....)

ASVS

Difficulties

What difficulties did you encounter, either with the code or the ASVS? Can you think of ways to reduce or avoid these difficulties?

• ASVS tries to make requirements as concrete as possible. Still, some more explanation as to what each requirement actually stands for would be welcome, so interpretation is more uniform (i.e. the explanation with "Verify that direct object references are protected, such that only authorized objects are accessible to each user." in https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OWASP-AZ-004) was helpful!)
• Some requirements may be little bit confusing, e.g. "V4.11 Verify that all access controls are enforced on the server side" actually also asking to verify that client cannot manipulate unauthorized data.

Improvements

Could the ASVS be clearer, more complete, or structured in a better way?

• Yes ;) The Wiki-form of OWASP gives it a lot of unstructed possibilities, but there is a nice table of contents now. Still, the level of detail could be improved, but it seems that there are some half-baked attempts being made to accomplish that.

• It would be nice if ASVS could provide a reference review, to learn what the people who came up with the ideas actually mean.

Solution

• More and better OWASP documentation would be really helpful, especially if it would explain how to deal with all requirements.

• Commit these kind of tips and statements about ASVS to the OWASP community; possible actively participate in moving OWASP as Open Source project ahead

(Erik: I agree that these would be nice. I also see a danger, that the OWASP wiki would grow even further, and it becomes hard to find stuff.

Developers

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?

• Developers should always write code very clear (good layout rules), uniformly and have a lot of documentation inside the code. Also use best practice ways and have things modular and non refactored to have as little redundancy as possible.

• When looking from a reviewer's point of view, Aspect Oriented Programming (or even Annotations) really starts making sense, as different (non-functional) responsibilities are easily added (and reviewed) to different code points. This makes it easier to establish that for example access control is applied in a complete way to a codebase. (Erik: Good points. AOP has been proposed for security for the reasons you mention, though interest in it have died down a bit. )

• When thinking about designing an architecture of a system or of an application, it makes sense to design functional topics like access control and input validation in such a way that they can be used through a sinkhole, and as such be easier reviewed.

• If, in the role of Reviewer, it is easy to spot that code is doing things right, then it is also easier for a developer to see and to create things right in the first place.

Group work

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?

• I think it was a very useful way to divide the labour. But we never really had a meeting in person or for example sitting next each other while working on the checks. If you do this you can help each other and discuss far more. I think that would improve the situation.

• We could have reviewed each other's work as well, but it is difficult to figure out how much time and effort you should put in an assignment like this; you easily make it a full time project!

Or when answering the question from the lecture perspective:

• It is very much workable and touches on the subject of security reviewing in general. The ASVS requirements are pretty much setup to be mutually exclusive as much as possible, so that allows for a parallel work on the different topics.

• In general, a students can learn a lot from working on actually reviewing part of the ASVS requirements, what the next steps could look like when coping with a complete security review.

Other interesting things

Any other interesting, frustating, boring, educational, etc. aspects of the whole experience.

• It's really good to get some practical insight into actual security code reviewing, which I think is pretty exciting! Especially because the topic is so relevant and actual, which is proven every single day.

(Erik:Your struggles with V4 suggest that it might be wise to let groups steer clear of V4 in the future, at least for the project in this course. It's one of the messier set of security requirements to verify - something you also ran into in your review )