SQL injection and solution - sql

Question

SQL injection and solution
What would be the solution?

Answer 1

you should do prepared SQL statement, and the way to do it differs from one programming language to another. regarding what could he do with SQL injection worst case he could dump the DB content. how to prevent it check the following link http://www.marcofolio.net/features/how_you_can_prevent_an_sql_injection.html

Answer 2

I guess your best approach is to have your SQL statements as far as possible from your UI, overall you need to understand how a SQL injection happens, so for example, you have a query like this:
select name from users where password='ValueFromTxtPassword' --not good approach
an attacker could write this in you TxtPassword field:
0 or 1=1; select * from creditcards --
this effectively makes a valid query like this:
select name from users where password=0 or 1=1; ======> valid query is always true
select * from creditcards -- ===> makes another query and ignores the rest of the lines in your SQL statement, giving you all the records from your creditcard table
So, to avoid that, you can have a stored procedure like
authenticate(username, password) --Stored procedures force you to pass only the needed info
another good approach is to use a 'query' complex object that builds up your sql statement according to your needs
public class query{
public List<column> projections {get; set;} //use this to build your SELECT
public List<condition> filters { get; set;} //use this to build your WHERE
public List<condition> sorting { get; set;} //use this to build your ORDER BY
}
using ORMs like Hibernate usually force you to build this query complex objects because you are not able to map table maps but only return domain objects.

Answer 3

It's not good. You need to protect the SQL queries to client requests. If it's too hard then the best way if you'll use a framework. For example if You familiarly for PHP then you can use Symfony or Zend.

Answer 4

1) Filter Input- Stop believing your users: The biggest threat to the application is from its users. Users need not be well mannered and obedient as you are expecting. Some users have really bad intentions and some simply try to test their hacking skills. Whatever code you are going to write, write it using the best practices and consider the security aspects of it. Validate every field in the form
2) Use database wrapper classes or PDO –
Database wrappers or PDO (in PHP) can reduce the risk of direct access of the input values to the database.
Prepared statements can be used along with PDO as shown below.
http://www.itechnicalblog.com/what-is-a-sql-injection-and-how-to-fix-it/
enter link description here

Answer 5

A server-side solution would be to have the database server reject unexpected SQL queries (queries whose parse-tree hash is not in a set of known hashes).
Basically, the idea is fairly simple and others have had similar thoughts.
https://www.researchgate.net/profile/Debabrata_Kar/publication/261318459_Prevention_of_SQL_Injection_attack_using_query_transformation_and_hashing/links/545cf9180cf295b5615e6452.pdf
My idea is just slightly different in that I suggest moving the parsing from the client to the server where there is already a parse step.
Algorithm:
1) On the database server, after parsing the SQL, walk the parse-tree and produce a string of opcode tokens. Compute a MD5 hash on the string.
2) This hash then represents the shape of the parse-tree. For a web-application, the number of unique SQL queries will be fairly small.
3) The database server keeps a per-user list of valid hashes and warns/fails on new hashes.
4) Add a function to the API to pre-load this list of hashes and call this function with a list of known hashes at the web application startup.
The way SQL Injection works is to insert characters resulting in a different parse-tree than the one envisioned by the programmer.
The parse-tree hashes can detect unexpected parse-trees.
The downside of this proposal is that no current database system does it. The closest I have seen so far is Postgresql which keeps a hash of the parse tree in pg_stat for informational purposes.