I have a simple feedback form PHP script that I would like to enhance by adding the $_SERVER[HTTP_USER_AGENT] data to the row in the database that I'm saving.
I keep getting parse errors when I try a simple insert, passing '$_SERVER[HTTP_USER_AGENT]' as a typical string. Should I bundle it in some way, so that the characters used in that Server variable are not triggering such errors?
(The INSERT query runs fine without that field, btw.)
Thanks.
My bet is that there is a ' in the user agent strings that are causing the parser error.
The User-Agent string returned to PHP is under control of the local browser, which means that you need to treat it no differently from regular user input. A malicious user or a user who has been infected by a virus/trojan/worm could change the user agent string to cause an SQL injection attack. At the very least, you need to escape it (with mysql_real_escape_string() for example. My bet is that once you do this, your parser errors should also go away. Better yet, try to move to using prepared statements if your system allows this.
Does
mysql_query("
INSERT INTO
db_table
VALUES (
...
'" . mysql_real_escape_string($_SERVER['HTTP_USER_AGENT']) . "'
...
)");
not work? Can you show us your whole query? What are the exact error-messages?
Without an actual error message it's hard to say what particular problem you encounter with.
But to solve all possible issues,
First of all, you must read an official manual page to make yourself understand PHP strings syntax: http://php.net/types.string
Then, you have to understand Mysql proper syntax. I've explained it already here
Finally, you have to put everything together
like this:
$agent = mysql_real_escape_string($_SERVER['HTTP_USER_AGENT']);
$sql = "INSERT INTO `table` set useragent = '$agent'";
$res = mysql_query($sql) or trigger_error(mysql_query.$sql);
Running your queries this way you'll never have any problem. Or comprehensive error message at least.
Related
I need to pass special symbols through the URL for my MySQL query. For example, I need to have a URL that is something like:
www.example.com/index.php?q=AND name LIKE '%hi%'
When I tried it at first, I got a 406 error. I looked it up and apparently I have to use urlencode() and urldecode(). I put those in, and the 406 error went away, but then I got a MySQL error:
mysql_fetch_array(): supplied argument is not a valid MySQL result resource
Usually when I get these it means the query isn't written properly. So I echoed MySQL query, and everything looked fine. I even removed the urldecode() and hard-coded into a variable what I wanted to be passed to the page, and the MySQL error went away. However, both queries from using urldecode() and not using that are EXACTLY the same, so I'm kind of confused.
I went onto the php.net documentation page for urldecode(), and there was a warning that said something like using _GET and urldecode() together can result in unexpected things, and that _GET already functions as a decoder (or at least that's how I interpreted the wording), so I removed urldecode() but still left in the _GET, and that resulted in the text not being decoded, so I guess I didn't interpret the documentation correctly.
Is urldecode() not compatible with MySQL queries? I'm fairly certain it's an issue with the encode/decode, since I already tested my code with hard-coded info that bypassed the encode/decode, and it worked fine. Maybe the urldecode() is somehow turning the characters into special ones that look the same but are internally different so MySQL can't read them?
Don't do this. It's wrong. Anyone can of course just end the query using a ; and start a new one, deleting everything or reading out users and passwords.
One easy and much better way to do this is to use www.example.com/index.php?q=hi as your URL, then on the server (let's assume PHP)
$queryString = mysql_real_escape_string($_GET['q']);
$query = "AND name LIKE '%$queryString%'";
// Then replace $query for whatever you were using $_GET['q'] for before.
// Feel free to rename my variables what you like!
This way, the user can't mess things up, and the URL looks cleaner. the mysql_real_escape_string function makes the string safe to use in the query by escaping things. Read http://php.net/manual/en/function.mysql-real-escape-string.php for more on that.
If you still aren't convinced this is useful, consider what happens if someone publishes a link that will drop your tables, and then Google crawls it once a week. Your data will be removed any time that Google happens to swing by.
Once you are happy with this technique, read up on mod_rewrite (if using Apache) to clean the URL up even more, mysqli and how it is an improved version of the mysql functions, and finally PHP Data Objects (PDO) which helps to clean the PHP up even more.
Rich has the right general idea, but even better than quoting is to use database parameters. It essentially places a "variable token" into your SQL query, and then passes the variable separately. The query ends up looking something like this:
SELECT ID, VALUE1, VALUE2
FROM MY_TABLE
WHERE VALUE3 = :param
And then in your code, you add a value to substitute in for :param, and then send that to the database alongside your SQL. (On some DB libraries, you'd use a ? instead of a :parametername.) It works better than quoting for three reasons:
First, you can keep the query string constant instead of having to rebuild it every time, which improves performance in your server.
Second, if you send the same constant query to the database multiple times with multiple different parameters, the database engine can cache the query plan, which improves performance on the DB.
Third, when you get used to writing your queries in parameterized style, it becomes natural, especially if you use a query function that takes a parameter list as an argument, so it's hard to get wrong. By contrast, it's easy to forget to quote something, and then you've accidentally opened a security hole in your program.
Exactly how parameterization works depends on the database and the DB access library you're using, but every SQL database supports them. You should look at how it's done for the system you're using. It really is the best way to work with SQL, especially when you have input coming from untrusted sources such as the Internet.
At some point after calling mysql_query() and before calling mysql_fetch_array() you should check that the query didn't return false, and print mysql_error() if it did. e.g.:
$result = mysql_query($query);
if (!$result) {
die(htmlenitites(mysql_error())." when running <pre>".htmlenitites($query)."</pre>");
}
But:
You shouldn't be using php's mysql functions, you should use PDO, and you should use prepared / parameterized queries.
You shuoldn't be letting SQL be passed from the client unless you really trust anything the client might type - e.g. this is for a back-end admin interface, and even then, it's probably bad practice unless you really need it (like you are writing phpMySQLAdmin)
Keep in mind please that I am learning still. I am working on a website and I am simply adjusting and copying codes for the most part, from the existing ones, because that's the easiest way for me to understand them.
I keep getting an sql error that is caused by the use of apostrophes, and I've started putting in the mysql_real_escape_string() for every text field, which solved the individual problems.
Now this is genuinely just me asking for help. Please don't be sarcastic, I am really just trying to learn and this has been the best place to ask questions, so here:
Is there any way of fixing a general setup that will filter out the apostrophes that interfere? Basically anything that will help the site in general be protected against sql injection? Any help would be greatly appreciated :)
The general solution: all the parameters (values) should be passed through prepared statement placeholders
http://nz.php.net/manual/en/pdo.prepare.php
http://nz.php.net/manual/en/mysqli.prepare.php
Is there any way of fixing a general setup that will filter out the apostrophes that interfere?
Definitely NO.
Long time ago there was one, but nowadays it's defamed, deprecated and excommunicated (as it never worked as intended and failed it's purpose).
The problem you face is coming from the fact that SQL query being a program.
So, you have to follow the syntax rules creating this program, just like with any other program language. If you happen to create a PHP program, you have to take care of the irritating apostrophes as well - you can't put it all over the code in random places, but each have to have it's strict syntactical meaning, or - if an apostrophe being part of the data - it have to be properly escaped.
So, it is just syntax issue.
The best way to solve the problem is to separate the code from the data.
Native prepared statements gives you that possibility.
You can create a program - the query itself - and eventually bind some variables to it, so, the program code and the date being sent to the SQL server separately.
That's why prepared statements considered the best way of creating dynamical SQL queries.
But of course you have to bind each variable to it's query explicitly - so, there is no generalized way.
However, you can use some helper to do the binding automatically, so, the code become as concise as
$db->run("SELECT * FROM table WHERE id=?",$id);
which would be both short in writing and perfectly safe at the same time.
Using a data access layer that does this for you is a far better way than manually protecting each query parameter. Not only because it's tedious, but because there'll be that one critical parameter you'll forget eventually.
I used SafeSQL back when I still did PHP -- it's very light and unobtrusive... but plugging it in if you're a beginner might still be a daunting task.
I'm currently working on a php/PostgreSQL/JQuery project, and I'm an absolute beginner in all of these domains. In Php, to connect to my database, best way I found was to include a php
script with user and password in all php scripts that need it, like this.
include('../scripts/pgconnect.php');
With pgconnect.php :
$conn_string = "dbname=mydb user=myuser password=mypass";
$db = pg_connect($conn_string);
if(!$db){
die("Connection à la base impossible -> " . pg_errormessage($db));}
I'm sure all of you security expert will laugh at this, so could you tell me what is the best way to keep user and pass out from prying eyes ?
I found on stack overflow an advice to use env variables, but I don't find it really secure.
PHP is a server-side language. That means that when the requested page is sent back to the client all PHP code is parsed and "removed". As long you're the only one being able to look into your files there is no fear.
Whether you store it in (env) variables or not won't make a single difference.
There's absolutely nothing wrong with this code ;)
Edit:
When you execute an SQL query however, you need to be careful. Often, you use user input (an URL or POST data) to set certain values in a query. For example:
$sql = 'SELECT * FROM `table` WHERE `id`=' . $_GET['id'];
The $_GET['id'] variable is set in the URL (index.php?id=4).
If they change the value 4 to a bit of SQL query, they can pretty much do everything with your database. This is called SQL injection. It's truly the biggest threat of web applications using a database.
There are multiple fixes.
Sanitize the input (make sure that the input doesn't contain SQL syntax)
Prepare statements
Now, I'm not familiar with PostgreSQL, but apparently the PHP module has the ability to send prepared statements. This allows you to send the query with the unknown values as question marks and send the values afterwards.
$sql = 'SELECT * FROM `table` WHERE `id`=?';
// send prepared statement
$value = $_GET['id'];
// send the value
This way the database can tell that the value is no query.
Like I said, I'm not familiar with PostgreSQL, but I'm sure there are some tutorials that will guide you all the way through!
Another edit:
Because I'm a nice guy, I found how to do it! You need to use the function pg_prepare() and pg_execute(). Like this:
// This is a name to allow the database to identify the prepared statement
$queryname = 'my_query';
// Setting up our query with "empty" values
$sql = "SELECT * FROM `table` WHERE `column`='$1' AND `column`='$2'";
// Setting our values to send afterwards
$values = array(
$_GET['first_value'], // The first value that will replace $1
$_GET['second_value'] // The second value that will replace $2
);
$result = pg_prepare($connection, $queryname, $sql); // Send the query to the database
$result = pg_execute($connection, $queryname, array($value)); // Send the values
Last edit (I swear):
If you decide to put your configuration variables in an extern file, lets say configuration.php, make sure that the file ends with the .php extension. If you use a different extension, people might be able to find it and see it in plain text. If the PHP extension is used, they won't be able to see anything because like I said, the PHP is parsed and removed.
I use environment variable to store db authentication information: that is, the host/user/password for the db are in SetEnv commands in the Apache configuration, which appear in $_SERVER.
Why do this?
Development and production environments need different values for these, so having the application read some sort of environment configuration is necessary.
The application code is in a source code repository, which is easily browseable... embedding authentication secrets into it would make those just as widely available.
Environment variables aren't the only solution: for example, including a file that sets up a configuration object of some sort will work too. But most people seem to evolve some system for having the configuration settings (and just the settings) in a single changeable point, separate from the code that uses those settings, which changes on a completely different schedule.
I am pretty new at php, quick note this is an android application that i am calling this script, I am not having the users make up the script lol. There is a series of checkboxs and when they check off certain ones it appends a script to the string builder. i am trying to run a query based on the value of a variable that is being passed in. Usually i do something like this,
mssql_query("UPDATE Userdata SET BrowseScript = '".$_REQUEST['sqlscript']."'
WHERE Userdata.Username = '".$_REQUEST['Username']."'");
and where it says .$_REQUEST[''] I can grab values that i pass in.
But this time the .$_REQUEST[''] is the whole script, so i want something like this
mssql_query($_REQUEST['sqlscript']);
and thats it i want it to run the query thats in that value, The query is correct, but it just will not return any value, I think i may have some type of syntax error or something, like i said i am new to php. Thanks for any help. Also I am not posting the whole code because everything is running ok, i just cant get that query to run. so all i need assistance with is the mssql_query part thanks again.
First of all there is huge security flaw in what you are doing. You should always sanitalize and escape the variables you use in your queries for example using mysql_real_escape_string or prepared statements.
Since you are importing whole script for your query, it could be that quotes are not escaped. You need to put these functions like this before your variables:
mysql_real_escape_string($_REQUEST['your_var']);
Using $_REQUEST in itself instead of proper $_GET or $_POST is vulnerable.
Tell your script to output the contents of $_REQUEST['sqlscript']
echo $REQUEST['sqlscript'];
Check that the output is correct. You might well find that there are some parsing errors, or just that your script is incomplete. Check for quotes (") and make sure the query is valid.
Also, you should never run a script from a request. Imagine if someone browsed to your site and typed
youtsite.com?sqlscript='drop * from tables';
Your entire database would be wiped.
For all that's holy, do not do this!
You do not just use request parameters and put them in SQL queries. You at the very least use mysql_real_escape_string (or whatever the MSSQL equivalent is, never used it). And you most certainly don't accept whole queries in the request and execute them sight unseen.
You're opening huge gaping security holes. Especially if you're new, stop that now before it becomes a habit!
example.com/foo.php?sqlscript=DROP TABLE users
Minimum required lecture: http://www.php.net/manual/en/security.database.sql-injection.php
My partner on a PHP project objects my practice of always sanitizing integer values in dynamic SQL. We do use parameterized queries when possible. But for UPDATE and DELETE conditions Zend_Db_Adapter requires a non-parameterized SQL string. That's why I, even without thinking, always write something like:
$db->delete('table_foo', 'id = ' . intval($obj->get_id()));
Which is equivalent, but is a shorter version of (I've checked the ZF source code):
$db->delete('table_foo', $db->qouteInto('id = ?', $obj->get_id(), 'INTEGER'));
My partner strongly objects this intval(), saying that if $obj ID is null (the object is not yet saved to DB), I will not notice an error, and the DB operation will just silently execute. That's what has actually happened to him.
He says that if we sanitize all the HTML forms input, there's no way an integer ID can possibly get into '; DROP TABLE ...', or ' OR 1 = 1', or another nasty value, and get inserted into our SQL queries. Thus, I'm just paranoid, and am making our lives unnecessarily more complicated. "Stop trusting the $_SESSION values then" he says.
However, for string value conditions he does agree with:
$db->update->(
'table_foo',
$columns,
'string_column_bar = ' . $db->qoute($string_value))
);
I failed to prove him wrong, and he failed to prove me wrong. Can you do either?
Frankly, your partner is off his rocker: sanitizing is cheap, there's no good reason not to do it. Even if you are sanitizing what is in the HTML forms, if those checks somehow break on production, you'll be happy that you have a backup in other places. Also, it promotes a good practice.
You should sanitize—always
Which do you consider more trouble:
Having to track down a bug that didn't cause a failed SQL query.
Having to restore data after you make a mistake in sanitizing the form input and someone exploits that.
Whichever you pick, there's your answer. Personally, I tend to lean towards the paranoid side of things as well.
If anything, you could do both: create your own function that first checks for null and then calls intval(), and use that instead. Then you get the best of both worlds.
I think your partner is wrong - he is not considering separation of concerns between data sanatisation in the model (where your DB code lives) and data validation of your forms.
Normally your form validation logic will be in a separate area of the application to your model. I.e. when adding validators to form elements, and so this is often done in the form class itself. The purpose of this layer of validation code is to validate the input of the form and return the appropriate messages if there is anything wrong.
So I think data sanitisation in the model should be considered separately to this, as the Model is really a standalone class - and thus should be responsible for it's own data sanitisation. Since in theory you should be able to re-use this model elsewhere in your application, the model should not then assume that the sanitisation has been done elsewhere, i.e. as part of the form validation layer.
Your partners main point about not noticing failed SQL queries is not really an issue in practice - it is better to code defensively.
You should of course always sanitize and not rely on HTML forms. What if you change your code and reuse that part with some other data, that came not from HTML form but from webservice or email or any other source that you decide to add a year later? Using intval() here seems to be fine.
form input should idd always be sanitized, but not every variable that goes into a query should be sanitized imo...
The origin of the variable does play a significant role here.
You just have to know if the data used can be trusted...
If you look deeper inside the Zend framework code, you'll see that $db->quoteInto() turns into $db->quote which returns (string) intval($value) with INTEGER as type.
If type is undefined, $db->_quote() is called. Its code is following:
protected function _quote($value)
{
if (is_int($value) || is_float($value)) {
return $value;
}
return "'" . addcslashes($value, "\000\n\r\\'\"\032") . "'";
}
Whatever the calling method used (with or without specifying type), $db->delete is totally safe.
You should first check that the ID is not null. If it is, you know not to do a useless query and continue from there. It does not make sense to track down issues by reading failed SQL queries or so.
All data retrieved from a form should be sanitized. No exceptions. All data retrieved from your system should have already been sanitized before it got into your system, and therefore shouldn't be sanitized when retrieved from the system again.
So, the question is - where is this integer coming from?