Cuando se utiliza la autenticación básica (específicamente a través de LDAP, pero también htpasswd) con Apache, la variable REMOTE_USER está disponible para el código PHP/Ruby/Python subyacente; esto es muy útil para descargar la autenticación al servidor web.
En nuestro entorno de oficina tenemos muchas aplicaciones internas que funcionan así a través de SSL, todas bastante seguras. PERO: Apache expone las variables PHP_AUTH_USER (=REMOTE_USER) y PHP_AUTH_PW a cualquier aplicación dentro de PHP. (PHP_AUTH_PW contiene la contraseña en texto plano que ingresó el usuario). Esto significa que es posible que la aplicación recopile nombres de usuarios y contraseñas. Presumiblemente, la misma información está disponible para Python y Ruby (los tres están actualmente en uso; PHP se está eliminando).
Entonces, ¿cómo puedo evitar que Apache haga esto?
Una idea es utilizar la autenticación Kerberos Negotiate (que no expone la contraseña y tiene la ventaja de ser SSO), pero que automáticamente vuelve al Básico para algunos navegadores (Chrome y en algunos casos Firefox), lo que hace que la contraseña vuelva a quedar expuesta. .
Respuesta1
En caso de que alguien se tope con esta pregunta como lo hice yo:
En Apache 2.4.5 y posteriores puedes usar elAuthBasicFakedirectiva para enmascarar la contraseña:
AuthBasicFake toto tata
Resultados en:
PHP_AUTH_USER=toto
PHP_AUTH_PWD=tata
Para conservar el nombre de usuario:
AuthBasicFake %{REMOTE_USER} tata
da como resultado:
PHP_AUTH_USER=value-of-remote-user
PHP_AUTH_PWD=tata
REMOTE_USER no se ve afectado.
Respuesta2
Parece que no es posible pero mirahttp://bytes.com/topic/php/answers/798619-prevent-setting-php_auth_pw
La publicación n.° 8 sugiere usar auto_prepend_file para ejecutar un script que desactive la variable.
Es una solución alternativa, no una solución limpia, pero existe...
¿Probaste AuthType Digest?
Respuesta3
El radio tiene razón, no se puede.
Después de investigar más, me di cuenta de que este es básicamente un escenario de libro de texto para una afirmación de identidad: un proveedor de identidad confiable "prueba" la identidad del usuario a la aplicación cliente. La especificación SAML 2.0 parece encajar bien.
Esperaba poder prescindir de más capas de infraestructura, pero optaré por simpleSAMLphp[1] para el IDP y mod_mellon[2] para el lado de Apache. (Un día de retoques y funciona). Esto no resuelve el problema de la contraseña, pero la traslada a un lugar donde se puede controlar.
Aparte: OpenSSO de Sun es bastante robusto, pero Oracle lo eliminó y el futuro del proyecto OpenAM relacionado aún no está claro.
[1]:http://rnd.feide.no/simplesamlphpsimpleSAMLphp
[2]:http://code.google.com/p/modmellon/mod_mellon
Respuesta4
Tengo una solución alternativa. Agregué lo siguiente a mi .htaccess
php_value auto_prepend_file "global_prepend.php"
En el archivo "global_prepend.php" agregué la siguiente línea PHP:
$_SERVER["PHP_AUTH_PW"]="Shh! It's a secret!";
Ahora puedo iniciar sesión con mis credenciales y mi contraseña real ya no se almacena.