Latest LQ Deal: Linux Power User Bundle
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 12-21-2005, 02:11 AM   #1
Registered: Mar 2005
Posts: 94

Rep: Reputation: 15
sql injection

Hi all, i am a beginner in security. In sql injection i'm unfamiliar in SQL injection. Did anybody knows from A to Z about sql injection. I dont know on how to apply sql injection. This knowledge is purposely for my security paper.
Old 12-21-2005, 07:54 AM   #2
Registered: Sep 2002
Location: Cincinnati
Distribution: Debian GNU/Linux
Posts: 310

Rep: Reputation: 31
Old 12-21-2005, 10:03 AM   #3
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307

Rep: Reputation: 55
Old 12-22-2005, 05:10 AM   #4
Registered: Jun 2003
Location: London
Distribution: Linux Mint 13 Maya
Posts: 720

Rep: Reputation: 32
Basically sql injection is where a user interface eg forms that is not meant to allow people to run sql queries directly on the database, is badly set up and so by entering in various commands you can run sql queries or update/delete statements.

This is obviously very bad as someone could destroy an online shop's database.
Old 12-22-2005, 05:35 AM   #5
Senior Member
Registered: Nov 2003
Location: Knoxville, TN
Distribution: Kubuntu 9.04
Posts: 1,168

Rep: Reputation: 53
SQL injection attacks usually result from poor database design and coding practices. But basically you should never "build" sql statement in code by concatenating strings.

For example, lets say you had an input box with username and password fields. A properly designed database app would pass these to a stored proc where variables and Dynamic SQL would be used to build the statement to execute. A bad db programmer who thinks his general purpose language is just as good as SQL would try and concatentate those and execute the SQL statement directly. Seems a lot simpler to the newbie db programmer, but that's when you run into SQL injection troubles (not to mention the scalability problems that are also created... and usually not discovered until 100 people are on the system and it grinds to a halt.. anyway...)


"SELECT id FROM users WHERE username= " & strUserName & " AND password= " & strPassword

is bad coding because a user could enter " '' or username is null" for the username and " '' or password is null". The statement that would actually get executed then is:

SELECT id FROM users WHERE username = '' or username is null AND password = '' or password is null

Thus the reason it's called an "injection" attack... the cracker has "injected" his own code into your SQL statement and now has full access to the database without a valid account.
Old 12-22-2005, 06:57 AM   #6
Registered: Mar 2003
Location: Berkshire, England.
Distribution: SuSE 10.0
Posts: 299

Rep: Reputation: 32
Here's an article I wrote on the subject a while ago:

Hope it's useful for you.
Old 12-22-2005, 07:49 AM   #7
Registered: Oct 2004
Location: Romania
Distribution: Ubuntu server, FreeBsd
Posts: 472

Rep: Reputation: 30
Old 12-22-2005, 09:33 AM   #8
Senior Member
Registered: Nov 2003
Location: Knoxville, TN
Distribution: Kubuntu 9.04
Posts: 1,168

Rep: Reputation: 53
The UNIX wiz one was decent, I especially liked:

"Use stored procedures for database access

When the database server supports them, use stored procedures for performing access on the application's behalf, which can eliminate SQL entirely (assuming the stored procedures themselves are written properly).

By encapsulating the rules for a certain action - query, update, delete, etc. - into a single procedure, it can be tested and documented on a standalone basis and business rules enforced (for instance, the "add new order" procedure might reject that order if the customer were over his credit limit).

For simple queries this might be only a minor benefit, but as the operations become more complicated (or are used in more than one place), having a single definition for the operation means it's going to be more robust and easier to maintain.

Note: it's always possible to write a stored procedure that itself constructs a query dynamically: this provides no protection against SQL Injection - it's only proper binding with prepare/execute or direct SQL statements with bound variables that provide this protection."

Think he meant "remove SQL entirely from the front-end/application" as stored procs are themsel;ves written in SQL. And he's right that Dynamix SQL alone is not sufficient, as bad coding can still allow the exploit. But it does provide some protection. When you define your variables in a stored proc they're the same datatype as the field they're being compared to, so it's not possible to put an AND/OR into a variable that only accepts integers, for example. Perhaps the author confused Dyanmic SQL with queries built "dynamically" by concatenating strings... but ideally (and I've yet to see an "ideal" db design) you shouldn't *have* to do either. Most of the logic need can also be handled by things like a CASE in your SELECT or a server-side cursor (loop), but unfortunately developers proficient with SQL are a dying breed.

Last edited by Crito; 12-22-2005 at 09:36 AM.
Old 12-22-2005, 10:41 AM   #9
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 8,508
Blog Entries: 4

Rep: Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954Reputation: 2954
Another simple technique, often overlooked, is to call a PHP (or other) function that will sanitize the input, converting metacharacters that need to be "escaped" into their escaped-form ... {'} becomes {\'} and so-on. All sorts of characters cannot appear in a quoted string in their unmodified form.

The root cause of these problems is simply that the programmers never sanitized the input-strings; never really tested the code; never really thought like a nasty (or even careless) person. Long before such issues caused the site to be hijacked, they would have caused it to fail.

There was for many years a commercial site that would produce an SQL error message (including the complete query-string!) if you omitted a value in one field. It's not uncommon...


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Migrating from MS-SQL server to My-SQL emailssent Linux - Networking 2 02-07-2005 02:20 PM
my sql................ apenguinlinux Programming 2 01-24-2005 10:39 PM
Which SQL is suitable for EMbedded SQL on C? hk_michael Programming 4 01-10-2005 05:07 PM
Is SQL Injection traceable and is it a serious offence? novkhan Linux - Security 2 05-21-2004 10:26 PM
My SQL and M$SQL ikw38 Linux - Software 2 07-03-2003 01:45 PM > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 06:53 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration