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.
+ 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
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
+ \HTTP{} message body or headers (i.e., URL parameters are
never used to send sensitive data).
\begin{result}
\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
an example screen scraping.}
\item\pass{} Verify that data stored in client side storage (such as
- HTML5 local storage, session storage, IndexedDB, regular
+ \HTMLF{} local storage, session storage, IndexedDB, regular
cookies or Flash cookies) does not contain sensitive data
- or PII.
+ 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
+ \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 / blobdiff