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.

http://www.google.com/search?q=sql+i...en-US:official
http://www.google.com/search?hs=IUO&...on&btnG=Search

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.

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...)

So,

"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.

Here's an article I wrote on the subject a while ago:
http://www.dislexik.com/thread320.html

Hope it's useful for you.

http://www.unixwiz.net/techtips/sql-injection.html
http://packetstormsecurity.org/paper...s/zk-blind.txt

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.

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...