In PHP Manual, there is a note:
Note: If this function is not used to
escape data, the query is vulnerable
to SQL Injection Attacks.
Is this enough to anti sql injection? If not, could you give an example and a good solution to anti sql injection?
mysql_real_escape_string is usually enough to avoid SQL injection. This does depend on it being bug free though, i.e. there's some small unknown chance it is vulnerable (but this hasn't manifested in the real world yet). A better alternative which completely rules out SQL injections on a conceptual level is prepared statements. Both methods entirely depend on your applying them correctly; i.e. neither will protect you if you simply mess it up anyway.
As far as i know this is a solid way to avoid SQL Injection attacks.
The best solution is PDO.
If you're using the traditional mysql_query then running all of your data through mysql_real_escape_string() is enough.
Related
Is this considered completely safe?
$stmt = $dbhandler->prepare("update sometable set somefield=:somestring");
$stmt->bindParam(":somestring",$_REQUEST["hack_me_please"],PDO::PARAM_STR);
$stmt->execute();
And if not, what could make it safer? I'm assuming there are unknown vulnerabilities in PDO/MySQL/PHP that may be exploited in the future so I'm wondering if there is anything reasonable I can do make my queries safer, or is it out of my hands with prepared statements.
If it is this easy, why is SQL injection still a thing? Shouldn't it have gone the way of polio?
No, it's not necessary to sanitize inputs when using prepared statement to protect sql injections but you may do it if you want for any other reason.
If it is this easy, why is SQL injection still a thing? Shouldn't it have gone the way of polio?
it's easy for those who knows about it, nothing is easy unless you know it. I believe sql injection doesn't happen a lot nowadays.
Your example is completely safe because it passes the user input parameters separate from the query string. The reason sql injection still exists is because a lot of users still use the deprecated mysql_* api/driver and are unaware of the alternatives. Also, even using pdo or mysqli you can still pass user input directly into the query string instead of binding it separately.
I plan to prevent SQL injections by using the the $variable and route it to a function that will scan the $variable for any sql commands or any attempts of injections. I will also make a list of common sql commands that people would use inject so it would be detected.
Note: I previously asked a similar question but this time I have a theory I managed to think ;)
The simplest and secure way to prevent SQL injection is to use mysql_real_escape_string() on any untrusted data (eg: $_GET or $_POST). It will escape any special characters so the query will be safe.
If you use mysqli, see http://www.php.net/manual/en/mysqli.real-escape-string.php
More about SQL injection and how can you protect yourself against it: http://www.php.net/manual/en/security.database.sql-injection.php
So, your plan it's not the best way to do it. It unnecessarly complicates things.
No. Blacklisting will inevitably give false positives and almost certainly give false negatives.
Use bound parameters and let the database deal with it for you.
If I'm using mysql_real_escape_string and addslashes to avoid sql Injection attack in my website is this two are enough to stop SQL Injection so its 100% sure no one can now attack using SQL Injection?
It depends on your query; if you are talking about just the values you want to insert in your database, mysql_real_escape_string is enough, you don´t need addslashes.
If you also are talking about variable table or column names, you'll need white-lists as well as mysql_real_escape_string will not prevent sql injection on these.
So the answer really is: No, it depends on your query.
Don’t use addslashes at all; it’s not appropriate to protect against SQL injections.
Use mysql_real_escape_string only. And if you need to change the character encoding, use mysql_set_charset.
There isn't any simple "magical" way to prevent SQL injection. mysql_real_escape_string is a good start, using PDO (docs) is even better. Above all of that, you need to look at your database structure, look at your queries, look at your data sources, then think it out. Where is data coming from? What would happen if the data isn't what I expect?
The entire structure of your code should be created with a mind toward controlling the flow of your application logic. The best way to prevent SQL injection is to stay aware and in control of what goes in your database.
You should never use addslashes. Just stick with mysql_real_escape_string
Anyway only the death is sure.
And if you fear the death you should use PDO to be less prone to vulnerabilities
http://it.php.net/manual/en/pdo.prepare.php
Depends on what you mean, I suppose.
The mere use of mysql_real_escape_string will not protect you with 100% certainty, if for no other reason than that it is possible to use it incorrectly.
On the other hand, the correct use of mysql_real_escape_string should protect you as close to 100% as you can get.
On yet some other hand, it is probably easier to make mistakes as a programmer using mysql_real_escape_string compared to a parameterized query.
If you are unsure about your code, perhaps posting it and asking about it specifically may be more educational/useful.
Also: Ditto what others are saying regarding addslashes.
Would it be possible to prevent mysql injection using the gzcompress (and after retrieving it from the database, the gzuncompress) function? Or is there a reason why this would not work? Or is there a reason that this would not be a good idea at all?
This is a bad idea because
Theoretically, there might be a sequence of data that, when compressed, leads to a SQL injection or simply breaks the query
gzcompressed data can't be properly indexed and searched - you'll have a database full of garbled characters
gzcompression is computationally expensive
simply always sanitize your data before entering it into a database, using the string escaping method of your library (like mysql(i)_real_escape_string()) or parametrized queries.
If you do that reliably, no further protection is necessary.
to protect against SQL Injection attacks, use PDO's parameterized queries.
SQL injection can be prevented 1 of 2 ways. You can use parameterized queries or you can properly sanitize values when building your SQL statements.
Now, what you are suggesting will probably prevent malicious injections into the database, but that does not eliminate the possibility that will introduce SQL syntax errors (effectively SQL injection) into your SQL statements.
Also, by using compression functions, it will eliminate the possibility of viewing or searching the contents of the database without going through decompression.
This is a novel approach to avoiding SQL injection, but will cause you more problems than it actually solves. You really need to stick with the tried and true solutions.
OWASP - SQL Injection
Steve Friedl's Unixwiz.net Tech Tips - SQL Injection Attacks by Example
MSDN - SQL Injection
I've seen lots of articles and questions about mysqli, and all of them claim that it protects against sql injections. But is it fool proof, or is there still some way to get around it. I'm not interested in cross site scripting or phishing attacks, only sql injections.
What I should have said to begin with is that I am using prepared statements. That is what I meant with mysqli. If I use prepared statements without any string concatenation, then is it foolproof?
But is it fool proof, or is there still some way to get around it.
No, you have to know what you're doing. If you use bound parameters (A feature that MySqli comes with), you are completely safe from injection type attacks from this attack vector. This doesn't prevent you - the programmer - from embedding strings directly, and thereby enabling injection attacks. You have to use the feature as intended.
Re: Edit
What I should have said to begin with is that I am using prepared statements. That is what I meant with mysqli. If I use prepared statements without any string concatenation, then is it foolproof?
Foolproof is still such a dangerous word. But you are safe from injection attacks for the variables that are bound through prepared statements. This is because bound parameters are transmitted separately from the SQL query. With the "traditional" embed-string approach, the database server needs to parse the input and there are lots of edge cases in that (Charsets etc.). When the data and the query are sent separate, there is no actual parsing going on (At least not parsing of the variable data).
It doesn't protect from sql injections any better than the old mysql module, just makes doing it easier for the developer, who can now use prepared statements instead of calling mysql_real_escape_string.