content type header specifying a safe character set
(e.g., \emph{UTF-8}, \emph{ISO 8859{-}1}).
\begin{result}
- Content type headers may be set anywhere in the application. Furthermure,
+ Content type headers may be set anywhere in the application. Furthermure,\\
\code{Response::send} ensures that if no content type header is set, all
responses will fall back to using \code{text/html; charset=UTF-8}.
\end{result}
However, the installation instructions state the following:
\begin{verbatim}
-Change the file permissions to allow all users write access to the folder
-you extracted testcms to.
+Change the file permissions to allow all users write access to the
+folder you extracted testcms to.
\end{verbatim}
This implies making the configuration file readable for all users on the
system. This information should not be accessible for any user other than
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 \code{Cache-Control} isn't explicitly used anywhere in the \CMS{} to aid the situation. In my test setup, the response does send \code{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.
+ 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 \code{Cache-Control} isn't explicitly used anywhere in the \CMS{} to aid the situation. In our test setup, the response does send \code{Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0}, but that'll be a default global Apache setting, we think.
\end{result}
\notapplicable{\item Verify that the list of sensitive data processed by the
\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.
+ Cache control header are never set by the \CMS{}. The fact that headers as these are indeed sent to the broswer in our test setup is probably due to default global Apache settings.
\end{result}
\item\pass{} Verify that on the server, all cached or temporary copies
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.
+ 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 we count this as a pass.
\end{result}
\notapplicable{\item Verify the application has the ability to detect and alert
Vacuously: data is not stored on the client side.
\end{result}
- \item\pass{} Verify accessing sensitive data is logged, if the data is
+ \item\fail{} Verify accessing sensitive data is logged, if the data is
collected under relevant data protection directives or
where logging of accesses is 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{}.
+ We 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