report/reflection.secure_development.tex

   1 % Wouter:  This last question might be generalised, to (web) applications in
   2 % general, rather than this specific example of the TestCMS: ie. if you were to
   3 % develop an application that will need to be subjected to a security review,
   4 % would you do anything differently, given your experience in doing this, and if
   5 % so, what and why?
   6
   7 After our experience doing a security review of TestCMS, there are definitely
   8 lessons to be learned for development of easy{-}to{-}review applications.
   9
  10 % Mark sections of code as implementing some requirement
  11 One could, for example, mark sections of code which treat a certain security
  12 requirement clearly as such. This would allow for a speed up of the reviewing
  13 process. The reviewers would still need to check if the marked section treat
  14 what they state they do, but this would still lead to a decrease in the amount
  15 of time spent per requirement in the OWASP guidelines.
  16
  17 This would be for the reason that such an approach would clearly save time in
  18 the review, which would also increase the quality of the review and the overall
  19 security of the application. Of course every advantage come with certain
  20 disadvantages, and the disadvantage here is that such an approach would increase
  21 development time. This would also require more careful planning of the
  22 development of the application.
  23
  24 % Centralize user input
  25 Another improvement which would streamline the security audit would be to
  26 centralize the locations in which user input is handled. By doing this the whole
  27 class of vulnerabilities which stems from the handling of user input could be
  28 neutralized to an extent. This would be a relatively easy change in the
  29 development process with comparatively big security benefits.
  30
  31 % Centralize application output
  32 In the same category; during development the application could be designed in
  33 such a way that all dynamic output is sanitized before outputting it to the
  34 user. This would create another defense{-}in{-}depth layer for handling
  35 attacker controlled input.
  36
  37 % Use working frameworks
  38 To achieve the last two points one could use a framework verified to be secure,
  39 the security reviewers could then spend less time on verifying the framework and
  40 more on the implementation of the specific features of this application.