--- /dev/null
+\begin{enumerate}[label={9.\arabic*}]
+ \item\fail{} Verify that all forms containing sensitive information
+ have disabled client side caching, including autocomplete
+ features.
+
+ \begin{result}
+ The login and page/post editing/creation forms post back to the same page, thereby incentivising the browser to cache the form inputs as well. This is as opposed to the common post/redirect/get model (see \url{http://en.wikipedia.org/wiki/Post/Redirect/Get}). Also, the \texttt{Cache-Control} isn't explicitly used anywhere in the CMS to aid the situation. In my test setup, the response does send \texttt{Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0}, but that'll be a default global Apache setting, I think.
+ \end{result}
+
+ \notapplicable{\item Verify that the list of sensitive data processed by the
+ application is identified, and that there is an explicit
+ policy for how access to this data must be controlled,
+ encrypted and enforced under relevant data protection
+ directives.}
+
+ \item\pass{} Verify that all sensitive data is sent to the server in the
+ HTTP message body or headers (i.e., URL parameters are
+ never used to send sensitive data).
+
+ \begin{result}
+ With the exception of the install script, which we treat separately as explained above, this is indeed the case.
+ \end{result}
+
+ \item\fail{} Verify that the application sets appropriate anti-caching
+ headers as per the risk of the application, such as the
+ following:
+ \begin{verbatim}
+ Expires: Tue, 03 Jul 2001 06:00:00 GMT
+ Last-Modified: {now} GMT
+ Cache-Control: no-store, no-cache, must-
+ revalidate, max-age=0
+ Cache-Control: post-check=0, pre-check=0
+ Pragma: no-cache
+ \end{verbatim}
+
+ \begin{result}
+ Cache control header are never set by the CMS. The fact that headers as these are indeed sent to the broswer in my test setup is probably due to default global Apache settings.
+ \end{result}
+
+ \item\pass{} Verify that on the server, all cached or temporary copies
+ of sensitive data stored are protected from unauthorized
+ access or purged/invalidated after the authorized user
+ accesses the sensitive data.
+
+ \begin{result}
+ Vacuously.
+ \end{result}
+
+ \notapplicable{\item Verify that there is a method to remove each type of
+ sensitive data from the application at the end of the
+ required retention policy.}
+
+ \item\pass{} Verify the application minimizes the number of
+ parameters in a request, such as hidden fields, Ajax
+ variables, cookies and header values.
+
+ \begin{result}
+ The CMS by no means sends any larger amount of parameters than would be expected, seen as it is but a simple app and mostly lacks extra functionality often leading to this kind of excessive parameter transferring, so I count this as a pass.
+ \end{result}
+
+ \notapplicable{\item Verify the application has the ability to detect and alert
+ on abnormal numbers of requests for data harvesting for
+ an example screen scraping.}
+
+ \item\pass{} Verify that data stored in client side storage (such as
+ HTML5 local storage, session storage, IndexedDB, regular
+ cookies or Flash cookies) does not contain sensitive data
+ or PII.
+
+ \begin{result}
+ Vacuously: data is not stored on the client side.
+ \end{result}
+
+ \item\pass{} Verify accessing sensitive data is logged, if the data is
+ collected under relevant data protection directives or
+ where logging of accesses is required.
+
+ \begin{result}
+ No logging occurs at all.
+ \end{result}
+
+ \item\pass{} Verify that sensitive information maintained in memory
+ is overwritten with zeros as soon as it no longer required,
+ to mitigate memory dumping attacks.
+
+ \begin{result}
+ I consider this outside of the scope of the CMS's security requirements, as it is written in, and thus relies on the (memory) security of, PHP.
+ \end{result}
+
+\end{enumerate}
repositories / ssproject1617.git / commitdiff