.. ================================================== .. ================================================== .. ================================================== .. Header hierarchy .. == .. -- .. ^^ .. "" .. ;; .. ,, .. .. --------------------------------------------used to the update the records specified ------ .. Best Practice T3 reST: https://docs.typo3.org/m/typo3/docs-how-to-document/master/en-us/WritingReST/CheatSheet.html .. Reference: https://docs.typo3.org/m/typo3/docs-how-to-document/master/en-us/WritingReST/Index.html .. Italic *italic* .. Bold **bold** .. Code ``text`` .. External Links: `Bootstrap `_ .. Internal Link: :ref:`downloadButton` (default url text) or :ref:`download Button` (explicit url text) .. Add Images: .. image:: ./Images/a4.jpg .. .. .. Admonitions .. .. note:: .. important:: .. tip:: .. warning:: .. Color: (blue) (orange) (green) (red) .. .. Definition: .. some text becomes strong (only one line) .. description has to indented .. -*- coding: utf-8 -*- with BOM. .. include:: Includes.txt Security ======== All values passed to QFQ will be: * Checked against max. length and allowed content, on the client and on the server side. On the server side, the check happens before any further processing. The 'length' and 'allowed' content is specified per `FormElement`. 'digit' or 'alnumx' is the default. Violating the rules will stop the 'save record' process (Form) or result in an empty value (Report). If a variable is not replaced, check the default sanitize class. * Only elements defined in the `Form` definition or requested by `Report` will be processed. * UTF8 normalized (normalizer::normalize) to unify different ways of composing characters. It's more a database interest, to work with unified data. SQL statements are typically fired as `prepared statements` with separated variables. Further *custom* SQL statements will be defined by the webmaster - those do not use `prepared statements` and might be affected by SQL injection. To prevent SQL injection, every variable is by default escaped with `mysqli::real_escape_string`. **QFQ notice**: * Variables passed by the client (=Browser) are untrusted and use the default sanitize class 'digit' (if nothing else is specified). If alpha characters are submitted, the content violates `digit` and becomes therefore `!!!!` - there is no error message. Best is to always use SIP (value is trustful) or at least digits for GET (=client) parameter (user might change those and therefore those are *not* trustful). Get Parameter ------------- **QFQ security restriction**: * GET parameter might contain urlencoded content (%xx). Therefore all GET parameter will be processed by 'urldecode()'. As a result a text like '%nn' in GET variables will always be decoded. It's not possible to transfer '%nn' itself. * GET values are limited to securityGetMaxLength (:ref:`extension-manager-qfq-configuration`) chars - any violation will stop QFQ. Individual exceptions are defined via :ref:`ExceptionMaxLength`. * GET parameter 'type' and 'L' might affected by (T3, configuration dependent) cache poisoning. If they contain non digit values, only the first character is used (if this is a digit) or completely cleaned (else). Post Parameter -------------- Per `FormElement` (HTML input) the default is to `htmlspecialchars()` the input. This means ``&<>'"`` will be encoded as htmlentity and saved as a htmlentity in the database. In case any of these characters (e.g. for HTML tags) are required, the encoding can be disabled per FormElement: `encode=none` (default is `specialchar`). During Form load, htmlentities are decoded again. $_SERVER -------- All $_SERVER vars are htmlentities encoded (all, not only specialchars!) . Honeypot -------- Every QFQ Form contains 'honeypot'-HTML input elements (HTML: hidden & readonly). Which of them to use is configured in :ref:`configuration` (default: 'username', 'password' and 'email'). On every start of QFQ (form, report, save, ...), these variables are tested if they are non-empty. In such a case a probably malicious bot has send the request and the request will not be processed. If any of the default configured variable names are needed (which will never be the case for QFQ), an explicit variable name list have to be configured in :ref:`configuration`. **QFQ security restriction**: * The honeypot variables can't be used in GET or POST as regular HTML input elements - any values of them will terminate QFQ. Violation --------- On any violation, QFQ will sleep `securityAttackDelaySeconds` (:ref:`configuration`) and than exit the running PHP process. A detected attack leads to a complete white (=empty) page. If `securityShowMessage`: on (:ref:`configuration`), at least a message is displayed after the delay. Client Parameter via SIP ------------------------ Links with URL parameters, targeting to the local website, are typically SIP encoded. Instead of transferring the parameter as part of the URL, only one unique GET parameter 's' is appended at the link. The parameter 's' is unique (equal to a timestamp) for the user. Assigned variables are stored as a part of the PHP user session on the server. Two users might have the same value of parameter 's', but the content is completely independent. Variables needed by Typo3 remains on the link and are not 'sip-encoded'. .. _`SecureDirectFileAccess`: Secure direct file access ------------------------- A check for protected folder access is active as default and in the qfq configuration defined under security.protectedFolderCheck. See: :ref:`extension-manager-qfq-configuration` An activated check creates automatically a `.htaccess` file with following content which denies every connection from outside the server: :: Deny from all Command wget is used for access check. Command can be changed under tools.cmdWget, configured in qfq configuration. See: :ref:`extension-manager-qfq-configuration` If you don't need the protected folder check, then revise following instructions. If the application uploads files, mostly it's not necessary and often a security issue, to offer a direct download of the uploaded files. Best is to create a directory, e.g. `/fileadmin/protected` and deny direct access via webbrowser to it. E.g. for Apache set a rule: :: Require all denied If you only have access to `.htaccess`, create a file `/fileadmin/protected/.htaccess` with: :: Require all denied .. important:: All QFQ uploads should save files only in/below such a protected directory. To offer download of those files, use the reserved column name '_download' (see :ref:`download`) or variants. .. important:: To protect the installation against executing of uploaded malicious script code, disable PHP for the final upload directory. E.g. `fileadmin` (Apache):: php_admin_flag engine Off This is in general a good security improvement for directories with user supplied content. File upload ----------- By default the mime type of every uploaded file is checked against a white list of allowed mime types. The mime type of a file can be (easily) faked by an attacker. This check is good to handle regular user file upload for specific file types but won't help to prevent attacks against uploading and executing malicious code. Instead prohibit the execution of user contributed files by the webserver config (`SecureDirectFileAccess`_). Typo3 Setup - best practice --------------------------- * Activate notification emails for every BE login (if there are only few BE users). In case the backend has been hacked, unusual login's (time or username) will appear: :: [BE][warning_email_addr] = [BE][warning_mode] = 1