I'm trying to figure out the best method for encrypting or encoding a URL in my code, this is what it looks like:
$ProUpdateChecker=new PluginUpdateChecker('http://the-url-is-here.com/file.json',__FILE__,'pluginslug');
I want users to not be able to see that URL. I'm not too worried about them being able to decrypt it, I just want a little bit of added security since mostly newbies will be using my script anyways.
What is the best method to accomplish this? I used ionCube to encode the entire code (not just the URL), but it broke some of the functionality.
You could just store the base64 encoded version of the URL in your scripts as a string, and everywhere you use it run it through base64 decode.
$url = base64_decode('VGhpcyBpcyBhbiBlbmNvZGVkIHN0cmluZw==');
Sort of a silly, poor man's option, but you said keep it away from noobs...
If you are just trying to make it so the URL isn't readable ASCII text, try Base64 Encoding:
http://php.net/manual/en/function.base64-encode.php
Related
I have a php page which print different options to the client:
foreach($strings as $i => $string){
echo 'Go with option '.$i.'';
}
I want that the user can retrive the content of $string only on my webpage and cannot by sniffing html code or something like that. The string length is not long, less than 100 chars, and it's dynamic. I would like the url to be "elegant". I tried using
$string = gzencode($string);
$string = urlencode($string);
But it becomes a monster of string. Is there any basic function to encrypt the string? The other idea would be setting an array in $_SESSION, but that would make my urls not shareable. Creating a database is a mess. I need something very easy, just like old roman encryption method. Just not that because is a little bit too easy.
It is not possible to give a good advise without knowing your use-case and how much you know. But I like thought experiments like this, so here are some ideas for you to think about.
Encryption and encoding is not the same, so you first need to decide if you want to obfuscate or secure the data. Encoding obfuscate the data making it harder for non-tech people to read it, encryption make it really hard to read it.
If you want to obfuscate php have the function http://php.net/manual/en/function.str-rot13.php, but since this is like old roman "encryption" you could base64 encode it after. This will give you a string that is obfuscated and not readable by most users, but most here on SO will recognize what it is and be able to read it.
Another way to obfuscate the data could be to xor the string with another string.
You did include that you are not ready to include a database, but maybe you could implement a simple replacement with storing a lookup-table in a file. Using the key in the link and then looking up the value in the file.
If you want to actually encrypt the data you should look into openssl_encrypt and openssl_decrypt and encrypt it with a key using cbc mode, this is the way to go if you want security.
This is a little out of the blue and it's mostly curiosity. I hope it's not a waste pf time and space.
I was writing a little script to validate accounts with a link so I decided to send an email with a link to the php script and in the link I would put two variables to get with the _GET array. A key and the email. Then I would just search the database with that email and key and change it's activated status to true... No prob. Easy enough even though it may not be very elegant..
I used a script for the generation of the key that I used elsewhere in the site for generating a new password (to reset it for instance) but sometimes it didn't work and after a lot of tries I noticed (and I felt stupid then) that the array my password generation function drew from was this:
'0123456789_!##$%&*()-=+abcdfghjkmnpqrstvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'
So naturally I deleted the & character that is used for separating variables in the url... Then in another try I noticed that the link in the email was not recognized whole and stopped after the '#' character as well which I then remembered is used for references in an html so I deleted that as well. In the end I decided to leave only alphanumeric characters to be sure but I am curious; Are ther any more characters that are not 'valid' for url's using utilizing _GET and is there any way to use those characters anyway (maybe ulr encode or somwething)
There are plenty of characters that are invalid. Use urlencode to convert them to URL safe encodings. (Always run that function over any data you are inserting into a URL).
You have to use urlencode() before sending the values to $_GET.
You could use url_encode and url_decode but I would stay away from & # ? these are normal URL characters.
Also when it comes to passwords : dont stress about an algorithm, use sha1 crypt or something along those lines with a salt. These algorithms will be much stronger than your homemade ones.
what about using more than one encoder to encode my code, because if we take a look at ioncube you will see some people can decode it.
my idea here is using non familliar encoder on the encoding code of i*oncube*
i mean i will encode two times
first with ioncube
second with any other decoder
is that will make a problem?
Well, it would depend on the type of encoding done, if its non destructive, meaning it only obfuscates the code then you probably can run multiple passes, however if it does something more like ioncube, then the person who you would give access to it will need to run both encoders in reverse order to do the decoding.
I dont think it would do any harm, but as far as I know ioncube, encodes the code using a license file which means that even someone with the software cant decode your code without having a license
Im currently using base64_encode for some $_GET params that i don't want regular user to mess with.
I was wondering that base64 is not looking too strong or is it ?
I also don't want to make some sort of mega encoding it's not so much of important information, but i would not like that user with average knowledge would mess with params in get.
Should i keep using base64 ? Currently it produces MQ== if value is 1 so it's quite easy to take it out from URL and decode and then insert your own.
Base-64 encoding doesn’t protect the data in any way. It’s a simply base conversion like using hexadecimal instead of decimal for integers.
If you just want to verify data integrity, you can use a salted hash (with a secret salt) that you store along with the data. See for example the hashed message authentication code (HMAC).
base64_encode() is not a security measure! It was designed to make sending of binary blobs possible through mediums that typically transfer ASCII only.
Use a session, or properly encrypt your variables.
I would recommend just using a session, and storing it out of the default /tmp for good measure with...
ini_set('session.save_path', '/sessions');
If you want some real encryption/decryption take a look at the Mcrypt features of PHP. http://www.php.net/manual/en/mcrypt.examples.php
But then you may want to use POST instead of GET because of the URL specifications which are limited in character usage and URL length.
Depends on what you want do do with it.
If you just want to obfuscate it (especially when you're generating those URLs in Javascript or so), you could apply ROT13 to the URL and swap a few additional characters to make decoding it a little bit more difficult.
However, if the security of your application depends on it, you could apply a static-key symmetric encrytion on the data server-side and decode it when you receive a request or so. I think that there are frameworks or so for that.
The Interwebs are no help on this one. We're encoding data in ColdFusion using serializeJSON and trying to decode it in PHP using json_decode. Most of the time, this is working fine, but in some cases, json_decode returns NULL. We've looked for the obvious culprits, but serializeJSON seems to be formatting things as expected. What else could be the problem?
UPDATE: A couple of people (wisely) asked me to post the output that is causing the problem. I would, except we just discovered that the result set is all of our data (listing information for 2300+ rental properties for a total of 565,135 ASCII characters)! That could be a problem, though I didn't see anything in the PHP docs about a max size for the string. What would be the limiting factor there? RAM?
UPDATE II: It looks like the problem was that a couple of our users had copied and pasted Microsoft Word text with "smart" quotes. Those pesky users...
You could try operating in UTF-8 and also letting PHP know that fact.
I had an issue with PHP's json_decode not being able to decode a UTF-8 JSON string (with some "weird" characters other than the curly quotes that you have). My solution was to hint PHP that I was working in UTF-8 mode by inserting a Content-Type meta tag in the HTML page that was doing the submit to the PHP. That way the content type of the submitted data, which is the JSON string, would also be UTF-8:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
After that, PHP's json_decode was able to properly decode the string.
can you replicate this issue reliably? and if so can you post sample data that returns null? i'm sure you know this, but for informational sake for others stumbling on this who may not, RFC 4627 describes JSON, and it's a common mistake to assume valid javascript is valid JSON. it's better to think of JSON as a subset of javascript.
in response to the edit:
i'd suggest checking to make sure your information is being populated in your PHP script (before it's being passed off to json_decode), and also validating that information (especially if you can reliably reproduce the error). you can try an online validator for convenience. based on the very limited information it sounds like perhaps it's timing out and not grabbing all the data? is there a need for such a large dataset?
I had this exact problem and it turns out it was due to ColdFusion putting none printable characters into the JSON packets (these characters did actually exist in our data) but they can't go into JSON.
Two questions on this site fixed this problem for me, although I went for the PHP solution rather than the ColdFusion solution as I felt it was the more elegant of the two.
PHP solution
Fix the string before you pass it to json_decode()
$string = preg_replace('/[\x00-\x1F\x80-\xFF]/', '', $string);
ColdFusion solution
Use the cleanXmlString() function in that SO question after using serializeJSON()
You could try parsing it with another parser, and looking for an error -- I know Python's JSON parsers are very high quality. If you have Python installed it's easy enough to run the text through demjson's syntax checker. If it's a very large dataset you can use my library jsonlib -- memory use will be higher than with demjson, but it will run faster because it's written in C.