What’s all the fuss about this SQL Injection thing?
It boils down getting some malicious crafted SQL code into the SQL code of an application, destroying data or authenticate yourself without knowing any real password. xkdc has a nice explanation.
The simple cases base on wrong escaped strings and the like. But as this SQL injection cheatsheet shows there are an infinity number of possibilities.
At day most of the time my database connection is an Oracle connection and so i found this Oracle whitepaper titled How to write injection-proof PL/SQL very interesting (via Bruce Schneier found at the gay bar).
I do not have a magic recipe for avoiding attack vectors all the time but as well as the whitepaper is written, it’s not a solution to expose all queries only via pl/sql to clients. In fact, it’s a nightmare to get this to work with JPA and other ORM mappers.
I try not to use dynamic sql in the sense of “concatenate some strings with one another and mysql_real_escape_string or DBMS_Assert. them” but use prepared statements with placeholders and explicit datatypes. Also if there’s a need for computing sql queries at runtime, do not ever let user supplied input come near them. I know that i’m relying to my api in this case but there is always a point on which i must rely on i guess.
As alway, the most important thing is: Be conscious about what you are doing and try to understand that, but at this point, i leave the discussion about software development and enter the depths of common sense…
No comments yet
One Trackback/Pingback
[…] interesting to me where injections (again) but not SQL-Injections this time but injections into queues, for example those of […]
Post a Comment