From bbd53815ca081140fc8b22e9b4f2790bbad20528 Mon Sep 17 00:00:00 2001 From: W Date: Fri, 25 Nov 2016 10:57:42 +0100 Subject: [PATCH] add centralization comments --- report/reflection.secure_development.tex | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/report/reflection.secure_development.tex b/report/reflection.secure_development.tex index b190d8e..4729d43 100644 --- a/report/reflection.secure_development.tex +++ b/report/reflection.secure_development.tex @@ -21,5 +21,20 @@ disadvantages, and the disadvantage here is that such an approach would increase development time. This would also require more careful planning of the development of the application. -% Last section, lets try to end with some deep insight. +% Centralize user input +Another improvement which would streamline the security audit would be to +centralize the locations in which user input is handled. By doing this the whole +class of vulnerabilities which stems from the handling of user input could be +neutralized to an extent. This would be a relatively easy change in the +development process with comparatively big security benefits. +% Centralize application output +In the same category; during development the application could be designed in +such a way that all dynamic output is sanitized before outputting it to the +user. This would create another defense{-}in{-}depth layer for handling +attacker controlled input. + +% Use working frameworks +To achieve the last two points one could use a framework verified to be secure, +the security reviewers could then spend less time on verifying the framework and +more on the implementation of the specific features of this application. -- 2.20.1