More SQL Injection
-
Comments posted to this topic are about the item More SQL Injection
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
With the ready availablility of exploit scripts, the opportunity exists for anyone with an axe to grind, a desire to rip someone off, or time on their hands to make life miserable for application owners. ';DROP TABLE USERS;--
-
(Just kidding.)
-
Time flow like a river and history repeat.
-
It's sad but I've seen code that is ripe for SQL Injection, commented it shouldn't be allowed and that if it was my decision it wouldn't be, yet the code gets pushed out because the "project must get done".
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question -
Jack Corbett (11/17/2011)
It's sad but I've seen code that is ripe for SQL Injection, commented it shouldn't be allowed and that if it was my decision it wouldn't be, yet the code gets pushed out because the "project must get done".:crazy: In the time it takes to write the comment/excuse the embedded SQL could have been copied and pasted to a strored procedure.
-
I agree with your points Steve. Interestingly, I think this dovetails nicely into the "don't criticize the code" discussion. It seems easy to justify ("management made me do it...") release of poor or inadequate code even today.
If you are a DBA or a senior level software person your job is to convince people of the need to build things properly.... that is, after all part of your job. If, after going on record expressing your concerns, you are somehow forced at gun point to implement crappy code then at least add a caveat comment and save your emails.
The probability of survival is inversely proportional to the angle of arrival.
-
Jack Corbett (11/17/2011)
It's sad but I've seen code that is ripe for SQL Injection, commented it shouldn't be allowed and that if it was my decision it wouldn't be, yet the code gets pushed out because the "project must get done".Seen this happen about three months ago. Fortunately, the PM who made this decision found he needed to spend more time with his family.
-
Irony: Just the other day this site was telling me "Don't Criticize Code", because it might hurt someone's fee-fee's.
-
On a well managed project you do code reviews. And if you are the reviewer, you do your best to be polite and helpful but it is your duty to find what can go wrong.
-
sherifffruitfly (11/17/2011)
Irony: Just the other day this site was telling me "Don't Criticize Code", because it might hurt someone's fee-fee's.I don't see the irony. The point of writing good code or finding and fixing bad code or code reviews in general is not to criticize someone else's code. It's to improve the overall quality of the code. Whether someone is overly critical about the code and/or coder is matter of tact or lack thereof not the objective of the exercise.
-
About SQL injection... it is really difficult to explain to people that are not well verse on SQL.
I found this article, which explains it and gives a few examples illustrating how easy is to perform an attack and how easy is to protect your code.
http://www.unixwiz.net/techtips/sql-injection.html#findname
Thanks
-
Dave62 (11/17/2011)
Jack Corbett (11/17/2011)
It's sad but I've seen code that is ripe for SQL Injection, commented it shouldn't be allowed and that if it was my decision it wouldn't be, yet the code gets pushed out because the "project must get done".:crazy: In the time it takes to write the comment/excuse the embedded SQL could have been copied and pasted to a strored procedure.
If management is so whacked and out of it, would they even notice if you just make the SQL Injection fix, and bundled it another change order? Especially during the development phaze. There are some simple fixes that can be implmented within the stored procedure to scrub input parameters, etc. without even touching the web application stuff.
Of course, it also helps to insure that the application account is running with least required privilages. Obviously the application account doesn't need sysadmin or dbo role membership, so that avoids the possibility of stuff like dropping tables, querying schema, or selecting from any table.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
Eric M Russell (11/17/2011)
Dave62 (11/17/2011)
Jack Corbett (11/17/2011)
It's sad but I've seen code that is ripe for SQL Injection, commented it shouldn't be allowed and that if it was my decision it wouldn't be, yet the code gets pushed out because the "project must get done".:crazy: In the time it takes to write the comment/excuse the embedded SQL could have been copied and pasted to a strored procedure.
If management is so whacked and out of it, would they even notice if you just make the SQL Injection fix, and bundled it another change order? Especially during the development phaze. There are some simple fixes that can be implmented within the stored procedure to scrub input parameters, etc. without even touching the web application stuff.
Of course, it also helps to insure that the application account is running with least required privilages. Obviously the application account doesn't need sysadmin or dbo role membership, so that avoids the possibility of stuff like dropping tables, querying schema, or selecting from any table.
Usually it is a good idea not to allow users access to the tables, only to views and sprocs.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply