Jump to content

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?

Edited by bsmither

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 by bsmither
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • 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.