dhtmlxConnector is open to external access of other programs and any external user is allowed to change data in database.
Thus, adding some kind of session-based authentication is strongly recommended.
The built-in security manager allows limiting connector to certain operations.
connector.Request.AllowedAccess = AccessRights.Select; //allow Select action only connector.Request.AllowedAccess = AccessRights.Insert; //allow Insert action only connector.Request.AllowedAccess = AccessRights.Update; //allow Update action only connector.Request.AllowedAccess = AccessRights.Delete; //allow Delete action only connector.Request.AllowedAccess = AccessRights.All; //allow all action connector.Request.AllowedAccess = AccessRights.None; //deny all actions
The access rights can be combined:
//allow Select and Update actions connector.Request.AllowedAccess = AccessRights.Select | AccessRights.Update;
By default, the connector allows all operations.
Starting from version 1.5, dhtmlxConnector allows you to protect an app from XSS attacks.
3 security levels are available:
To set the necessary security level, use the next code:
ConnectorSecurity.XSS = ConnectorSecurity.SecutiryXSS.DHX_SECURITY_SAFETEXT; //ConnectorSecurity.SecutiryXSS.DHX_SECURITY_SAFEHTML; //ConnectorSecurity.SecutiryXSS.DHX_SECURITY_TRUSTED;
If you want to enable the same behavior as the previous versions of connectors had, set the DHX_SECURITY_TRUSTED mode.
The functionality requires 3.5 or later version of the DHTMLX Suite package
The protection is available starting from the version 1.5 and can be activated by the following code line:
ConnectorSecurity.SecurityKey = 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 the valid user session.
The technique is based on sessions, and assumes that any session will be preserved between separate script calls (default behavior).
Please make 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 someone else's session.Back to top