clean:
$(RM) $(addprefix $(DOC).,aux log fmt toc bbl blg mlog run.xml out)\
$(DOC)-blx.bib logo.png
+
+clobber: clean
+ $(RM) $(DOC).pdf
Fortify's results can be summarized to the following:
\begin{enumerate}[label=(\Alph*)]
- \item 50 cases of \textbf{XSS} vurnerabilities, all labeled \textbf{critical}, because none of the CMS's forms include nonces / protection against XSS is indeed missing.
+ \item 50 cases of \XSS{} vurnerabilities, all labeled \textbf{critical}, because none of the \CMS{}'s forms include nonces / protection against \XSS{} is indeed missing.
\item \textbf{Password management}. In a user password reset form in \code{reset.php}, if the resetting fails, the password the user just entered reappears in the password field. This is not a database-retrieved password, and hence not actually as \textbf{critical} as Fortify labels it, but of course bad practice nonetheless.
\item In the \textbf{privact violation} category, Fortify found errors and warnings printed back to the browser, and labelled it \textbf{critical}. However, this happens in the installer script, which we have decided to treat separately, as explained earlier.
- \item \textbf{SQL injection} attacks are possible on the installer script, labelled \textbf{critical}. Yet again: the installer script.
+ \item \textbf{\SQL{} injection} attacks are possible on the installer script, labelled \textbf{critical}. Yet again: the installer script.
\item \textbf{Cookie security}: the \code{HttpOnly} header is not set, labelled \textbf{high}.
- \item \textbf{Privacy violation}: HTML forms don't disable autocompletion. Labelled \textbf{high}. However, autocompletion of HTML forms by means of the \code{autocompletion="none"} attribute notoriously doesn't really work. The larger problem is that the post/redirect/get pattern is not followed, as stated above at our analysis of OWASP requirement (9.1).
- \item Fortify complains that PHP's \code{crypt(...)} function is \textbf{weak encryption} and labels the 5 usages \textbf{high}.
+ \item \textbf{Privacy violation}: \HTML{} forms don't disable autocompletion. Labelled \textbf{high}. However, autocompletion of \HTML{} forms by means of the \code{autocompletion="none"} attribute notoriously doesn't really work. The larger problem is that the post/redirect/get pattern is not followed, as stated above at our analysis of OWASP requirement (9.1).
+ \item Fortify complains that \PHP{}'s \code{crypt(...)} function is \textbf{weak encryption} and labels the 5 usages \textbf{high}.
\end{enumerate}
\begin{description}
\item[V4.9] Verify that the same access control rules implied by the presentation layer are enforced on the server side. \\
- (\textit{The CMS failed this requirement in our analysis.})
- \item[V5.17] Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, environment, etc.. \\
- (\textit{The CMS passed this requirement in our analysis.})
+ (\textit{The \CMS{} failed this requirement in our analysis.})
+ \item[V5.17] Verify that the application has defenses against \HTTP{} parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (\GET{}, \POST{}, cookies, headers, environment, etc.. \\
+ (\textit{The \CMS{} passed this requirement in our analysis.})
\end{description}
-For this reason, Fortify was nowhere near able to identifying all the problems we found in the CMS. An overview of our findings, where Fortify's concurrences are outlined explicitly, is given by the table below.
+For this reason, Fortify was nowhere near able to identifying all the problems we found in the \CMS{}. An overview of our findings, where Fortify's concurrences are outlined explicitly, is given by the table below.
\newcommand{\p}{{\color{lightgray}\pass}}
innertopmargin=2pt,
innerbottommargin=2pt,
skipabove=\topsep,
- skipbelow=\topsep
+ skipbelow=\topsep%
]{result}
% Tools afkortingen
+\newcommand{\API}{\emph{API}}
+\newcommand{\CMS}{\emph{CMS}}
+\newcommand{\CSRF}{\emph{CSRF}}
+\newcommand{\DELETE}{\emph{DELETE}}
+\newcommand{\DOM}{\emph{DOM}}
+\newcommand{\GET}{\emph{GET}}
+\newcommand{\GUID}{\emph{GUID}}
+\newcommand{\HTMLF}{\textsc{HTML5}}
+\newcommand{\HTML}{\textsc{HTML}}
+\newcommand{\HTTPS}{\textsc{HTTPS}}
+\newcommand{\HTTP}{\textsc{HTTP}}
+\newcommand{\JQuery}{\textsc{JQuery}}
+\newcommand{\JSON}{\textsc{JSON}}
+\newcommand{\LDAP}{\textsc{LDAP}}
\newcommand{\PHP}{\textsc{PHP}}
+\newcommand{\PII}{\emph{PII}}
+\newcommand{\POST}{\emph{POST}}
+\newcommand{\PUT}{\emph{PUT}}
+\newcommand{\REST}{\emph{REST}}
+\newcommand{\RSS}{\emph{RSS}}
+\newcommand{\SMTP}{\emph{SMTP}}
\newcommand{\SQL}{\textsc{SQL}}
-\newcommand{\LDAP}{\textsc{LDAP}}
+\newcommand{\SSO}{\emph{SSO}}
+\newcommand{\TOTP}{\emph{TOTP}}
+\newcommand{\TRACE}{\emph{TRACE}}
\newcommand{\XML}{\textsc{XML}}
-\newcommand{\HTML}{\textsc{HTML}}
-\newcommand{\JSON}{\textsc{JSON}}
-\newcommand{\JQuery}{\textsc{JQuery}}
+\newcommand{\XSS}{\emph{XSS}}
+
% Reference naar de source
\newcommand{\srcref}[2]{{\small\texttt{#1}} (line(s) #2)}
-TODO
\ No newline at end of file
+Some categories in the ASVS are easier to check than others. For example
+Section~\ref{sec:v6}. A lot of possible attack vectors were not available just
+because the were not used. In other cases the verdict was an easy fail since
+some components, like input escaping, are just not present.
+%
+%TODO
+%- Vandaag verdict (puntjes) uploaden (iedereen)!
+%- Na morgen heeft iedereen de resultaten van Fortify een keer bekeken
+%- Aanpak beschrijven, vóór volgende bijeenkomst (Daan)
+%- Iedereen een stuk reflectie schrijven (zie onder):
+%- Spreadsheet bouwen, vóór volgende bijeenkomst (Charlie)
+%
+%Uit opdracht:
+%
+%Reflection
+%Reflect on the whole process, including
+%
+% the ASVS,
+% the use of static code analysis tools,
+% the way you organised the process,
+% and possibly also the TestCMS code.
+%
+%For example, questions to consider are:
+% - Kelley: How good (useful, clear, ...) is the ASVS? How could it be improved?
+% - Charlie: How useful were code analysis tools? How could they be improved? How did you experience the rates and amounts of false and true positives? How might that be improved?
+% - Wouter: What were the bottlenecks in doing the security review in your experience?
+% - Mart: Maybe in the points above you can distinguish different (types of) security flaws or verification requirements. E.g., are some (categories of) verification requirements easier to check than others?
+% - Daan: If you would have to do something like this again, what would you do differently? Eg. about organising things within the group: i.e., in retrospect, what do you think the best approach is to organise and divide the work in a team? (Dividing the verification requirements over the team members? Or by dividing the code? Or letting everyone look at everything, because different people will spot different things? Or work in pairs where one person confirms the findings of the other? ...)
+% - Kelley: About the TestCMS code: are there important aspects that could (or should) be changed to improve security? Or aspects that could be changed to facilitate doing a security review?
+% - Wouter: This last question might be generalised, to (web) applications in general, rather than this specific example of the TestCMS: ie. if you were to develop an application that will need to be subjected to a security review, would you do anything differently, given your experience in doing this, and if so, what and why?
\section{Organization}
\input{organization.tex}
-\section{Our security analysis of the CMS}
+\section{Our security analysis of the \CMS{}}
\subsection{General comments}
\begin{itemize}
\item
- The CMS comes equipped with an installer script, which is incredibly insecure, but which the author of the CMS assumes the admin will remove after installation. If we regard this installer script as part of our subject matter, the analysis becomes incredibly simple, as it directly makes the CMS vulnerable to server side code execution, SQL injections, etc. Therefore, we regard the installer script as a special case, and we assume that it is indeed removed after installation. The analysis, then, treats the CMS as it is after installation.
+ The \CMS{} comes equipped with an installer script, which is incredibly insecure, but which the author of the \CMS{} assumes the admin will remove after installation. If we regard this installer script as part of our subject matter, the analysis becomes incredibly simple, as it directly makes the \CMS{} vulnerable to server side code execution, \SQL{} injections, etc. Therefore, we regard the installer script as a special case, and we assume that it is indeed removed after installation. The analysis, then, treats the \CMS{} as it is after installation.
\item
- A number of times in our analysis, the OWASP ASVS requirements will require certain overridable server settings or request/response headers to be correcty set. The CMS is in principle able to set these parameters, for example by adding directives to an Apache \code{.htaccess} file, or explicitly setting certain HTTP response headers. However, the CMS does not do so, and therefore relies upon the server's default settings. In these cases, we consider the requirements failed, although one might contest this on the principle of separation of concerns.
+ A number of times in our analysis, the OWASP ASVS requirements will require certain overridable server settings or request/response headers to be correcty set. The \CMS{} is in principle able to set these parameters, for example by adding directives to an Apache \code{.htaccess} file, or explicitly setting certain \HTTP{} response headers. However, the \CMS{} does not do so, and therefore relies upon the server's default settings. In these cases, we consider the requirements failed, although one might contest this on the principle of separation of concerns.
\end{itemize}
\subsection{Access Control}
\input{v4_access.tex}
- \subsection{Input Validation \& Output Encoding/Escaping}
+ \subsection{Input Validation \& Output Encoding/Escaping}\label{sec:v6}
\input{v5_input.tex}
\addtocounter{subsection}{1}
\input{v9_data.tex}
\addtocounter{subsection}{2}
- \subsection{HTTP Security}
+ \subsection{\HTTP{} Security}
\input{v11_httpsec.tex}
\addtocounter{subsection}{4}
\item\fail{}
Verify that the application accepts only a defined
-set of required HTTP request methods, such as
-GET and POST are accepted, and unused methods
-(e.g. TRACE, PUT, and DELETE) are explicitly
+set of required \HTTP{} request methods, such as
+\GET{} and \POST{} are accepted, and unused methods
+(e.g. \TRACE{}, \PUT{}, and \DELETE{}) are explicitly
blocked.
\begin{result}
- The application treats only \texttt{POST} requests as different from
+ The application treats only \POST{} requests as different from
others and in an opportunistic manner. It assumes all other methods to be
- treated as \texttt{GET} requests.
+ treated as \GET{} requests.
\end{result}
\item\pass{}
-Verify that every HTTP response contains a
+Verify that every \HTTP{} response contains a
content type header specifying a safe character set
-(e.g., UTF-8, ISO 8859-1).
+(e.g., \emph{UTF-8}, \emph{ISO 8859{-}1}).
\begin{result}
Content type headers may be set anywhere in the application. Furthermure,
- \texttt{Response::send} ensures that if no content type header is set, all
- responses will fall back to using \texttt{text/html; charset=UTF-8}.
+ \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}
\notapplicable{\item
-Verify that HTTP headers added by a trusted proxy
-or SSO devices, such as a bearer token, are
+Verify that \HTTP{} headers added by a trusted proxy
+or \SSO{} devices, such as a bearer token, are
authenticated by the application.}
% No proxies are present
in use for sites where content should not be
viewed in a 3rd-party X-Frame.
\begin{result}
- The application will never supply an \texttt{X-FRAME-OPTIONS} header. While
+ The application will never supply an \code{X-FRAME-OPTIONS} header. While
this is not really a problem for the home page, a 3rd party X-Frame should
not be able to refer to the administrative interfaces of the application
and this should be fixed.
\end{result}
\item\pass{}
-Verify that the HTTP headers or any part of the
-HTTP response do not expose detailed version
+Verify that the \HTTP{} headers or any part of the
+\HTTP{} response do not expose detailed version
information of system components.
\begin{result}
- The headers provide information about the PHP version (these are added by
- the PHP interpreter by default) and information about the webserver. This
+ The headers provide information about the \PHP{} version (these are added by
+ the \PHP{} interpreter by default) and information about the webserver. This
information is not specific for the application. It would be advisable to
- hide the PHP version to the client, but this is specific to the way the
+ hide the \PHP{} version to the client, but this is specific to the way the
application is installed.
\end{result}
\item\fail{}
-Verify that all API responses contain X-Content-Type-Options:
-nosniff and Content-Disposition:
-attachment; filename="api.json" (or other
+Verify that all \API{} responses contain \code{X-Content-Type-Options:
+nosniff} and\\
+\code{Content-Disposition: attachment; filename="api.json"} (or other
appropriate filename for the content type).
\begin{result}
- The application does not supply the \texttt{X-Content-Type-Options} header.
+ The application does not supply the \code{X-Content-Type-Options} header.
\end{result}
\item\fail{}
\item\fail{}
Verify that the X-XSS-Protection: 1; mode=block
-header is in place to enable browser reflected XSS
+header is in place to enable browser reflected \XSS{}
filters.
\begin{result}
- The application does not supply the \texttt{X-XSS-Protection} header.
+ The application does not supply the \code{X-XSS-Protection} header.
\end{result}
\end{enumerate}
\begin{result}
The input to various forms is not sanitized at all. This makes the implementation
- in (not only) \texttt{Users::find} vulnerable to SQL injections. The login form
- is also vulnerable. Any user can execute arbitrary SQL code from the username field.
+ in (not only) \code{Users::find} vulnerable to \SQL{} injections. The login form
+ is also vulnerable. Any user can execute arbitrary \SQL{} code from the username field.
The following example code can submitted as username in the login form, which
- will set the password of the \texttt{admin} user to \texttt{s3cret}:
+ will set the password of the \code{admin} user to \code{s3cret}:
\code{"; UPDATE users SET password='\$1\$OWgsBb90\$Lkko6aZwmp9XOVrFI09Ab0' WHERE \\username='admin' AND 'a' = "a}
\begin{result}
The application allows the user to use any password (except ones that contain
- SQL code).
+ \SQL{} code).
\end{result}
\item
expire, however. It would be even better to require that a token be used
withing a day (or so) after creation.
- The security of the SMTP connection is at the discretion of the web server.
+ The security of the \SMTP{} connection is at the discretion of the web server.
Often these connections are not very secure, but this worry is beyond the
scope of this audit.
\end{result}
force and password hash recovery attacks.
\begin{result}
- Password are stored in database using the PHP function \texttt{crypt}. Internally, this
- function uses salted MD5. This is way easy too reverse with brute-force attacks using dictionary files.
+ Password are stored in database using the \PHP{} function \code{crypt}. Internally, this
+ function uses salted MD5. This is way too reverse with brute-force attacks using dictionary files.
- Instead it would be better to use the \texttt{argon2} password hashing algorithm
- or the PHP \texttt{password\_hash} function (which currently uses BCRYPT).
+ Instead it would be better to use the \code{argon2} password hashing algorithm
+ or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT).
\end{result}
\setcounter{enumi}{15}
link.
\begin{result}
- The app allows admin users to log in over HTTP. This is insecure, as it allows
+ The app allows admin users to log in over \HTTP{}. This is insecure, as it allows
eavesdroppers to intercept password.
- The app should force HTTPS for at least the login form, the \texttt{admin\_controller} and
+ The app should force \HTTPS{} for at least the login form, the \code{admin\_controller} and
for the installation script (because the users posts secrets like the database
password to this page).
\end{result}
login, password reset, or forgot account functionality.
\begin{result}
- All these forms are vulnerable to SQL injection attacks. So any information
+ All these forms are vulnerable to \SQL{} injection attacks. So any information
can leak any information from the database.
\end{result}
\begin{result}
No secrets are initialized by predefined values. The admin user will have
- username \texttt{admin} by default. This is no secret and therefore not
+ username \code{admin} by default. This is no secret and therefore not
considered unsafe.
\end{result}
stored in a protected location.
\begin{result}
- The database credentials are hardcoded in \texttt{config.php}. While it
+ The database credentials are hardcoded in \code{config.php}. While it
would be better to pass secrets as environment variables, this is not
really bad practice.
\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
- the one running the PHP script.
+ running the \PHP{} script.
\end{result}
\item
\pass{}
Verify that forgotten password and other recovery paths
-use a TOTP or other soft token, mobile push, or other
+use a \TOTP{} or other soft token, mobile push, or other
offline recovery mechanism. Use of a random value in an
e-mail or SMS should be a last resort and is known weak.
\notapplicable{\item
Verify that if shared knowledge based questions (also
-known as "secret questions") are required, the questions
+known as ``secret questions'') are required, the questions
do not violate privacy laws and are sufficiently strong to
protect accounts from malicious recovery.}
\item
\fail{}
-Verify that secrets, API keys, and passwords are not
+Verify that secrets, \API{} keys, and passwords are not
included in the source code, or online source code
repositories.
\begin{result}
- The database credentials are hard coded in \texttt{config.php}. These
+ The database credentials are hard coded in \code{config.php}. These
credentials should ideally be passed using environment variables.
\end{result}
\begin{result}
The logout functionality is plainly visible on the top right of the
application on every page that requires authentication. This is defined in
- \srcref{admin/themes/header.php}{16-30}
+ \srcref{admin/themes/header.php}{16{-}30}
\end{result}
session tokens additionally set the “HttpOnly” and “secure” attributes.
\begin{result}
There is just one cookie for tha application and it's path includes the whole
- site. However this seems appropriate. The "HttpOnly" and "secure"
+ site. However this seems appropriate. The ``HttpOnly'' and ``secure''
attributes are not set for this cookie.
\end{result}
\noindent
-The CMS has the following access control mechanisms:
+The \CMS{} has the following access control mechanisms:
\begin{itemize}
\item A login mechanism, where logged in users are allowed to access the backend, and anonymous users are not.
\item
\fail{}
-Verify that the principle of least privilege exists - users
+Verify that the principle of least privilege exists {-} users
should only be able to access functions, data files, URLs,
controllers, services, and other resources, for which they
possess specific authorization. This implies protection
parameter to see or alter another user's account).
\begin{result}
-There is no different access context for distinct users. In particular, they are allowed to access and edit each others' account info, including password. Taken one way, this could be said to be by design and thus OK. But in any reasonable design concept allowing for distinct user accounts, this is clearly not the desired setup.
+There is no different access context for distinct users. In particular, they
+ are allowed to access and edit each others' account info, including
+ password. Taken one way, this could be said to be by design and thus OK\. But in any reasonable design concept allowing for distinct user accounts, this is clearly not the desired setup.
\end{result}
\item
\begin{result}
\begin{itemize}[leftmargin=*]
\item \code{.gitignore} accessible, as well as any other dot-preceded file (except \code{.htaccess} itself by default Apache rules), as well as files such as \code{Thumbs.db} and \code{.DS\_Store}.
- \item Directory contents were listed in my simple setup. A global apache setting may disable by default, but the \code{.htaccess} file doesn't explicitly disable (with \code{Options -Indexes}), so that the CMS's codebase basically enables the listing by default.
+ \item Directory contents were listed in my simple setup. A global apache setting may disable by default, but the \code{.htaccess} file doesn't explicitly disable (with \code{Options -Indexes}), so that the \CMS{}'s codebase basically enables the listing by default.
\end{itemize}
\end{result}
\item
\fail{}
Verify that the application or framework uses strong
-random anti-CSRF tokens or has another transaction
+random anti-\CSRF{} tokens or has another transaction
protection mechanism.
\begin{result}
\srcref{classes/users.php}{145}.
\end{result}
- \item\pass{} Verify that the application is not susceptible to LDAP
- Injection, or that security controls prevent LDAP Injection.
+ \item\pass{} Verify that the application is not susceptible to \LDAP{}
+ Injection, or that security controls prevent \LDAP{} Injection.
\begin{result}
\LDAP{} is not used, thus the application is not susceptible.
recovery\\
(\srcref{classes/user.php}{115}) filepaths are calculated on the
hash of the password. All non standard filepaths, such as admin or
- theme files, are generated using functions. CMS urls are parsed using a
+ theme files, are generated using functions. \CMS{} urls are parsed using a
standard system wide \code{parse} function.
\end{result}
web client code is either properly contextually encoded manually, or
utilize templates that automatically encode contextually to ensure the
application is not susceptible to reflected, stored and DOM Cross-Site
- Scripting (XSS) attacks.
+ Scripting (\XSS{}) attacks.
\begin{result}
- A lot of \HTML{} tags are allowed in the post screen, therefore an XSS
+ A lot of \HTML{} tags are allowed in the post screen, therefore an \XSS{}
attack is trivial. Even the comment section uses no input validation
whatsoever.
\end{result}
malicious automatic binding.
\begin{result}
- There is some automatic variable binding happening in the POST and GET
+ There is some automatic variable binding happening in the \POST{} and \GET{}
however, defaults are always given and there is no possibility of
accidentally binding extra variables. Also the variables are in an
array.
\end{result}
- \item\pass{} Verify that the application has defenses against HTTP
+ \item\pass{} Verify that the application has defenses against \HTTP{}
parameter pollution attacks, particularly if the application framework
- makes no distinction about the source of request parameters (GET, POST,
+ makes no distinction about the source of request parameters (\GET{}, \POST{},
cookies, headers, environment, etc.)
\begin{result}
\end{result}
\item\fail{} Verify that all input data is validated, not only \HTML{} form
- fields but all sources of input such as REST calls, query parameters,
- HTTP headers, cookies, batch files, RSS feeds, etc; using positive
+ fields but all sources of input such as \REST{} calls, query parameters,
+ \HTTP{} headers, cookies, batch files, \RSS{} feeds, etc; using positive
validation (whitelisting), then lesser forms of validation such as
greylisting (eliminating known bad strings), or rejecting bad inputs
(blacklisting).
\begin{result}
- REST calls are validated using whitelisting, query parameters are not,
+ \REST{} calls are validated using whitelisting, query parameters are not,
headers are not, cookies not, batch files are non-existent and RSS feed
output is not filtered.
\end{result}
\addtocounter{enumi}{3}
\notapplicable{
\item
- Verify that all random numbers, random file names, random GUIDs, and random
+ Verify that all random numbers, random file names, random \GUID{}s, and random
strings are generated using the cryptographic module’s approved random
number generator when these random values are intended to be not guessable
by an attacker.
\item
Verify that cryptographic algorithms used by the application have been
- validated against FIPS 140-2 or an equivalent standard.
+ validated against FIPS 140{-}2 or an equivalent standard.
\begin{result}
The application uses MD5 for password hashing, which should be insecure by
now.
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 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.
\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 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
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 I 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.
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.
+ 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