What are some common SQL injections I can use?

Question

I am launching my web application and I am trying to test various parts of the system to make sure that they are not suitable for SQL injection.

What are some common SQL injection checks that I can do in text or text areas, etc., that would be a good check for vulnerability?

I am not worried about damaging my data, as I run this on a test bench, so it is ok if it kills my server or database.

I am specifically looking for examples that I can use. I am not looking for common methods, although I hope to cover the various methods with examples that I hope to get.

Answer 1

You may find this site useful.

Answer 2

If you always use parameterized queries or stored procedures, you do not need to do any checks.

Never use dynamic SQL, where you create an SQL command partially based on user input. This is what requires you to disinfect the input.

Answer 3

1) if you use only stored procedures (and call them in a paramatized form) that do not contain dynamic SQL that suits you. 2) if you use only prepared statements in your application language, you are well off.
3) if none of the above, you must run special langauge commands to scan your text, but you don’t say what language the application is.

EDIT
morale of history. never create and execute an SQL command in a string if it contains any text provided by you by the user. pass the specified text to the user sql command as a parameter. SQL injection is the user changing your SQL command in the text that they give you.

Example:

Query="select * from users where userName='"+givenUserName+"'" 

you think Query will be:

  select * from users where userName='your_friend' 

but if givenUserName

 'x';delete from users -- 

As a result, the request will be:

 select * from users where userName='x';delete from users --' 

Answer 4

Just make sure that you use SqlParameter objects everywhere (assuming .net) and not concatenate sql queries and you will be completely protected from SQL Injection.

- Change

Some say that using “stored procedures" matters. This is not true. If you are still building a query to execute the stored procedure dynamically, you risk:

 string sql = "exec spFoo @Hello = '" + helloValue + "'"; 

The only way to execute a query with parameters in a modern language (and especially .net) is to use the SqlParameter class and specify the appropriate data types.

Answer 5

SQL injection checks? How about the lines you should be afraid of?

Much better in the long run

• use .NET SqlParameters (which test themselves for the use of espionage more fully than you would hope for special checks).
• avoid dynamic SQL in your SPs (because even parameterized queries can be triggered by unexpected input if you concatenate strings and then execute them on the back panel)

Answer 6

You can also use parameters in classic ASP using ASP ADO objects.

Here is a small example:

 Dim conn, cmd, SQL, connstr connstr = "My Connection String" SQL = "SELECT Username FROM Users WHERE UserID = @UserID" ' Setup Connection and Command objects Set conn = Server.CreateObject("ADODB.Connection") conn.ConnectionString = connstr Set cmd = Server.CreateObject("ADODB.Command") Set cmd.ActiveConnection = conn cmd.CommandText = SQL ' Create and add the parameter cmd.Parameters.Append(cmd.CreateParameter("UserID", adParamInput, 50, ID)) ' Execute cmd.Execute () 

It has been a long time since I wrote the classic ASP, so this code probably will not work as it is. However, it does provide an idea of ​​how parameters can be used in classic ASP, as well as to prevent SQL injection.

Answer 7

Using parameters is convenient, but not the only way to protect yourself from SQL injection and is not reliable.

If a stored procedure internally dynamically creates and executes EXEC () code in SQL, you lose all this protection. You will also lose this protection if you have one request in the application that includes these fields without using parameters or escaping.

Parameters are not magical, and you can protect yourself simply by using the escape function when building SQL:

 Public Shared Function StringToSql(ByVal s As String) As String If s Is Nothing Then Return "NULL" Return "N'" & Replace(s, "'", "''") & "'" End Function 

Using:

 Sql = "INSERT INTO mytable(name) VALUES(" & StringToSql(username) & ")" 

Boom. As easy as pie. Even takes care of quoting nvarchar.

You can convert dates, numbers, GUID, etc. into strings and pass them to the above function, but you better create separate functions for each data type used.

There is one caveat: you have to use it every time you create a request — every CRUD that includes this data, whether it is produced at the application level or generated dynamically inside a stored procedure.

But you have to do the same to take advantage of the options! So, anyway, you should change your habits and revise your code. There is no way to avoid this (alleged lime).

Answer 8

All that is in it.