On 05.01.2016 12:45, Nicolas Ribot wrote: > Hi all, > > Concerning SQL, I can't see how we can protect from malicious SQL code > considering: > > OJ is not just an interface to SQL databases, but a complete SQL client > allowing to perform ANY kind of queries (as we open a connection to a > database then execute the statement in DB Query plugin, for instance). > Adhoc queries works the same: free SQL query to execute. > > To use PreparedStatements, we would have to parse a free query, which is > really complicated (see the PG SQL parser for instance) and extract column > names/positions and values to bind parameters.
not necessarily. the r/o db datastores should be easily converted into prepared statement. > I see OJ a bit like PgAdmin for Spatial Types when working with PostGIS: a > SQL client allowing DB admin to perform any task, even dangerous one. > For instance, when I use DB Query, I sometimes execute function definition > SQL as part of my SQL scripts. These functions can contain strings that look > like malicious code (when generating batch series of delete/update/insert > queries based on Catalog metadata). In this case, it would be very hard to > choose between legitimate and malicious code. > > QGis, through DB Manager, works the same: the user query is sent as-is, and > its the DB admins task to allow or not a safe connection to a database. > well, can't beat you to do it ;).. but maybe when touching query building next time you consider at least sql escaping variable parameters. i am totally aware that a free (adhoc) query cannot be made safer. but the default statements to read/test db datastore layers could be made more safe for sure. ..ede ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
