Commit da5693b5 authored by Carsten  Rose's avatar Carsten Rose
Browse files

Manual.rst: document escape type and enhance Security chapter.

parent ba817c0e
......@@ -461,26 +461,35 @@ URL Parameter
* URL (=GET) Parameter can be used in *forms* and *reports* as variables.
* If a value violates a parameter sanitize class, the value becomes an empty string.
Escape
^^^^^^
* Variables used in SQL Statements might cause trouble, if they contain single or double ticks.
* Escaping of single or double is defined by the parameter <escape> (fourth parameter):
Variables used in SQL Statements might cause trouble by using: NUL (ASCII 0), \\n, \\r, \\, ', ", and Control-Z.
Available `escape` types:
* 's' - single ticks will be escaped.
* 'd' - double ticks will be escaped.
* 'l' - LDAP search filter values will be escaped.
* 'L' - LDAP DN values will be escaped.
* 'm' - `real_escape_string() <http://php.net/manual/en/mysqli.real-escape-string.php>`_ (m = mysql)
* 'l' - LDAP search filter values will be escaped: `ldap-escape() <http://php.net/manual/en/function.ldap-escape.php>`_ (LDAP_ESCAPE_FILTER).
* 'L' - LDAP DN values will be escaped. `ldap-escape() <http://php.net/manual/en/function.ldap-escape.php>`_ (LDAP_ESCAPE_DN).
* 's' - single ticks will be escaped. str_replace() of ' against \\'.
* 'd' - double ticks will be escaped: str_replace() of " against \\".
* '-' - no escaping.
* Even it's possible to escape single and double ticks at the same time, this makes no sense.
* Which of them to escape (single or double) depends on the surrounding SQL query.
* Escaping is only necessary inside of SQL or LDAP queries.
* The `escape` type is defined by the fourth parameter of the variable. E.g.: `{{name:FE:alnumx:m}}` (m = mysql).
* It's possible to combine different `escape` types, they will be processed in the order given. E.g. `{{name:FE:alnumx:Ls}}` (L, s).
* Escaping is typically necessary for SQL or LDAP queries.
* Be careful when escaping nested variables. Best is to escape **only** the most outer variable.
* In `config.qfq.ini`_ a global `default escape type` can be defined. Such type applies to all substituted variables without
a *specific* escape type.
* Additionally a `default escape type` can be defined per `Form`. This overwrites the global definition of `config.qfq.ini`.
* To suppress a default escape type, the `escape type` = '-' will switch of escaping. E.g.: `{{name:FE:alnumx:-}}`.
Sanitize class
^^^^^^^^^^^^^^
* All values in Store *C* (Client=Browser) and store *F* (Form) will be sanitized:
* All :ref:`predefined-variable-names` have a specific default sanitize class. For these variables, it's not necessary
* All `predefined-variable-names`_ have a specific default sanitize class. For these variables, it's not necessary
to specify a sanitize class.
* All other variables (Store: C, F) get by default the sanitize class defined in the corresponding form. If not defined
the default class is 'digit'.
......@@ -513,26 +522,45 @@ Security
All values passed to QFQ will be:
* UTF8 normalized (normalizer::normalize) to unify different ways of composing characters,
*
* 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`. 'alnumx' is the
default allowed content for those. Violating the rules will stop the 'save record' process (Form) or result in an empty value (Report).
* 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 can be escaped with `mysqli::real_escape_string` by
defining the `escape` modifier `m`.
**QFQ notice**:
* Variables passed by the client (=Browser) are untrusted and use the default sanatize class 'digit' (if nothing else is
specified). If alpha characters are submitted, the content violates `digit` and becomes therefore empty - there is no
error message. Best is to always use SIP or digits.
Get Parameter
-------------
GET parameter might contain urlencoded content (%xx). 'urldDecode' all GET parameter.
The string length of GET parameter is limited on SECURITY_GET_MAX_LENGTH chars (see `config.qfq.ini`_)
GET parameter might contain urlencoded content (%xx). 'urldecode()' all GET parameter.
The string length of GET parameter is limited to SECURITY_GET_MAX_LENGTH chars (see `config.qfq.ini`_)
**QFQ security restiction**:
**QFQ security restriction**:
* '%nn' in GET variables will always be decoded. It's not possible to transfer '%nn' itself.
* GET variables are limited to SECURITY_GET_MAX_LENGTH chars - any violation will break QFQ.
* GET variables are limited to SECURITY_GET_MAX_LENGTH chars - any violation will break QFQ.
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 quotes or some of the others characters (e.g. for HTML tags) are
required, the encoding can be disabled per FormElement. During Form load, the htmlentities are decoded.
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 therse 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
--------
......@@ -546,24 +574,24 @@ Every QFQ Form contains 'honeypot'-HTML input elements (hidden & readonly). Whic
(default: 'username', 'password' and 'email'). Independet of the QFQ Form, on every start of QFQ, these variables are
tested if they are non-empty.
**QFQ security restiction**:
**QFQ security restriction**:
* The honeypot variables can't be used in GET or POST as regular HTML input elements - any use of it will break QFQ.
* 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 SYSTEM_SECURITY_ATTACK_DELAY seconds (`config.qfq.ini`_) and than exit the running PHP process.
On any violation, QFQ will sleep SECURITY_ATTACK_DELAY seconds (`config.qfq.ini`_) and than exit the running PHP process.
A detected attack leads to a complete white (=empty) page.
If SECURITY_SHOW_MESSAGE == true (`config.qfq.ini`_), a message is displayed.
If SECURITY_SHOW_MESSAGE = true (`config.qfq.ini`_), a message is displayed.
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 uniqe timestamp, called 's', is appended at the link. The parameter 's' is uniq (equal to a
timestamp) for the user and the assigned variables are stored as a part of the PHP user session on the server.
as part of the URL, only one uniqe GET parameter 's' is appended at the link. The parameter 's' is uniq (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 independet.
Variables needed by Typo3 remains on the link and are not 'sip-encoded'.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment