Connector Security

Suite and Optimus Suite 5
#1

Can you talk a bit about security of the PHP Connector when passing in additional parameters?

docs.dhtmlx.com/connector__php__ … nipulation

What’s to prevent SQL injection through the URL? Is the Connector coded to use PDO, parameterized queries, or other measures to help prevent injection?

Would additionally denying access to insert/update/delete actions prevent such attacks (assuming parameters are only passed in for SELECT actions)?

docs.dhtmlx.com/connector__php__ … urity.html

Thanks

#2

All incoming data is escaped before adding to the SQL code, of course. The code uses data escaping related to the DB driver ( mysql_real_escape for MySQL, pro->quote for PDO and etc. )

Those parameters are parsed only during select actions, they are ignored for other operations. Connector always create an API for all CRUD operations, so if you want to allow only data reading, you can block other operations.

#3

OK thanks. I did not appreciate until now that for a MySQL connection, there are 3 built-in options: mysql, mysqli and pdo (per here: docs.dhtmlx.com/connector__php__ … ample.html)

But a couple of things:

  1. It looks like for pdo and mysqli the code is not using prepared statements?

stackoverflow.com/questions/6017 … ion-in-php

  1. Isn’t php_mysql deprecated?

uk.php.net/manual/en/function.mysql-connect.php

#4

It looks like for pdo and mysqli the code is not using prepared statements?

Yes, due to historical reasons, the connector uses data escaping instead of prepared statements. They both produce the same result at the end.

Isn’t php_mysql deprecated?
Yes, Connector was designed when mysql extension was a default option. Currently, if you want to work with MySQL DB, usage of PDO data driver is recommended.

#5

II wonder if to really lock down security, you should consider changing the code to use prepared statements. Those SO links above offer some interesting points on the issues. Just a suggestion for the future. Thanks