Jump to content

Losing Part of Querystring


bsmither

Recommended Posts

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?

 

 

Link to comment
https://forums.phpfreaks.com/topic/291523-losing-part-of-querystring/
Share on other sites

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.

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?

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

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.