Comments on: Improve the speed and security of your SQL queries http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/ Meditations on programming, startups, and technology Wed, 01 Feb 2012 10:09:40 +0000 hourly 1 http://wordpress.org/?v= By: Ennuyer.net » Blog Archive » Rails Reading - Sept 10, 2009 http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/#comment-7666 Ennuyer.net » Blog Archive » Rails Reading - Sept 10, 2009 Thu, 10 Sep 2009 19:36:01 +0000 http://antoniocangiano.com/?p=1101#comment-7666 [...] Improve the speed and security of your SQL queries | Zen and the Art of Programming [...] [...] Improve the speed and security of your SQL queries | Zen and the Art of Programming [...]

]]> By: Mario Briggs http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/#comment-7659 Mario Briggs Thu, 10 Sep 2009 08:17:05 +0000 http://antoniocangiano.com/?p=1101#comment-7659 Ankur, you are right and wrong at the sametime. Blind faith can lead to problems :-) e.g. String street = getStreetFromUser(); Query query = session.createQuery("from Address a where a.street='" + street + "'"); see - http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection Ankur,
you are right and wrong at the sametime. Blind faith can lead to problems :-)
e.g.
String street = getStreetFromUser();
Query query = session.createQuery(“from Address a where a.street=’” + street + “‘”);

see – http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection

]]> By: Ankur Shah http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/#comment-7648 Ankur Shah Wed, 09 Sep 2009 15:58:54 +0000 http://antoniocangiano.com/?p=1101#comment-7648 I think so hibernate have inbuilt support for parameterized query. So hibernate is less prone to sql injection. I think so hibernate have inbuilt support for parameterized query. So hibernate is less prone to sql injection.

]]> By: TimothyAWiseman http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/#comment-7646 TimothyAWiseman Wed, 09 Sep 2009 15:37:06 +0000 http://antoniocangiano.com/?p=1101#comment-7646 Excellent post. Paramaterizing queries can be enormous beneficial in terms of both speed and security. The article "The Curse and Blessing of Dynamic SQL " at http://www.sommarskog.se/dynamic_sql.html makes this point with examples and details for T-SQL in Microsoft SQL Server. Excellent post. Paramaterizing queries can be enormous beneficial in terms of both speed and security.

The article “The Curse and Blessing of Dynamic SQL ” at http://www.sommarskog.se/dynamic_sql.html
makes this point with examples and details for T-SQL in Microsoft SQL Server.

]]> By: Mike Woodhouse http://programmingzen.com/2009/09/09/improve-the-speed-and-security-of-your-sql-queries/#comment-7640 Mike Woodhouse Wed, 09 Sep 2009 08:13:14 +0000 http://antoniocangiano.com/?p=1101#comment-7640 In general, I absolutely agree with the above. Where the RDBMS not only stores the parsed query but the query plan, however, one should probably be aware that queries such as the "BETWEEN" one can have unexpected adverse effects. Consider the case where all karma values lie between 1000 and 5000 and further that karma is indexed. A SELECT for karma between 1999 and 2001 will almost certainly use the index, being suitably selective. Looking for all karmas between 1100 and 4900 would probably be best done with a table scan, but would be unexpectedly slower in the case that the query plan was re-used from the first query. It's a relatively rare situation but I'm sensitive to it: the scars are still healing after several years ago! In general, I absolutely agree with the above. Where the RDBMS not only stores the parsed query but the query plan, however, one should probably be aware that queries such as the “BETWEEN” one can have unexpected adverse effects.

Consider the case where all karma values lie between 1000 and 5000 and further that karma is indexed. A SELECT for karma between 1999 and 2001 will almost certainly use the index, being suitably selective. Looking for all karmas between 1100 and 4900 would probably be best done with a table scan, but would be unexpectedly slower in the case that the query plan was re-used from the first query.

It’s a relatively rare situation but I’m sensitive to it: the scars are still healing after several years ago!

]]>