the application. We could also find some spots where easy to find vulnerabilities
could be expected. However, looking at the source code was more effective,
especially when verifying that the \CMS{} \emph{passes} a requirement. Buggy code
-is easy to find. Bugless code is not.
+is easy to find. Bug-free code is not.
We have chosen to split the work by category of security requirements in
the OWASP Application Security Verification Standard. We set the goal to perform
the aim to be designed in such a way as to be easily transformed into automated penetration tests etc.
Another typical way to present security concerns and measures would be to list appropriate security concerns
- per type of architectural component of a web app, and thus integrate it into the development lifecycle.
+ per type of architectural component of a web app, and thus integrate it into the development life-cycle.
We suspect the ASVS is presented the way it is, exactly because security is an \emph{emergent property},
and thus security measures should not be regarded as attachments to respective components of an app.
Rather, it should be verified at each stage and level; and thus a checklist is a better presentation.
% Verifying each other's results
The final bottleneck we like to note concerns the verifying of each other's
-results. When verifying the results of your group members (collegues) it may be
+results. When verifying the results of your group members (colleagues) it may be
difficult to fully double-check their work. This touches upon the previous
point, for when a counterexample is giving it is trivial to see the result is
correct. However when a member of the group passes a requirement it will take
more time to verify this is the correct verdict. In the end we are confident of
our results, but this may be a bottleneck which can be addressed in the initial
-organisation.
+organization.
problems. This could be very useful in combination with the information about\r
components and functions which do pass the given security check. This would allow\r
developers to determine if they suffer from chronically malformed code \r
-(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire codebase) \r
+(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire code base) \r
or a single error (e.g. most relevant code passes the check except for a few isolated cases).\r
-In the tested codebase there is a clean distinction between an installer component and the\r
+In the tested code base there is a clean distinction between an installer component and the\r
actual web application. If the installer suffers from problems not present in\r
the web application and Fortify would be able to point out the specific check is\r
relevant to both components the company would know which team or developer needs some major\r
\fail{}
Verify that forms containing credentials are not filled in by
the application. Pre-filling by the application implies that
-credentials are stored in plaintext or a reversible format,
+credentials are stored in plain-text or a reversible format,
which is explicitly prohibited.
\begin{result}
\begin{result}
All authentication controls (login credentials and client cookies) are
enforced by the application. Note however item~\ref{auth:6}, about the
- security of these controls in the immplementation.
+ security of these controls in the implementation.
\end{result}
\setcounter{enumi}{5}
\item
\pass{}
Verify password entry fields allow, or encourage, the use
-of passphrases, and do not prevent password managers,
-long passphrases or highly complex passwords being
+of pass-phrases, and do not prevent password managers,
+long pass-phrases or highly complex passwords being
entered.
\begin{result}
stored in a protected location.
\begin{result}
- The database credentials are hardcoded in \code{config.php}. While it
+ The database credentials are hard-coded in \code{config.php}. While it
would be better to pass secrets as environment variables, this is not
really bad practice.
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.
+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
\item
\fail{}
Verify that measures are in place to block the use of
-commonly chosen passwords and weak passphrases.
+commonly chosen passwords and weak pass-phrases.
\begin{result}
No password strengthening measures are implemented. The app should
\item
\pass{}
-Browser autocomplete, and integration with password
+Browser auto-complete, and integration with password
managers are permitted unless prohibited by risk based
policy.
\begin{result}
- Browser autocomplete functionality is not restricted in any way.
+ Browser auto-complete functionality is not restricted in any way.
\end{result}
\end{enumerate}
\begin{result}
The session ids are generated by \PHP{} trough the \code{session\_start}
function. These are indeed sufficiently long, random and unique. There are
- no known attacks against these session ID's.
+ no known attacks against these session IDs.
\end{result}
appropriately restrictive value for the application, and authentication
session tokens additionally set the \code{HttpOnly} and \code{secure} attributes.
\begin{result}
- There is just one cookie for tha application and it's path includes the whole
+ There is just one cookie for the application and it's path includes the whole
site. However this seems appropriate. The \code{HttpOnly} and \code{secure}
attributes are not set for this cookie.
\end{result}
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 A login mechanism, where logged in users are allowed to access the back-end, and anonymous users are not.
\item For logged in users, a role system with three specified roles: admin, editor and regular user.
\end{itemize}
\item Folders, files, info over these data
\end{itemize}
-Our check reveales that the access control mechanisms are basically only a stub, and haven't been developed to their usually implied meaning, thus flattening the access control to the single aspect of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `backend' objects from anonymous users.
+Our check reveals that the access control mechanisms are basically only a stub, and haven't been developed to their usually implied meaning, thus flattening the access control to the single aspect of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `back-end' objects from anonymous users.
These are the results of our check:
against spoofing and elevation of privilege.
\begin{result}
-Aside from the authentication issues as described in V2, the login system that is in place works as intended, and theoretically only allows registered users to access the backend.
+Aside from the authentication issues as described in V2, the login system that is in place works as intended, and theoretically only allows registered users to access the back-end.
There is a role system, but it seems only to be a stub, for the role of a user has no effect whatsoever on their capabilities.
\end{result}
\begin{result}
\begin{itemize}[leftmargin=*]
\item \code{.gitignore} is freely accessible, as well as any other dot-preceded file (except \code{.htaccess}, which is hidden 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 code-base basically enables the listing by default.
\end{itemize}
\end{result}
\item
\fail{}
Verify that the application correctly enforces context-
-sensitive authorisation so as to not allow unauthorised
+sensitive authorization so as to not allow unauthorized
manipulation by means of parameter tampering.
\begin{result}
\begin{result}
As of OWASP's statement\footnote{\url{%
https://www.owasp.org/index.php/Buffer_Overflows\#Platforms_Affected}}
- \PHP{} is not surceptible to buffer overflows as long no external
+ \PHP{} is not susceptible to buffer overflows as long no external
programs or extensions are used which is not the case.
\end{result}
\addtocounter{enumi}{3}
\item\fail{} Verify that all \SQL{} queries, \code{HQL}, \code{OSQL},
\code{NOSQL} and stored procedures, calling of stored procedures are
- protected by the use of prepared statements or query parameterization,
+ protected by the use of prepared statements or query parametrization,
and thus not susceptible to \SQL{} injection.
\begin{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
- validation (whitelisting), then lesser forms of validation such as
+ validation (white-listing), then lesser forms of validation such as
greylisting (eliminating known bad strings), or rejecting bad inputs
(blacklisting).
repositories / ssproject1617.git / commitdiff