While looking over the doc's for urldecode() I came across this note:
The superglobals $_GET and $_REQUEST
are already decoded. Using urldecode()
on an element in $_GET or $_REQUEST
could have unexpected and dangerous
results.
This is the reason why a get variable with the value of %26 ends up being &. Are there any other auto-magical decode routines other than urldecode()? Perhaps decoding that is only done because of configuration or negotiation?
GET parameter decoding works actually in this sequence:
explode("&", $QUERY_STRING)
strtok("=") to split names from value
urldecode() on name and value
strtr(".", "_", $name) - non-alphanumeric characters mostly stripped from var names (a GET parameter &x.y= becomes $_GET["x_y"])
expanding of [] array names
addslashes() on values if magic quotes were enabled - this is the only part that's configurable
When decoding POST parameters in multipart/form-data a charset= could be set individually for each field. But I have a hunch that PHP doesn't respect that.
That is all. AFAIK
While no longer really an issue in the later builds of PHP, GET POST & COOKIES used to have quotes automatically escaped... See here for more info: http://php.net/manual/en/security.magicquotes.php
Related
Please note that this is a JQuery-Ajax-CodeIgniter issue.
All files involved in the post process are UTF8 encoded.
At non-Ajax calls, all of my forms work perfectly with UTF8 characters.
At Ajax calls, the Firebug/Chrome sniffers display the posted values correctly.
If I print the $_POST array in the index.php (root file), the values appear correctly.
CI is doing something that is placing question marks where the curly quotes are and trimming the strings at the first accented character.
From the sound of it, iconv could be messing with the strings, so I tried removing XSS, commenting the iconv and mb_convert_encoding lines from CI system/core/Input.php and system/core/Utf8.php, but no joy.
After suffering a bit I decided to have a look at the $_REQUEST. OMG, the strings are correctly displayed there, so instead of $_POST I use $_REQUEST (not that I like it).
I found the following post saying that we should use $_REQUEST instead of $_POST:
`$('#form').serialize()` messes up UTF-8 characters, which then points back to the PHP urldecode function.
I am not sure the problem is related to the urldecode as the $_POST array changes after being treated by CI.
So, should I keep using $_REQUEST in my Ajax controllers or is there a better solution for this problem?
Any thoughts in the security/XSS side?
Thanks!
I have a string has encrypted but with some symbol qwfKOEK==dwk&f
What if I need pass this string to a parameter:
www.example.php?string=qwfKOEK==dwk&f
$_GET["string"]
But I can’t get the string cause the symbol interrupt it.
Anyway to escape the symbol?
I had try html_entity_decode but seems not working, any possible way to escape the symbol and $_GET the original string?
A URL value needs to be URL encoded using urlencode or rawurlencode.
The difference between the two is two slightly different standards for encoding, whereby the rawurlencode variant is generally preferred.
If you try to put this sting in a GET parameter, definitely it'll not be accepted as it explodes at "=" sign. You can try passing the same though a POST parameter or try changing the encryption technique. I hope this may solve the problem. plus, html_entity_decode() doesnt apply to "=" sign.
I am passing an encrypted string in the url and then using php $_GET to retrieve it but i am having some problems with let me write the url first to make it more sense
http://localhost/marketplace/test.php?sortid=Cd2&V0reSzN$NBh^tjcF!%3CfsAAhIU%28%3C
if you will notice i have an ampersand sign in the middle of the string so when i am echoing out $_GET it is breaking the value after ampersand sign Ex
echo $_GET['sortid'];
and the result i am getting is Cd2 and it is not reading anything after ampersand sign , the problem i can figure out is that php will read the everything as a different parameter after '&' sign while using $_GET
But i have no idea on how to fix this
Thanks
This is happening because ampersand sign has a special meaning in query strings. The behaviour you are experiencing is perfectly normal and expected.
If you want to pass GET parameters that include special characters you should properly encode them using urlencode or alternatively something like base64 encode.
by URL creating, replace ampersand with %26, it will do the trick.
Alternately, encode your encoded string with base64 again, then you have no ampersand.
I have a text field where where the user can pass wild cards - more specific to the question they can use '%' character.
I am using ajax to get the value and send it to a PHP file. If I enter '%BA' in the text file and retrieve the value using
document.getElementById('textfield').value
This actually gets '%BA'. I am using POST method to send it to a PHP file. But the variable displays as "�" in the web browser and inserts " ° - degree small o" in the database.
I am sure there are other cases that I am not aware of as well. Is there a function in PHP to escape the special characters or any other way to get the exact string?
Edit: This may be a guess but doing escape(document.getElementById('textfield').value) to send the value and using urldecode($values[3]) to retrieve the value doesn't work. Maybe it's a js to PHP problem.
Update: urldecode will not work. Read the first comment in urldecode. Used the function there. Solved.
while passing the value using ajax , you just encode the value with encodeURIComponent() function and use urldecode() function to decode it in the php file. This might solve the issue.
You could encode the characters with urlencode (and maybe htmlspecialchars too) before storing it in the database, and use urldecode ( and maybe htmlspecialchars_decode) to decode them before displaying to the user.
You can use escape in javascript i.e.
escape(document.getElementById('val'))
I need to encrypt a string using MySQL's AES_ENCRYPT function, then attach that encrypted string to the end of a URL, such that it can then be decrypted and used by a PHP script on the other end.
Basically, I am encrypting the string (using MySQL's AES_ENCRYPT), I am then using PHP's rawurlencode() function to make it "URL safe". I then pass the encrypted string in a URL, which is then retrieved by the PHP script on the other end where it gets successfully decrypted... about 95% of the time.
Seems as though about 5% of strings are encrypting in such a way that they are getting corrupted somewhere in the process, and can't be decoded on the other end after being passed by a URL. Can anyone help me out here? Is there a 100% fool-proof way to do this? I have also tried using urlencode() as well as base64_encode() in varying combinations.
Thanks.
Solved.
Once I have encrypted the string using MySQL's AES_ENCRYPT function, I use PHP's bin2hex() function to convert that encrypted data (which is in binary form) in to Hexidecimal. I then pass the Hexidecimal as a string on the end of the URL. Once the URL is received on the other end, I then use this custom PHP function to revert the Hex string back to binary:
function hex2bin($data) {
$len = strlen($data);
return pack("H" . $len, $data);
}
From there, all that's left to do is decrypt the data using MySQL's AES_DECRYPT function, and wha-la. The original string is successfully restored.
URLs have a finite maximum length. AES-encrypted strings do not.
URLs are not an appropriate vector for passing arbitrary information. Using an HTTP POST is a much better way, if you must communicate over HTTP.
About why you are having problems: quoting from the PHP manual page on urlencode:
Note: Be careful about variables that
may match HTML entities. Things like
&, © and £ are parsed by
the browser and the actual entity is
used instead of the desired variable
name. This is an obvious hassle that
the W3C has been telling people about
for years. The reference is here:
http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2.
PHP supports changing the argument
separator to the W3C-suggested
semi-colon through the arg_separator
.ini directive. Unfortunately most
user agents do not send form data in
this semi-colon separated format. A
more portable way around this is to
use & instead of & as the
separator. You don't need to change
PHP's arg_separator for this. Leave it
as &, but simply encode your URLs
using htmlentities() or
htmlspecialchars().