From 4e6200b3f4264e0889b897e3e8752083cf0ffd4d Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 17 Oct 2016 12:45:16 +0200 Subject: [PATCH] meer dingen --- report/preamble.tex | 4 ++ report/v5_input.tex | 103 ++++++++++++++++++++++++++++++++++++++++++- report/v6_output.tex | 2 + 3 files changed, 107 insertions(+), 2 deletions(-) create mode 100644 report/v6_output.tex diff --git a/report/preamble.tex b/report/preamble.tex index 0030c2b..cc50745 100644 --- a/report/preamble.tex +++ b/report/preamble.tex @@ -1,5 +1,6 @@ \documentclass[a4paper,titlepage]{article} +\usepackage{CJKutf8} \usepackage{rutitlepage} \usepackage{geometry} \usepackage{hyperref} @@ -16,6 +17,9 @@ \newcommand{\PHP}{\textsc{PHP}} \newcommand{\SQL}{\textsc{SQL}} \newcommand{\LDAP}{\textsc{LDAP}} +\newcommand{\XML}{\textsc{XML}} +\newcommand{\HTML}{\textsc{HTML}} +\newcommand{\JSON}{\textsc{JSON}} % Reference naar de source \newcommand{\srcref}[2]{\texttt{#1} (line (s) #2)} diff --git a/report/v5_input.tex b/report/v5_input.tex index 3660b54..a255deb 100644 --- a/report/v5_input.tex +++ b/report/v5_input.tex @@ -15,8 +15,8 @@ returned to the user, no logging taking place. % They skip 5.4 \addtocounter{enumi}{1} - \item\pass{} Verify that input validation routines are enforced on the server - side. + \item\pass{} Verify that input validation routines are enforced on the + server side. Errors are accumulated in an array which, when non-empty, will fail the function and report the error. @@ -45,4 +45,103 @@ it is trivial to do an \SQL{} injection it might be possible to run commands via the database. However, which a sufficiently secure \SQL{} config this can not take place. + + %TODO hier nog even naar kijken + \item\pass{} Verify that the application is not susceptible to Remote File + Inclusion (RFI) or Local File Inclusion (LFI) when content is used that + is a path to a file. + + Some file inclusion might be possible in the themes. Also in password + recovery (\srcref{system/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 standard system wide \texttt{parse} function. + \item\pass{} Verify that the application is not susceptible to common + \XML{} attacks, such as XPath query tampering, \XML{} External Entity + attacks, and \XML{} injection attacks. + + No \XML{} or related techniques are used and thus the application is + not susceptible. + \item\fail{} Ensure that all string variables placed into \HTML{} or other + 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. + + 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. + \item\pass{} If the application framework allows automatic mass parameter + assignment (also called automatic variable binding) from the inbound + request to a model, verify that security sensitive fields such as + ``accountBalance'', ``role'' or ``password'' are protected from + malicious automatic binding. + + 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. + \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, + cookies, headers, environment, etc.) + + The system explicitly makes a difference with the different input + types. As said in the previous item, the function that does this + parameter parsing is system wide and uses defaults and filters unwanted + parameters. + \item\fail{} Verify that client side validation is used as a second line of + defense, in addition to server side validation. + + There is client side validation on comments in the email section. There + is no validation for the comments itself to check for malafide \HTML{}. + In the admin panel the email address is not validated. + \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 + greylisting (eliminating known bad strings), or rejecting bad inputs + (blacklisting). + + 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. + \item\pass{} Verify that structured data is strongly typed and validated + against a defined schema including allowed characters, length and + pattern (e.g. credit card numbers or telephone, or validating that two + related fields are reasonable, such as validating suburbs and zip or + post codes match). + + Email addresses are validated against \PHP's stander functionality. + Note that the \PHP{} email validation is not perfect and some valid + email addresses are rejected(such as email addresses with non-ASCII + characters). The other requirements are not used. + \item\pass{} Verify that unstructured data is sanitized to enforce generic + safety measures such as allowed characters and length, and characters + potentially harmful in given context should be escaped (e.g.\ natural + names with Unicode or apostrophes, such as + \begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara) + + Emailaddresses with non-ASCII characters are rejected. Unicode + characters are displayed correctly. + \item\fail{} Make sure untrusted \HTML{} from WYSIWYG editors or similar are + properly sanitized with an \HTML{} sanitizer and handle it + appropriately according to the input validation task and encoding task. + + This is not the case, any \HTML{} is allowed. + \item\fail{} For auto-escaping template technology, if UI escaping is disabled, + ensure that \HTML{} sanitization is enabled instead. + + See previous item. + \item\pass{} Verify that data transferred from one DOM context to another, + uses safe JavaScript methods, such as using \texttt{.innerText} and + \texttt{.val}. + + The \JQuery{} framework is used for this. + \item Verify when parsing \JSON{} in browsers, that \text{JSON.parse} is + used to parse \JSON{} on the client. Do not use \texttt{eval()} to + parse \JSON{} on the client. + + \item Verify that authenticated data is cleared from client storage, such + as the browser DOM, after the session is terminated \end{enumerate} diff --git a/report/v6_output.tex b/report/v6_output.tex new file mode 100644 index 0000000..b01611c --- /dev/null +++ b/report/v6_output.tex @@ -0,0 +1,2 @@ +\begin{enumerate}[label={6.\arabic*}] +\end{enumerate} -- 2.20.1