dhtmlxconnector:app_security [DHX documentation]

PHP Connector DHTMLX


dhtmlxConnector is open to external access of another programs and any external user is allowed to change data in database.
Thus, adding some kind of session-based authentication is strongly recommended.

Basic security

Built-in security manager allows you to limit connector for certain operations.

$gridConn->access->deny("read"); //blocks Select action
$gridConn->access->deny("insert"); //blocks Insert action
$gridConn->access->deny("update"); //blocks Update action
$gridConn->access->deny("delete"); //blocks Delete action

By default, connector allows all operations.

Protection from cross-site scripting (XSS)

Starting from version 1.5, dhtmlxConnector allows you to protect an app from XSS attacks.

To avoid XSS attacks, the library checks all data inputted by users and according to the set security level doesn't allow html or javascript code to be inserted.

3 security levels are available:

  • DHX_SECURITY_SAFETEXT (default) - all html data is removed from the input field;
  • DHX_SECURITY_SAFEHTML - allows html data, but removes possible script tags and handlers;
  • DHX_SECURITY_TRUSTED - input fields are not filtered at all (similar to previous version of connectors).

To set the necessary security level, use the next code:

ConnectorSecurity::$xss = DHX_SECURITY_SAFETEXT;
//ConnectorSecurity::$xss = DHX_SECURITY_SAFEHTML;
//ConnectorSecurity::$xss = DHX_SECURITY_TRUSTED;

If you want to enable the same behavior as the previous versions of connectors have, set the DHX_SECURITY_TRUSTED mode.

Preventing CSRF and XSRF attacks

The functionality requires 3.5 or later version of the DHTMLX Suite package

The protection is available starting from version 1.5 and can be activated by the following code line:

ConnectorSecurity::$security_key = true;

After calling such a command, connectors start to include additional security keys to all data loading operations and process data updating calls only if they contain the same keys. As a result of this processing, it's impossible to trigger a data updating operation from some third-party site, even if an attacker has access to a valid user session.

The technique is based on php sessions and assumes that any php session will be preserved between separate script calls (default php behavior).

Please be sure that you understand what CSRF attack is, cause the stated technique won't prevent access to the connector from external urls, it will only prevent execution actions through some one elses session.