bsmither Posted October 9, 2014 Share Posted October 9, 2014 I am working with a fellow who runs an eCommerce shop. The transaction resolution comes in on a querystring. I do not yet know what web server software is being used, nor if any security appliance/software is installed. One of the values in the querystring starts with the @ character. We know the web server gets this as there entries in the web server's access log that shows thing value is present. It is not available in PHP's $_GET array. We are trying to get an idea of where this value, and it's key, is getting discarded. Is there a known problem with (actual server software being used not yet known) web server software discarding a key/value if the value has the @ character in the querystring? Quote Link to comment Share on other sites More sharing options...
requinix Posted October 9, 2014 Share Posted October 9, 2014 If it's definitely in the URL (confirm with $_SERVER["REQUEST_URI"] or $_SERVER["QUERY_STRING"]) then it should also be in $_GET. Knowing about the web server would be very useful for this. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 9, 2014 Author Share Posted October 9, 2014 (edited) I have learned the web server is Litespeed, but the version is not yet known. Running PHP5.3.28. I will soon learn the results of $_SERVER["QUERY_STRING"]. Thank you. Edited October 9, 2014 by bsmither Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 9, 2014 Author Share Posted October 9, 2014 The $_SERVER["QUERY_STRING"] contains the missing key/value. That key/value is missing in the $_REQUEST array (as posted above, I assume it will also not be in the $_GET array, but I have a test in progress). In case it matters for PHP 5.3.28, the key's name is crypt and the value is 802 characters that starts with the @ character. This response comes from the SagePay payment processor. SagePay, a few years ago, had two types of encoded response - the type was indicated by the @ prefix. Since that time, the non-@ encoding method was shelved. I have to assume: * the length of the value did not change appreciably between the two encoding methods * if the @ prefix was causing large numbers of failures, it would have been discarded years ago * if the key name 'crypt' was causing large numbers of failures, it would have been changed years ago I am left to believe that a PHP setting (or a fault with PHP 5.3.28, or a security program setting) is not processing this key/value from the querystring into $_REQUEST (and possibly $_GET). More experiments to conduct. Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted October 9, 2014 Share Posted October 9, 2014 do any $_GET parameters on the end of url's work on this server? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 9, 2014 Author Share Posted October 9, 2014 Test complete. 'crypt' is not in $_GET either. Five of the six key/values in this querystring survive. Quote Link to comment Share on other sites More sharing options...
requinix Posted October 9, 2014 Share Posted October 9, 2014 There is no PHP setting that will drop @crypt when parsing. You're barking up the wrong tree. What happens if you parse_str() on the raw QUERY_STRING? Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 12, 2014 Author Share Posted October 12, 2014 (edited) I fed the querystring to my local system and it's all good. I modified the index.php file on the other system to show: 21:39:35UTC - 10/12/14 URI => '/index.php?_g=rm&type=gateway&cmd=process&module=SagePay&cart_order_id=141012-123456-0000&crypt=@5057f-800chars IP:PORT=>PORT => '94.x.y.z:80' COOKIE => 'abc' POST => '<empty>' GET => Array ( [_g] => rm [type] => gateway [cmd] => process [module] => SagePay [cart_order_id] => 141012-123456-0000 ) REQUEST => Array ( [_g] => rm [type] => gateway [cmd] => process [module] => SagePay [cart_order_id] => 141012-123456-0000 [__utma] => 123 [__utmc] => 456 [__utmz] => 789 [username] => abc@**.com [PHPSESSID] => abc ) I will agree 99% it's not a PHP setting. That still leaves a security add-on to PHP that may be the culprit. Any suspects come to mind? Would it even be possible? Would you think that parse_str() would not be affected by any such security addon, if that were the case? Edited October 12, 2014 by bsmither Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 13, 2014 Author Share Posted October 13, 2014 (edited) Would any of these settings influence a GET value of 800+ characters for a given key? suhosin.get.max_name_length 64 suhosin.get.max_totalname_length 256 suhosin.get.max_value_length 512 suhosin.get.max_vars 100 suhosin.post.max_name_length 64 suhosin.post.max_totalname_length 256 suhosin.post.max_value_length 1000000 suhosin.post.max_vars 1000 suhosin.request.disallow_nul 1 suhosin.request.disallow_ws 0 suhosin.request.max_array_depth 50 suhosin.request.max_array_index_length 64 suhosin.request.max_totalname_length 256 suhosin.request.max_value_length 1000000 suhosin.request.max_varname_length 64 suhosin.request.max_vars 1000 suhosin.server.encode On suhosin.server.strip On Edited October 13, 2014 by bsmither Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 13, 2014 Author Share Posted October 13, 2014 If all this turns out sorted, maybe move the thread to whatever other forum is appropriate. Quote Link to comment Share on other sites More sharing options...
mac_gyver Posted October 13, 2014 Share Posted October 13, 2014 Would any of these settings influence a GET value of 800+ characters for a given key? yes - suhosin.get.max_value_length 512 http://www.suhosin.org/stories/configuration.html#suhosin-get-max-value-length Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.