SoftwareSecurity2012/Group 3/Reflection

In this reflection we look back at the different parts of the Application Security Verification we performed on the FluxBB forum software. We look at all different aspects involved with our part of the project. The actual results of the project can be found on the verdict page, and will not be repeated here.

In short, we looked at the requirements related to the encoding of HTML output and whether this was handled correctly.

OWASP Requirements

For the ASV we looked at a number of requirements from the OWASP list. However, not a lot of details are given about the requirements. The descriptions consist of a single line, with little additional information. Because of this, the exact differences between some of the requirements was a bit vague. It made the security verification more difficult for us. However, the requirements did give us a good starting point for checking the HTML output encoding of the FluxBB software.

Process

The FluxBB source code is divided in a number of files, with some spread out over different directories. In general, the naming of the files provides enough information to determine where certain code can be found. For instance, options like edit and search have corresponding files "edit.php" and "search.php". The total amount of code however is quite extensive, and we did not consider it time effective to look through the entire code manually without some structured approach. As an example, for checking requirement V6.7 (Verify that all untrusted data that are included in operating system command parameters are escaped properly), we checked the code by searching every file for a set of common system commands that are used in PHP, rather than checking the entire code line by line. Using an editor with good search capabilities (in our case Notepad++), gives enough options to perform a check of the code on a reasonable level.

Another important method we used, is to first determine which requirements would take the least or most time to check. This lead to the following categorization of the requirements:

• Not very time consuming:

• V6.3: Verify that output encoding/escaping controls encode all characters not known to be safe for the intended interpreter.

Easy to check by determining the function that is used for escaping and then determining what characters that function encodes.

• V6.8: Verify that all untrusted data that are output to any interpreters not specifically listed above are escaped properly.

Easy to check since the only relevant interpreter for the forum is the users browser (and the interpreters of HTML and Javascript within it).

• Moderately time consuming:

• V6.7: Verify that all untrusted data that are included in operating system command parameters are escaped properly.

A bit harder to check since all files have to be searched for all common system commands.

• V6.2: Verify that all output encoding/escaping controls are implemented on the server side.

This one also took some time, since everytime the escaping function was used it had to be manually checked whether it was server side.

• Very time consuming:

• V6.1: Verify that all untrusted data that are output to HTML are properly escaped for the applicable context.

Relatively hard to check, as all warnings of the scanning tools have to be checked manually to determine if they are truly wrong.

This categorization allowed us to divide our time effectively by focusing on V6.1 as a group during our meetings and verifying the other requirements individually/in pairs when time was available. This enabled us to verify all requirements, with the exception of V6.1, in very little time and spend the remaining time focusing on V6.1 (arguably the most important requirement of the set).(I can see that V6.1 is the hard one to check. Some more reflection on how you could split the work would have been nice (eg does it make sense for different people to look at different files, or do you really have to trace the way information flows through several files? (how) could you keep track of who had looked at what?), and also on the degree of coverage one could try to achive here, or indeed if/how one can ensure this.)

After performing the verifications, we came together as a group to decide whether the requirements were considered passed, failed or indeterminate. In some cases, like for V6.7 as mentioned above, we could not say conclusively that the requirement was passed, but based on our analysis a certain result could be considered the most likely.