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 !!<name of sanitize class>!! - 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 (Extension Manager: QFQ Configuration) chars - any violation will stop QFQ. Individual exceptions are defined via Exception for SECURITY_GET_MAX_LENGTH.
  • 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 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 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 (Configuration) and than exit the running PHP process. A detected attack leads to a complete white (=empty) page.

If securityShowMessage: true (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’.

Secure direct file access

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. <site path>/fileadmin/protected and deny direct access via webbrowser to it. E.g. for Apache set a rule:

<Directory "/var/www/html/fileadmin/protected">
    Require all denied
</Directory>

If you only have access to .htaccess, create a file <site path>/fileadmin/protected/.htaccess with:

<IfModule mod_authz_core.c>
     Require all denied
</IfModule>

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 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):

<Directory "/var/www/html/fileadmin">
  php_admin_flag engine Off
</Directory>

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] = <your email>
[BE][warning_mode] = 1