NULL value parsed into $select_single can cause 403 Forbidden on certain restrictive hosting environments for "Find a Member" function within Private Message composition

This probably affects many other versions, but I have only looked at these two versions.

PROBLEM
On certain hosts that have active IDS/IPS in place, the value pushed through to $select_single inside the U_FIND_USERNAME var within includes\ucp\ucp_pm_compose.php can create a 403 Forbidden error under certain conditions.

NOTE: Investigations have shown that it's not a Mod_Security thing - some other provider level protection is in force.

CONDITIONS
1. A host is filtering suspicious looking URLs (specifically, a URL with a query string that ends with an empty parameter eg; "&select_single=")
2. "Allow sending of private message to multiple users and groups" is set to "yes" in the ACP.

HOW TO REPRODUCE
1. Install Vanilla phpBB
2. Enable "Allow sending of private messages to multiple users and groups"
3. Go to the Private Message section
4. Click New PM
5. Click Find A Member

The resultant URL will look like this:
http://website.com/forum/memberlist.php?mode=searchuser&form=postform&field=username_list&select_single=

Whilst this may technically be a valid URL, on some hosts this will cause an Error 403 - Forbidden because the last parameter has no value - probably in an effort to prevent a potential injection attack angle.

On other less fussy hosts that don't filter suspicious requests, this would be processed no problems.

NOTE: If "Allow sending of private message to multiple users and groups" is not enabled, the URL will look like this:

http://website.com/forum/memberlist.php?mode=searchuser&form=postform&field=username_list&select_single=1

Which will work on all hosts, since the final parameter in the URL has a value.

I would suggest this is because early in ucp_pm_compose.php, $select_single is populated with either true or false. When you echo true on PHP, it will display the value 1, however if you echo false in PHP it will display nothing. This means that if $select_single is true, the value will be pushed through as 1, however if $select_single is false, the value will be null or nothing.

RESOLUTION
To resolve this issue, there are probably many ways that this could be addressed:

Option 1 - If $select_single is false, do not add select_single to the URL in the line of code below.

Option 2 - Force $select_single to store the value 0 for false or 1 for anything else before the line of code below.

Option 3 - Rearrange the URL Parameters in the line below so that the $select_single parameter is not the last parameter:

'U_FIND_USERNAME'	=> append_sid("{$phpbb_root_path}memberlist.$phpEx", "mode=searchuser&form=postform&field=username_list&select_single=$select_single"),

MORE INFORMATION

On a fussy host, when $select_single is empty, if we add a 0, reshuffle the parameter orders or remove the last parameter completely, everything processes fine - All three variations work:

http://website.com/forum/memberlist.php?mode=searchuser&form=postform&field=username_list&select_single=0

http://website.com/forum/memberlist.php?mode=searchuser&form=postform&select_single=&field=username_list

http://website.com/forum/memberlist.php?mode=searchuser&form=postform&field=username_list

For a more detailed explanation, see this article:
http://www.jigsolving.com/general/ending-url-query-string-equals-symbol-can-cause-http-403-forbidden

This issue is not going to affect a lot of users, but I would suggest that it would be better to resolve it in future versions.