I'm storing a JSON encoded array of integer indexes => integer values in a cookie.
Obviously cookies can be easily manipulated like any other user input, so here's my cookie getter validation:
if ($_COOKIE['myCookie']) { //if cookie exists
$myCookie = json_decode($_COOKIE['myCookie'], true);
if (!is_array($myCookie)) { //in case decoding fails or bad cookie
$myCookie = array(); //sets it as empty array
}
} else { //if cookie doesn't exist, uses an empty array instead
$myCookie = array();
}
Then before using any of the values, I check if it exists in the array and test against a list of white-listed values - this part seems pretty safe but I'm posting it as it's part of the validation:
if (!empty($myCookie[$index])) { //checks if index exists and is truthy
if ($myCookie[$index] !== 1 && $myCookie[$index] !== 2) { //values whitelist
die('Hacking attempt through cookies exploit.');
}
//use the cookie data now
}
Back to the question, is it safe to call json_decode directly on the cookie? Can users manipulate the cookie to run arbitrary code?
I've been reading around many topics on SO so far and what I found is that unserialize() is dimmed unsafe because it calls constructors, but json_decode is technically safe. I've read through their php.net pages but those do not address security directly.
My addon is reaching the live beta very soon, so I'm wondering if calling json_decode directly on the cookie is safe enough or if I should run some type of validation before calling json_decode. I could run a preg_match too, but as I'm testing against a whitelist of values before using them, there should be no problem unless json_decode somehow runs arbitrary code, which it doesn't, right?
I know that json_encode returns NULL if it's not valid JSON, but I'm wondering if this is the right approach or should I add some kind of validation before calling json_decode?
Using json_decode to decode the user input directly has no security problem.
It is just string parsing, won't do any string eval.
json_decode in php is like JSON.parse in javascript, and both of them could be used directly on the user input, they are safe at the decoding time.
But after being decoded, you have to validate the data for your requirement.
Insomuch as json_decode is correctly implemented, it should be safe to just use without extra pre-processing (in fact, that might be worse, given that you might have bugs in your pre-processor).
json_decode will fail if the data is not in json format and otherwise will return an nice array for you to work with. Like Itay said if somebody can exploit this he almost deserves to get in. json_decode doesnt suffer from the risk of sql so I'd say you're fine doing this.
Just make sure you clean anything (or white list, like you already are) before incorporating it in a query.
Related
I want to base64_encode the parameters I send over the url.
Send:
<?php
$product = array("productID"=>"13776", "name"=>"something", "availability"=>"1000");
$url_details = "?id=" . base64_encode(http_build_query($product));
?>
Details
Receive:
<?php
$details = base64_decode($_GET["id"]);
// $product = what is the best way to reconstruct the array from $details?
?>
<p>
Name: <?php echo $products["name"]; ?>
...
</p>
The encoding destroys the array, is there a convenient way to make an associative array out of the string again?
(the encoded url is not sensitive information, but I still do not want it to be flat out readable in the url. If there is a better way to pass this data between pages than what I am doing, let me know)
parse_str is the inverse of http_build_query, so to recover your data:
parse_str(base64_decode($_GET["id"]), $details);
Note that parse_str is harmful if called with only one argument.
And as an aside, you may not want to put this kind of information into the URL to begin with, since it can be easily disclosed to third parties, via the Referrer header, for instance.
You can serialize() your array:
<?php
$product = array("productID"=>"13776", "name"=>"something", "availability"=>"1000");
$url_details = base64_encode(serialize($product));
And then, on your end page unserialize() it:
<?php
$details = unserialize(base64_decode($url_details));
Demo
However you need to be careful and do thorough checking of what you're receiving, since unserialize() will execute arbitrary code sent by the client. For example, I can serialize() my own array, then base64_encode() it, and pass it to the URL in the id parameter, and I can do pretty nasty stuff. So definitely check what you're getting in the request!
From the manual:
Warning
Do not pass untrusted user input to unserialize() regardless of the
options value of allowed_classes. Unserialization can result in code
being loaded and executed due to object instantiation and autoloading,
and a malicious user may be able to exploit this. Use a safe, standard
data interchange format such as JSON (via json_decode() and
json_encode()) if you need to pass serialized data to the user.
Here's a comprehensive article on the matter. Give it a read!
As the manual says, you can also probably accomplish what you're trying to do with json_encode() and json_decode(), though the same warning remains, check that what you're getting is what you're supposed to get and sanitize it.
So... I need to save a large-ish amount of data from a platform with an excruciatingly limited amount of memory.
Because of this, I'm basically storing the data on my webserver, using a php script to just write JSON to a flat file, because I'm lazy af.
I could go to the trouble of having it store the data in my mysql server, but frankly the flat file thing should have been trivial, but I've run up against a problem. There are several quick and dirty workarounds that would fix it, but I've been trying to fix it the "right" way (I know, I know, the right way would be to just store the data in mysql, but I actually need to be able to take the json file this produces and send it back to the platform that needs the data (In a ridiculously roundabout fashion), so it made sense to just have the php save it as a flat file in the first place. And It's already working, aside from this one issue, so I hate to reimpliment.
See... Because of the low memory on the platform I'm sending the json to my server from... I'm sending things one field at a time. Each call to the php script is only setting ONE field.
So basically what I'm doing is loading the file from disk if it exists, and running it through json_decode to get my storage object, and then the php file gets a key argument and a value argument, and if the key is something like "object1,object2", it explodes that, gets the length of the resulting array, and then stores the value in $data->$key[0]->$key[1].
Then it's saved back to disk with fwrite($file, json_encode($data));
This is all working perfectly. Except when $value is a simple string. If it's an array, it works perfectly. If it's a number, it works fine. If it's a string, I get null from json_decode. I have tried every way I can think of to force quotes on to the ends of the $value variable in the hopes of getting json_decode to recognize it. Nothing works.
I've tried setting $data->$key[0]->$key[1] = $value in cases where value is a string, and not an array or number. No dice, php just complains that I'm trying to set an object that doesn't exist. It's fine if I'm using the output of json_decode to set the field, but it simply will not accept a string on its own.
So I have no idea.
Does anyone know how I can either get json_decode to not choke on a string that's just a string, or add a new field to an existing php object without using the output of json_decode?
I'm sure there's something obvious I'm missing. It should be clear I'm no php guru. I've never really used arrays and objects in php, so their vagaries are not something I'm familiar with.
Solutions I'm already aware of, but would prefer to avoid, are: I could have the platform that's sending the post requests wrap single, non-numeric values with square braces, creating a single item array, but this shouldn't be necessary, as far as I'm aware, so doing this bothers me (And ends up costing me something like half a kilobyte of storage that shouldn't need to be used).
I could also change some of my json from objects to arrays in order to get php to let me add items more readily, but it seems like there should be a solution that doesn't require that, so I'd really prefer not to...
I skim through your post.
And I know this works for StdClass :
$yourClass->newField = $string;
Is this what you wanted ?
OK so... ultimately, as succinctly as possible, the problem was this:
Assuming we have this JSON in $data:
{
"key1":
{
"key2":["somedata","someotherdata"]
}
}
And we want it to be:
{
"key1":
{
"key2":["somedata","someotherdata"],
"key3":"key3data"
}
}
The php script has received "key=key1,key3&value=key3data" as its post data, and is initialized thusly:
$key = $_POST["key"];
$key = explode($key,",");
$value = $_POST["value"];
...which provides us with an array ($key) representing the nested json key we want to set as a field, and a variable ($value) holding the value we want to set it to.
Approach #1:
$data->$key[0]->$key[1] = json_decode($value);
...fails. It creates this JSON when we re-encode $data:
{
"key1":
{
"key2":["somedata","someotherdata"],
"key3":null
}
}
Approach #2:
$data->$key[0]->$key[1] = $value;
...also fails. It fails to insert the field into $data at all.
But then I realized... the problem with #2 is that it won't let me set the nonexistent field, and the problem with approach #1 is that it sets the field wrong.
So all I have to do is brute force it thusly:
$data->$key[0]->$key[1] = json_decode($value);
if (json_decode($value) == NULL)
{
$data->$key[0]->$key[1] = $value;
}
This works! Since Approach #1 has created the field (Albeit with the incorrect value), PHP now allows me to set the value of that field without complaint.
It's a very brute force sort of means of fixing the problem, and I'm sure there are better ones, if I understood PHP objects better. But this works, so at least I have my code working.
Disclaimer: I am fairly new to using json.
I am trying to use php to receive json data from an iPAd application. I know how to convert json to an array in php, but how do I actually receive it and store it into a variable so it can be decoded?
Here are a couple examples that I have tried based on google and stackoverflow searches.
$json_request = #file_get_contents('php://input');
$array = json_decode($json_request);
AND ALSO
$array = json_decode($_POST['data'], true);
Any suggestions?
You have the basic idea already.
you should test that the value is set and also strip extra slashes from the incoming string before trying to parse it as JSON.
if(isset($_POST['data'])){
$array = json_decode(stripslashes($_POST['data']),true);
//$array now holds an associative array
}//Data Exists
It also would not be a bad idea before you start working with the array to test that the call to json_decode() was successful by ensuring that $array isn't null before use.
If you do not fully trust the integrity of the information being sent you should do extended checking along the way instead of trusting that a given key exists.
if($array){ // Or (!is_null($array)) Or (is_array($array)) could be used
//Process individual information here
//Without trust
if(isset($array['Firstname'])){
$CustomerId = $array['Firstname'];
}//Firstname exists
}//$array is valid
I in-particular like to verify information when I am building queries dynamically for information that may not be required for a successful db insert.
In the above example $_POST['data'] indicates that what ever called the PHP script did so passing the JSON string using the post method in a variable identified as data.
You could check more generically to allow flexibility in the sending method by using the $_REQUEST variable, or if you know it is coming as via the get method you can check $_GET. $_REQUEST holds all incoming parameters from both get and post.
If you don't know what the name of the variable coming in is and want to play really fast and loose you could loop over the keys in $_REQUEST trying to decode each one and use the one that successfully decoded (if any). [Note: I'm not encouraging this]
I am looking to have a list of arguments passed across in an a URL.
$url['key1']=1;
$url['key2']=2;
$url['key3']=3;
$url['key4']=4;
$url['key5']=5;
$url['key6']=6;
$url['key7']=7;
Please Note I am trying to pass this in the URL in 1 GET variable. I know this would be better done by ?key1=1&key2=2&key3=3...etc but for reasons that are too complicated to try and explain they can't be in this format.
Any suggestions how I can convert this array into something that can be passed as 1 get var in a URL string?
Thanks in advance.
You can use json_encode() or serialize()
$myUrl = 'http://www.example.com/?myKey=' . urlencode(json_encode($url));
or
$myUrl = 'http://www.example.com/?myKey=' . urlencode(serialize($url));
Using json_encode will usually give you a shorter string, but very old PHP version might not have the json_decode function available to decode it again.
The final way would be to create your own custom encoding... it could be as simple a pipe-separated values: key1|1|key2|2|key3|3
This would give you the best option for a short URL, but is the most work.
Try http_build_query:
$url['key1']=1;
$url['key2']=2;
$url['key3']=3;
$url['key4']=4;
$url['key5']=5;
$url['key6']=6;
$url['key7']=7;
echo http_build_query($url);
//echos key1=1&key2=2&key3=3&key...
What it does is converting an array into a query string using the keys and automatically takes care of url-encoding.
EDIT:
Just read your additional requirement that it should be just one variable. So nevermind this answer.
If your problem was the proper encoding though you might want to give this another try.
Hope that helps.
The recommendation to use serialize() is fine. If space is an issue, then use a combination of bzcompress() and serialize().
However, there's a security considering that hasn't been brought up, and that's that the end user (who can see and edit this url) could manipulate the data within it. You may think it's difficult, but most of the PHP-attacking worms in the wild do this to some degree or another.
If letting the user directly manipulate any of the keys or values (or replacing it with an integer, or an object, or anything else), then you should protect your script (and your users) from this attack.
A simple solution is to simply use a shared secret. It can be anything; just so long as it's unique and truly secret (perhaps you should randomly generate it at install-time). Let's say you have in your config file something like this:
define('SECRET', 'unoqetbioqtnioqrntbioqt');
Then, you can digitally sign the serialized data created with: $s=serialize($m) using $k=sha1($s.SECRET) and make the url value $k.$s
Then, before you unserialize() do this:
$v=substr($input,0,40);
$s=substr($input,40);
if ($v != sha1($s.SECRET)) { die("invalid input"); }
$m=unserialize($s);
This way, you know that $m is the same as the original value that you serialized.
If you like, you can use the following drop-in replacements:
define('SECRET','buh9tnb1094tib014'); // make sure you pick something else
function secureserialize($o) {
$s=serialize($o);
return sha1($s.SECRET).$s;
}
function secureunserialize($i) {
$v=substr($i,0,40);$s=substr($i,40);
if ($v!=sha1($s.SECRET)){die("invalid input");}
return unserialize($s);
}
You could serialize them as key-value pairs when constructing the URL, putting the resultant serialized value in a single $_GET variable (e.g. data=sfsdfasdf98sdfasdf), then unserialize the $_GET["data"] variable. You'll need to use urlencode to make sure the resultant serialized values are URL-safe. Make sure you watch out for maximum URL lengths - 2083 characters in IE.
However, unless you really can't use key-value pairs in URLs (per your question), key1=foo&key2=bar... is definitely the way to go.
If you don't mind dropping the key names, you can use
http://example.com?url[]=1&url[]=2&url[]=3
EDIT Keeping the key names:
http://example.com?values[]=1&values[]=2&values[]=3&keys[]=1&keys[]=2&keys[]=3
Then in your PHP script:
$url = array_combine($_GET['keys'], $_GET['values']);
Could you solve your problem by saving the data as a HTML cookie? That way you don't have to modify the URL at all.
If you know the values in advance, you can set them from the server side when you send the user the page with your target link on it.
If you won't know the values until the user fills out a form it can still be done using JavascriptL When the user clicks the form submit you can set multiple cookies by making multiple javascript calls like:
document.cookie = 'key1=test; expires=Mon, 7 Sept 2009 23:47:11 UTC; path=/'
The security model might give you some trouble if you are trying to pass this data from one domain to another though.
I'm trying to store a complex object here and am doing that by serialising the object running a mysql_real_escape_string on it and inserting it into a mysql database.
However when I retrieve it running a sql query - I'm using Zend frameworks Zend_DB_Table here but anyway - and when I try to stripslashes and unserialize I dont get my object back. I've tried to just unserialize without stripping slashes and all but nothings working.
UPDATE
This is weird. I made a simple page which just unserializes a serialised object. If I take the serialized string as it is retrieved from the database and unserialize it via this other page which just has an unserialize() on it - it works perfectly and I get my object back. However in the code where ironically I'm retriving the string and I run the exact same unserialize option there ,its not working!
So basically there is nothing wrong with the serialized string - for some weird reason it won't unserialize it in my application but it unserializes somewhere else, it makes no sense.
You probably need to run it through base64 encoding first:
$safe_string_to_store = base64_encode(serialize($data));
Then to get it back out:
$date = unserialize(base64_decode($safe_string_to_store));
Try that and let us know if it works.
(and dont run stripslashes on it - there is no need to)
You shouldn't run stripslashes on it - the database will give you back the right string to put into unserialize.
Make sure you have notices turned on and echo the string before you unserialize it - does it look right?
You should be able to just do the following:
Assuming MyTable is your instance of Zend_Db_Table_Abstract:
$t = new MyTable();
$n = $t->createRow();
$n->serializedfield = serialize($data);
$n->save();
and let Zend DB take care of the escaping for you.
If you're doing it via an insert(), you shouldnt need to do anything either (the above uses insert())
Otherwise use $db->quoteInto() like
$db->quoteInto('INSERT INTO mytable (serializedfield) values (?)', serialize($data));
I strongly recommend you to use json_encode instead of serialize. Some day you will find yourself trying to use that data from another place that is not PHP and having it stored in JSON makes it readable everywhere; virtually every language supports decoding JSON and is a well stablished standard. And is even worse if you base64 it, you also make the serialized content unreadable from your database console client.