Do I have to sanitize user input with prepared SQL statements? - php

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.

Related

How to turn off multiple statements in postgres?

I think it is a good idea to turn off multiple statements like this to prevent this type of sql-injection.
Example of multiple statements:
$query = "UPDATE authors SET author=UPPER(author) WHERE id=1;";
$query .= "UPDATE authors SET author=LOWER(author) WHERE id=2;";
$query .= "UPDATE authors SET author=NULL WHERE id=3;";
pg_query($conn, $query);
Is it possible to prevent multiple statements in posgresql settings or for example using posgre's related PHP code?
Or maybe there is any way of parsing SQL queries before passing them to pg_query in order to detect queries which consists of more than one statement?
No, there is no way to disable multi-statements in PostgreSQL. Nor, as far as I know, is there any way to do so in the PHP Pg or PDO PostgreSQL drivers.
They aren't your problem anyway. Disabling multi-statements might be a (slight) SQL injection harm mitigation, but it wouldn't be any real protection. Consider writeable CTEs, for example, or qualifier removal attacks.
Instead, protect your code properly in the first place. Rigorously use parameterized statements instead of string concatenation, so there's no SQL injection opportunity in the first place. It's not hard to avoid SQL injection, you just have to be a little bit sensible with your coding practices.
Use PDO or pg_query_params for all queries, and make sure you don't concatenate text that's come from outside the immediate scope directly into SQL text, use a parameter. Even if it comes from elsewhere in the application and is considered "trusted" ... later refactoring might change that.
I think it is a good idea
It is, actually, not.
You have to prevent injections, not multiple queries.

Will this SQL injection prevention work in theory?

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.

Sql injection prevention techniques still vulnerable?

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.

How do I safely store suspected SQL injection attacks in a database?

How would I go about storing potential SQL injection attacks in a database?
Assume first that I have detected a potential attack, and have the offending attack string in a variable and would like to add it to a table containing a log of suspicious events.
What would I need to do to safely insert these strings into a database so that no errors would be produced?
I have a feeling that it will be something along the lines of htmlspecialchars and mysql_real_escape_string... but I wanted to throw it out there to see if anybody else had any ideas!
One thought was to store the attack as an encoded base64 value, but that seems a bit hackish...
FYI, I am writing the application in PHP :)
Any responses would be greatly appreciated!
Always use parameterized queries. If you are using parameters, you don't need to rely on escaping strings and your query will always do exactly what you intend.
e.g.:
$statement = $db->prepare('INSERT INTO table_name (field_name1, field_name2) VALUES (:value, :value2)');
$statement->execute(array(':value' => $value, ':value2' => $value2));
See documentation for PDO prepare here:
http://www.php.net/manual/en/pdo.prepare.php
Use mysqli prepared statements to store the queries, it's the safest method to avoid sql injection. If you're going to display them via a web interface and concerned about XSS/CSRF attacks, use htmlspecialchars() before displaying them.
The same way you are storing any other data.
There is nothing special in storing SQL injection attacks, whatever you call it.
Like Steve Mayne said ... please use php PDO connection with prepared statements. It's the safes right now . Don't user mysql_connect() and subfunctions anymore because it's old and you cannot fully benefit of new mysql / sql / etc .. funcitons .
All I would do is run it though a simple encryption.
Then when you want to show the suspected sql, you would just decrypt it.
This should insure the suspected sql statement does not get executed on your db.

How to protect this SQL in a PHP from SQL Injection?

Can someone give me a little help with this? i have three PHP SQL querys, and i have to protect from SQL Injection. I am searching on google but i think is too hard for me, because it's combinated with PHP and i dont know munch about PHP and lees about SQL
if someone can give me the code protected I'll be grateful
the code:
$q=mysql_query("SELECT * FROM user where email= '".$_REQUEST['email']."'",$link );
$q=mysql_query("UPDATE user SET mobilePhone='".$_REQUEST['mobilePhone']."', fullName='".$_REQUEST['fullName']."' WHERE email='".$_REQUEST['email']."'",$link );
$q=mysql_query("UPDATE user SET mobilePhone='".$_REQUEST['mobilePhone']."' , fullName='".$_REQUEST['fullName']."', password='".$_REQUEST['password']."' WHERE email='".$_REQUEST['email']."'",$link );
Well, the simple way would be to wrap each of the $_REQUEST vars in mysql_real_escape_string()...
$q=mysql_query("SELECT * FROM user
where email= '".mysql_real_escape_string($_REQUEST['email'])."'",$link );
The better way would be to use prepared queries. There are plenty of tutorials available on how to do it, so I'll leave that to you...
The least you can do to prevent SQL injection is to use mysql_real_escape_string function before any variables that go into your queries.
The best you can do is to use prepared statements to avoid SQL injection.
The parameters to prepared statements
don't need to be quoted; the driver
automatically handles this. If an
application exclusively uses prepared
statements, the developer can be sure
that no SQL injection will occur
(however, if other portions of the
query are being built up with
unescaped input, SQL injection is
still possible).
Suggestion:
To be further on safer side, you should always use proper array eg $_POST or $_GET instead of $_REQUEST for security reasons.
Take a look at PHP's mysql_real_escape_string

Categories