I am using mysqli prepared statements and bound variables.
Then to prevent sql injection, am I need to do anything else(eg: data type validation, filtering, sanitize, string escape etc ) with user input ?
Is there any other way of attacking MySql database other than Sql Injection ?
To prevent SQL injection you have to format your query properly.
Every literal that have to be added to the query dynamically, have to be properly formatted.
Not only data literals like strings and numbers but all of them, including operators and identifiers.
The only proper way to make values formatted is prepared statements.
For the identifiers and operators you will need also filtering, to let only allowed ones into query.
Whatever user input should not be involved at all. It's destination, not source that matters.
Is there any other way of attacking MySql database other than Sql Injection ?
sure thing. But the topic is too broad to make you secured by means of a forum post. Better hire a DBA.
Related
According to Node.js' mysql package documentation:
In order to avoid SQL Injection attacks, you should always escape any user provided data before using it inside a SQL query. You can do so using the mysql.escape(), connection.escape() or pool.escape() methods.
I cannot find any documentation / reference to using prepared statements with mysql, except for in a reference to using '?' characters. It states the following:
Alternatively, you can use ? characters as placeholders for values you would like to have escaped...
This looks similar to prepared statements in MySQL, however it really
just uses the same connection.escape() method internally.
From my experience with talking to other developers, the general consensus in the developer community is that prepared statements are the ONLY safe way to perform mysql queries from Node.js however, as you can see with the mysql package, there is no obvious support for prepared statements. However, it is indicated that their method for avoiding SQL injection is via the usage of the escape functions.
My Question:
Are the escape functions in the mysql package sufficient enough to securely query a mysql database (without the use of prepared statements)?
Escaping is actually just as safe as using parameterized queries, if you do it consistently.
But it's recommended to use parameters because it makes your code simpler. Therefore developers are probably more likely to do it.
If the Node.js library makes it just as convenient as parameters, but implements it internally by modifying query strings, replacing the ? marks with the parameter values, then you're good.
For what it's worth, Python's MySQL driver does this too, and also PHP's PDO extension when the "emulate prepares" option is in effect. As long as those libraries are well-tested, it should be safe.
FWIW, both escaping and parameters is limited in SQL injection prevention, because in both cases, you can only protect values that you would combine with your SQL query. You cannot protect identifiers (like table names, or column names), or SQL keywords, or expressions, etc. In these cases, just be careful that you have vetted any dynamic content before combining it with your SQL query.
See also:
Preventing SQL injection in Node.js
Difference between real_escape_string and prepare()?
I mean for security. Does converting to/from JSON objects help any with MySQLi?
My intention is to use MySQLi statements and send/receive everything as JSON objects (in order to in the future allow Android to use the same calls and queries.)
My only focus on this question is the security side of it. Do I need prepared statements if I'm converting everything to and from JSON objects for a MySQL database.
It doesn't matter what kind of data you are storing in the database. To prevent against SQL injection you need to parameterize all variable input in your SQL. It makes no difference where this data comes from. It doesn't matter what it is.
There is no reason not to use prepared statements. Seriously, not a single reason why you should not use prepared statements 100% of the time, even for constant queries.
Remember though, that prepared statements do not protect against SQL injection. Only the parameters help. Use placeholders in your SQL and bind the data separately. Do this always.
I need to convince someone that he needs to sanitize the user input in addition to the user of stored procedures. well I know I sound crazy but I do not feel comfortable enough with store procedures only. My first reason is that I am able to cause errors in the stored procedure but because of the fact that the application itself handles errors such that error messages are coded it is difficult for outside to understand the what there are. but I still think that this is not secure.
Does any one has a suggestion ? or am I wrong to doubt stored procedures?
No it's not safe on it's own. You can also do in a stored procedure something like this:
SET #sql = 'Select * from products where name like ''' +#spinput+''' ';
exec(#sql);
With the wrong value in #spinput you can inject code.
However you can write stored procedures that are safe against sql injection.
Even if you use proper parameters, you can still mess with the database. You could insert a script that goes in as a parameter, but when it's displayed on a web page starts doing something it shouldn't. Use parameters to ensure your database is used as intended, but also sanitize the output later - never trust user-entered data.
Using stored procedures normally protects against SQL injection, but is not the only solution to prevent SQL injections, and it doesn't protect against all forms of SQL injection.
It's not the stored procedure itself that makes the big difference, but parameterised queries, which is the most common way to call a stored procedure. By putting the values used by the query in parameters, you let the database library handle them instead of having to escape them correctly yourself.
It's possible to write code that is safe against SQL injections without using parameterised queries, but it's difficult. You have to know exactly what characters you need to escape in a string for the specific database that you are using, and if you get it wrong you are pretty much as unprotected as if you didn't know about SQL injections at all.
If you use parameterised queries, then the step of sending the values into the database is safe from SQL injection, but the query itself might not be. If the query generates and executes SQL code itself, you have the same problem with escaping strings correctly. It's however not so usual to create SQL code in the SQL code, and if you do it you are very aware of that you are doing it.
I have been looking up SQL injection lately and what they are, what they do and how to stop them. Most place talk about username stored by users in select stamens causing problems such as 'OR 1 but if I was to only use a auto incremented id to select information from a database and not a user input value would this also prevent sql injections?
SQL Injection applies specifically to the shape of the query - it says nothing about queries that can accidentally leak information from other means.
SQL injection is a code injection technique, used to attack data driven applications, in which malicious SQL statements [or expressions] are inserted into an entry field for execution..
Using placeholders eliminates SQL Injection1,
but..
..just because a system is free from SQL Injection does not mean that it is safe from other vulnerabilities.
For instance, imagine this query, where #OWNER represents a placeholder.
select *
from emails
where owner = #OWNER
This query is free from SQL injection, but if an attacker can specify an arbitrary "OWNER" value, then they can access someone else's email - oops! This is just a security vulnerability; not SQL Injection.
1 Use placeholders for all data that comes from variables.
It doesn't matter if it is from the user or not. It doesn't matter if the value is guaranteed to be an integer (even one from an auto-increment column) or not. Just use placeholders consistently - then you'll have cleaner queries and more time to focus on other problems.
Everyone who is looking up on SQL injection, have to understand that there is no way to exploit a non-existent injection. On the other hand, once injection is possible, there is potentially infinite number of possible exploits.
Means one should never care of particular exploits. But always concentrate on making injection impossible.
Is there a list of SQL injection methods which can't be protected with just using mysql_real_escape_string(); with utf8 encoding?
For integer, I'm using intval();
Is it secure enough?
For those who think I want to get "tutorial" to hack anyone: No, I won't. I just want to know how to make my applications more secure, and I want to know if they're secured 99% against hackers
If given a valid database connection, mysql_real_escape_string() is supposed to be safe for string data under all circumstances (with the rare exception described in this answer).
However, anything outside a string, it won't escape:
$id = mysql_real_escape_string($_GET["id"]);
mysql_query("SELECT * FROM table WHERE id = $id");
is still vulnerable, because you don't have to "break out" of a string to add an evil additional command.
There are not many sql injection methods. They are always due to input not being sanitized and escaped properly. So, While mysql_real_escape_string() will make any string safe to be included in a database query, you should follow the following avoidance techniques to protect your data and users from sql injection.
Never connect to the database as a superuser or as the database owner. Use always customized users with very limited privileges.
Check if the given input has the expected data type.
If the application waits for numerical input, consider verifying data with is_numeric(), or silently change its type using settype()
Quote each non numeric user supplied value that is passed to the database with the database-specific string escape function. So mysql_real_escape_string() will make all strings safe to be included in an SQL query to a mysql database
You could also learn to use stored procedures and prepared statements which tend to be very safe but have other impacts
See also: PHP page on SQL injection
There are many things that may not get protected by standard methods (e.g. string escaping, int casting), also depending on the version of software you use. For example, utf-8 is quite an issue by itself, as a tiny example (among many) you should make sure the request is valid utf-8 (or convert it into utf-8). See an example.
As the undead bane of websites, I think that MySQL injection protection cannot be squeezed into a single SO answer, hence I'm including these links as general starting points.
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
And also : Search for mysql injection utf8