I am struggling with encrypting url parameters. I have for example the following urls:
http://www.domain.com/show_user.php?uid=45&s=photos
http://www.domain.com/show_user.php?uid=454&s=information
Now I do not want users to see the plain values of parameters 'uid' and 's' so I encrypted them with base64_encode.
http://www.domain.com/show_user.php?uid=NDU=&s=cGhvdG9z
http://www.domain.com/show_user.php?uid=NDU0&s=aW5mb3JtYXRpb24=
But now I have the problem that I have some capital letters in the URL. I my error log I find errors which are caused by requesting the url with only lowercase letters:
http://www.domain.com/show_user.php?uid=ndu=&s=cghvdg9z
This leads to an error since the string cannot be decrypted anymore.
This obviously isn't a very smart solution to encrypt parameters in url. What would you suggest? What encrypting methods do you use? Which one only creates lowercase letters?
I already want to thank you very much in advance for any help :)
Best regards,
Freddy
There must be a strtolower() in your code somewhere, addresses don't lowercase themselves. Check the code around where you're generating these encoded strings.
Also - As mentioned in that comment, it's not encryption. Functionally, is this something that actually needs to be encrypted, or just obscured?
If you have only this two parameters I would recommend you to write yourself an coding & encoding function. You can also compress all parameters to only one and then decoding it again using split string function.
If this information is somehow secret that you do not want to share, create table for mapping some id to this information, and generate page from these entries. But your need for encoding is not clear, so please elaborate more.
Related
I have a site that allows users to create a page based on user input example.com/My Page
The problem is if they create a url like example.com/H & E Photos or example.com/#1 Fan Club
Once php decodes the url, it tries to parse those characters into a hash (or a query string in the case of ?)
In my .htacess I am doing this ([^/]+?)
What is the typical way of handling a situation like this? Ideally, without going to an id system (example.com/131234121). Poor planning on my part :(
EDIT. Talking about PHP here. url is encoded when it hits the server, php decodes before parse regex and url
If you are using PHP to create/handle storing entries for user-entered-URLs then use htmlentities on the string before trying to handle it.
https://www.php.net/manual/en/function.htmlentities.php
https://www.w3schools.com/php/func_string_htmlentities.asp
Apparently, what I was looking for was a rewrite flag.
http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriteflags
B Escape non-alphanumeric characters before applying the transformation.
This allows you to send percent-encoded strings to the URL without them being decoded beforehand.
So it was actually an apache thing and not PHP. Sorry for the misleading question.
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.
It's quite pleasure to be posting my first question in here :-)
I'm running a URL Shortening / Redirecting service, PHP written.
I aim to store and handle valid URLs data as much as possible within my service.
I noticed that sometimes, invalid URL data is being handled over to the database, holding invalid characters (like spaces in the end or beginning of the URL).
I decided to make my URL-Check mechanism trim, stripslashes and strip_tags the values before storing them.
As far as I can think, these functions will not remove valid charterers that any URL may have.
Kindly, just correct me or advise me if I'm going into the wrong direction.
Regards..
If you're already trimming the incoming variable, as well as filtering it with the other built in PHP methods, and STILL running into issues, try changing the collation of your table to UTF-8 and see if that helps you get rid of the special characters you mention. (Could you paste a few examples to let us know?)
if i trying to access this url http://localhost/common/news/33/+%E0%B0%95%E0%B1%87%E0%B0%B8.html , it shows an An Error Was Encountered, The URI you submitted has disallowed characters. I set $config['permitted_uri_chars'] = 'a-z 0-9~%.:??_=+-?' ; ..// WHat i do ?
Yeah, if you want to allow non-ASCII bytes you would have to add them to permitted_uri_chars. This feature operates on URL-decoded strings (normally, unless there is something unusual about the environment), so you have to put the verbatim bytes you want in the string and not merely % and the hex digits. (Yes, I said bytes: _filter_uri doesn't use Unicode regex, so you can't use a Unicode range.)
Trying to filter incoming values (instead of encoding outgoing ones) is a ludicrously basic error that it is depressing to find in a popular framework. You can turn this misguided feature off by setting permitted_uri_chars to an empty string, or maybe you would like a range of all bytes except for control codes ("\x20-\xFF"). Unfortunately the _filter_uri function still does crazy, crazy, broken things with some input, HTML-encoding some punctuation on the way in for some unknown bizarre reason. And you don't get to turn this off.
This, along with the broken “anti-XSS” mangler, makes me believe the CodeIgniter team have quite a poor understanding of how string escaping and security issues actually work. I would not trust anything they say on security ever.
What to do?
Stop using unicode characters in an URL - for the same reasons as you shouldn't name files on a filesystem with unicode characters.
But, if you really need it, I'll copy/paste some lines from the config:
Leave blank to allow all characters -- but only if you are insane.
I would NOT suggest trying to decode them or use any other tricks, instead I would suggest using urlencode() and urldecode() functions.
Since I don't have a copy of your code, I can't add examples, if you could provide me some, I can show you an example how to do it.
However, it's pretty straightforward to use, and it's built in PHP4 and PHP5.
I had a similar problem and wanted to share the solution. It was reset password, and I had to send the username and time, as the url will be active for an hour only. Codeigniter will not accept certain characters in url for security reasons and I did not want to change that. So here is what I did:
concat user name, '__' and time() in a var $str
encrypt $str using MCRYPT_BLOWFISH, this may contain '/', '+'
re-encrypt using str2hex (got it from here)
put the encoded string as the 3rd argument in the link sent by
email, like,
http://xyz.com/users/resetpassword/3123213213ABCDEF238746238469898
-you can see that the url contains only 0-9 and A-Z.
When link from email is clicked, get the 3rd uri segment, use
hex2str() to decrypt to blowfish encrypted string, and then apply
blowfish decrypt to get the original string.
split with '__' to get the user name and time
I know that its almost a year till this question was asked, but I am hoping that someone will find this solution helpful after coming here by google.
I'm having an issue with validating chinese characters against other chinese characters, for example I'm creating a simple password script which gets data from a database, and gets the user input through get.
The issue I'm having is for some reason, even though the characters look exactly the same when you echo them out, my if statement still thinks they are different.
I have tried using the htmlentities() function to encode the characters, the password from the database encodes nicely, giving me a working '& #35441;' (I've put a space in it to stop it from converting to a chinese character!).
The other user input value gives me a load of funny characters. The only thing which I believe must be breaking it, is it encodes in a different way and therefore the php thinks it's 2 completely different strings.
Does anybody have any ideas?
Thanks in advance,
Will
Edit:
Thanks for the quick responses guys, I'm gonna look around setting the database encoding to UTF-8, however at the moment, the results from the database are not the problem, they are encoding correctly using htmlentities, it's the results I get from $_GET which is causing the problems.
Cheers,
Will
For passwords my advice is don't do a direct comparison, because that means you're storing passwords in the clear. At least run them through a hash like MD5 or SHA (preferably with a salt value as well) before storing them. Then you just have to compare the hash values, which are typically Hex values, so shouldn't cause any encoding problems.
For non-password values it sounds like your database and PHP are not on the same encoding, so they are not matching properly. If MySQL is storing them the way you want, have it do the comparison (instead of having it return the values first), that should avoid 1 of the passes through an encoding change which seems likely to be the problem.
If you want to store passwords, read this : what you need to know about secure password schemes.
After reading it, your root problem seem to be some character encoding missmatch between what you receive from the user and what you get from your database.
If you are using Mysql and utf-8 encoding, do you first use the SET names "utf-8" query ?
Saving the values using SHA1 and MD5 may solve your problem as the other stated it. It is also a secure process. Here's a code snippet to help out.
public function getHashedPassword()
{
$salt = 'mysalt';
return sprintf( "%d%s",$salt,sha1( sprintf( "%d%s", $salt,$this->_rawPassword) ));
}
Upon comparison, rehash the password input and compare it to the save hashed password in your database. Doing so may remove the encoding issue.
Since you anyway ought to store hashes of passwords rather than the passwords themselves, this might be a part of the solution. You store the hash rather than the password and thus have no problems with the database.
That said, there might be differences to how different browsers encode the strings they submit. It's not something I'm very much into, but you better make sure that you find a solution that makes the exact same string on all browsers. Setting the accept-charset to utf-8 is a nobrainer, you might also want to mess with the enctype.