SoftwareSecurity2014/Group 13/Reflection

Reflection

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

php's variables do not have a type, which makes it difficult to verify output escaping is done correctly. For example, integers do not need escaping, but strings do. If there is no escaping done on a variable, you have to check whether its type is an integer. This requires to search for assignments to the variable and sometimes complex dataflow analysis. PHPLint can solve this problem by turning php into a strongly typed language. This, however, requires a lot of annotations. Another feature of php that makes output escaping verification difficult is mixing output and code. Especially in loops and long if statements, understanding the general structure of the program then becomes hard.

For FluxBB most of our problems would be solved by a redesign of clearly separating input, business code and output. To check output escaping we'd only have to look at one component.

The ASVS is not very specific. In some cases it may not be clear if something should be a pass or fail. Some examples of incorrect code would be useful to understand what to look for.

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

The ASVS is a nice starting point for security assessment, as it clearly points to possible security vulnerabilities. That being said, the ASVS is overall not clear on whether a piece of software passed or failed a security aspect. Further elaboration and documentation on this part could result in a more objective assessment strategy.

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?

We think this worked quite well. In particular it was interesting to see the results of the input validation on FluxBB SoftwareSecurity2014/Group_3/Verdict. They had the same problems with the FluxBB code. An interesting point is that Group 3 trusts the SQL queries for the input validation, but we consider the SQL queries to be not properly escaped. This illustrates the overlap between the ASVS security requirements. It would be nice to have discussed these differences.

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

We found that the data flow in FluxBB was not very straight-forward or linear. This meant that it quickly became tedious or difficult to trace whether a given variable was escaped properly, for example. In general, we think that developers should share their design views, specifically how they intended to handle in-/output escaping and other security-critical functions.

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

Being a weakly typed language, php provides little type checking functionality, and as such, a programmer should be really careful about in-/output escaping. Also, the spaghetti coding style we encountered in FluxBB is something that should always be avoided. It not only makes the code rather unreadable, but small errors are bound to appear.