From 50c71ff31bba10a2d788650c075e1430683d9c12 Mon Sep 17 00:00:00 2001 From: Kelley van Evert Date: Wed, 30 Nov 2016 13:38:20 +0100 Subject: [PATCH] spelling --- report/organization.tex | 2 +- report/reflection.asvs.tex | 2 +- report/reflection.bottlenecks.tex | 4 ++-- report/reflection.tools.tex | 4 ++-- report/v2_authentication.tex | 18 +++++++++--------- report/v3_session.tex | 4 ++-- report/v4_access.tex | 10 +++++----- report/v5_input.tex | 6 +++--- 8 files changed, 25 insertions(+), 25 deletions(-) diff --git a/report/organization.tex b/report/organization.tex index e782083..31eb119 100644 --- a/report/organization.tex +++ b/report/organization.tex @@ -17,7 +17,7 @@ easy. Running the application made us understand the outline and components of 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 diff --git a/report/reflection.asvs.tex b/report/reflection.asvs.tex index 8f2272f..19c6c2a 100644 --- a/report/reflection.asvs.tex +++ b/report/reflection.asvs.tex @@ -10,7 +10,7 @@ First, note how it presents itself as a \emph{simple checklist}, with as single 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. diff --git a/report/reflection.bottlenecks.tex b/report/reflection.bottlenecks.tex index 42ced32..88dc6ad 100644 --- a/report/reflection.bottlenecks.tex +++ b/report/reflection.bottlenecks.tex @@ -29,10 +29,10 @@ requirement fails in \emph{one} case. % 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. diff --git a/report/reflection.tools.tex b/report/reflection.tools.tex index 49c7654..4205902 100644 --- a/report/reflection.tools.tex +++ b/report/reflection.tools.tex @@ -36,9 +36,9 @@ generate a clear overview of which components of the application contain detecte problems. This could be very useful in combination with the information about components and functions which do pass the given security check. This would allow developers to determine if they suffer from chronically malformed code -(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire codebase) +(e.g. all relevant code fails the check, indicating a very serious problem throughout the entire code base) or a single error (e.g. most relevant code passes the check except for a few isolated cases). -In the tested codebase there is a clean distinction between an installer component and the +In the tested code base there is a clean distinction between an installer component and the actual web application. If the installer suffers from problems not present in the web application and Fortify would be able to point out the specific check is relevant to both components the company would know which team or developer needs some major diff --git a/report/v2_authentication.tex b/report/v2_authentication.tex index 9c559e1..eb512cc 100644 --- a/report/v2_authentication.tex +++ b/report/v2_authentication.tex @@ -18,7 +18,7 @@ public (principle of complete mediation). \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} @@ -40,7 +40,7 @@ server side. \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} @@ -65,8 +65,8 @@ attackers cannot log in. \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} @@ -219,14 +219,14 @@ services external to the application are encrypted and 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 @@ -291,7 +291,7 @@ transaction signing is in place for high value transactions. \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 @@ -351,12 +351,12 @@ untrusted parties. \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} diff --git a/report/v3_session.tex b/report/v3_session.tex index ccf2a71..de65312 100644 --- a/report/v3_session.tex +++ b/report/v3_session.tex @@ -81,7 +81,7 @@ \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} @@ -91,7 +91,7 @@ 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} diff --git a/report/v4_access.tex b/report/v4_access.tex index 80358d8..1c0468f 100644 --- a/report/v4_access.tex +++ b/report/v4_access.tex @@ -3,7 +3,7 @@ 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} @@ -17,7 +17,7 @@ Some typical objects of access control, in this case, are: \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: @@ -41,7 +41,7 @@ possess specific authorization. This implies protection 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} @@ -70,7 +70,7 @@ such as \code{Thumbs.db}, \code{.DS\_Store}, \code{.git} or \code{.svn} folders. \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} @@ -159,7 +159,7 @@ No such mechanisms. \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} diff --git a/report/v5_input.tex b/report/v5_input.tex index 2aca35a..31a94be 100644 --- a/report/v5_input.tex +++ b/report/v5_input.tex @@ -5,7 +5,7 @@ \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} @@ -36,7 +36,7 @@ \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} @@ -134,7 +134,7 @@ \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). -- 2.20.1