PDA

View Full Version : php $_SERVER[] variables are not set correctly in Fedora



justinacolmena
10th November 2017, 09:28 PM
Even when I connect to my server via https on port 443, and no, the connection is not being proxied or tunneled in any way, the following assertions are true.

!isset($_SERVER['HTTPS'])

$_SERVER['SERVER_PORT'] == '80'
even though the actual connection is secure to port 443.

Relevant code snippet


if (isset($_SERVER['SERVER_PORT'])) switch ($_SERVER['SERVER_PORT'])
{
case '80':
echo '<h1 style="color:red;">HTTP insecure connection</h1>' . "\n"
. '<p>please consider using '
. '<a href="https://'
. $_SERVER['SERVER_NAME']
. '/">https</a></p>' . "\n";
break;
case '443':
echo '<h1 style="color:green">HTTPS</h1>' . "\n"
. 'your connection is secure';

break;
default:
echo '<h1 style="color:yellow">UNKNOWN PROTOCOL PORT ' . $_SERVER['SERVER_PORT'] . "</h1>\n";
}


from this page https://miel.colmena.biz/

see https://miel.colmena.biz/phpinfo.php for the output of phpinfo().

justinacolmena
11th November 2017, 05:45 PM
So ecommerce of any kind is impossible on Fedora. That shopping cart application will not run when

!isset($_SERVER['HTTPS']) && $_SERVER['SERVER_PORT'] == '80';

justinacolmena
13th November 2017, 07:45 PM
I'm a bloodhound, something really, really smells about this, and I'm staying on the trail. They silenced Stefan Esser (https://twitter.com/i0n1c) of PHP security research fame, and now they've crippled php entirely? What is going on here?


http://www.hardened-php.net/
http://php-security.org/

remi
14th November 2017, 07:44 AM
Sorry, but I cannot reproduce this issue, from phpinfo;

$_SERVER['HTTPS'] on
$_SERVER['SERVER_PORT'] 443

justinacolmena
14th November 2017, 06:36 PM
Sorry, but I cannot reproduce this issue, from phpinfo;

$_SERVER['HTTPS'] on
$_SERVER['SERVER_PORT'] 443

Vague denial is not helpful. Details? Proof? Software version?

justinacolmena
14th November 2017, 09:06 PM
I think I may have solved my own problem here. Various SELinux permissions for httpd:


[root@miel ~]# getsebool -a | grep httpd_can_
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_mythtv --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> on
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> on
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
[root@miel ~]#

It seems to be necessary to set at least two of these variables ON with the -P option in order to actually enable httpd to connect to an external database.


[root@miel ~]# setsebool -P httpd_can_network_connect 1
[root@miel ~]# setsebool -P httpd_can_network_connect_db 1
[root@miel ~]#

OFF-TOPIC (by-the-way):
The following permission, on the other hand is unnecessary...

[root@miel ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off
[root@miel ~]#

because as an ordinary user I am able to

[justina@miel ~]$ chcon -R -t httpd_sys_content_t public_html/
[justina@miel ~]$

to allow httpd to serve my homedir WITHOUT httpd_enable_homedirs...

justinacolmena
14th November 2017, 10:00 PM
There is an apparently undocumented little directive in httpd.conf


UseCanonicalPhysicalPort On

ref: https://stackoverflow.com/questions/4433229/incorrect-port-number-returned-by-serverserver-port

Compare: Apache Environment / SERVER_PORT

http://miel.colmena.biz/phpinfo.php
https://miel.colmena.biz/phpinfo.php

... But "$_SERVER['HTTPS'] is still not set for a secure connection. (Theoretically it is possible to have an insecure plaintext connection on port 443.)

justinacolmena
14th November 2017, 10:48 PM
This is not at all a complete solution
https://miel.colmena.biz/phpinfo.php
https://stackoverflow.com/questions/18008135/is-serverrequest-scheme-reliable


$_SERVER['REQUEST_SCHEME'] == http && !isset($_SERVER['HTTPS'])


Even with /etc/httpd/conf.d/ssl.conf

SSLOptions +StdEnvVars +ExportCertData
The documented SSL environment variables are not being set.
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

I suspect this is due to a certain "business" userbase with large content distribution networks who offload ssl termination and maintain large unsecured internal networks, and they do not want their sites to "look" any less secure than properly secured sites ssl-terminated at the server.

justinacolmena
17th November 2017, 03:25 AM
[root@miel ~]# dnf list installed | grep selinux
libselinux.x86_64 2.6-7.fc26 @updates
libselinux-python3.x86_64 2.6-7.fc26 @updates
libselinux-utils.x86_64 2.6-7.fc26 @updates
rpm-plugin-selinux.x86_64 4.13.0.2-1.fc26 @updates
selinux-policy.noarch 3.13.1-260.14.fc26 @updates
selinux-policy-targeted.noarch 3.13.1-260.14.fc26 @updates
[root@miel ~]# setsebool -P httpd_can_network_connect 1
libsepol.context_from_record: type svnserve_log_t is not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:object_r:svnserve_log_t:s0 to sid
invalid context system_u:object_r:svnserve_log_t:s0
[root@miel ~]# setsebool -P httpd_can_network_connect_db 1
libsepol.context_from_record: type svnserve_log_t is not defined
libsepol.context_from_record: could not create context structure
libsepol.context_from_string: could not create context structure
libsepol.sepol_context_to_sid: could not convert system_u:object_r:svnserve_log_t:s0 to sid
invalid context system_u:object_r:svnserve_log_t:s0
[root@miel ~]#

It got even worse. A recent update really, really borked the SELinux policy in fedora. that "svnserve_log_t" type is from a hacked development machine.

On the other hand it might have been borked before an this fixed it. At any rate,


[root@miel ~]# touch /.autorelabel
[root@miel ~]# reboot

Rather brutal, but it works.