☰

Wie kann ich verhindern, dass Apache das Passwort eines Benutzers preisgibt?

tag-icon • tag-icon apache-2.2 authentication
Wie kann ich verhindern, dass Apache das Passwort eines Benutzers preisgibt?

Bei Verwendung der Basisauthentifizierung (speziell über LDAP, aber auch über htpasswd) mit Apache wird die Variable REMOTE_USER für den darunterliegenden PHP-/Ruby-/Python-Code verfügbar – dies ist sehr nützlich, um die Authentifizierung auf den Webserver auszulagern.

In unserer Büroumgebung arbeiten viele interne Anwendungen auf diese Weise über SSL, und das alles ziemlich sicher. ABER: Apache stellt die Variablen PHP_AUTH_USER (=REMOTE_USER) und PHP_AUTH_PW jeder Anwendung innerhalb von PHP zur Verfügung. (PHP_AUTH_PW enthält das vom Benutzer eingegebene Passwort im Klartext.) Das bedeutet, dass die App Benutzernamen und Passwörter abgreifen kann. Vermutlich stehen Python und Ruby dieselben Informationen zur Verfügung (alle drei werden derzeit verwendet; PHP wird auslaufen).

Wie kann ich Apache also daran hindern, dies zu tun?

Eine Idee besteht darin, die Kerberos-Negotiate-Authentifizierung zu verwenden (die das Kennwort nicht preisgibt und den Vorteil hat, dass es sich um SSO handelt). Bei einigen Browsern (Chrome und in einigen Fällen Firefox) wird dabei jedoch automatisch auf Basic zurückgegriffen, wodurch das Kennwort erneut preisgegeben wird.

Antwort1

Nur für den Fall, dass jemand wie ich über diese Frage stolpert:

In Apache 2.4.5 und höher können Sie denAuthBasicFakeAnweisung zum Maskieren des Passworts:

AuthBasicFake toto tata

Ergebnisse in:

PHP_AUTH_USER=toto
PHP_AUTH_PWD=tata

So behalten Sie den Benutzernamen:

AuthBasicFake %{REMOTE_USER} tata

ergibt:

PHP_AUTH_USER=value-of-remote-user 
PHP_AUTH_PWD=tata

REMOTE_USER ist nicht betroffen.

Antwort2

Scheint nicht möglich zu sein, aber sehen Siehttp://bytes.com/topic/php/answers/798619-prevent-setting-php_auth_pw
In Beitrag Nr. 8 wird vorgeschlagen, auto_prepend_file zu verwenden, um ein Skript auszuführen, das die Variable aufhebt.
Es handelt sich dabei um einen Workaround, nicht um eine saubere Lösung, aber es gibt sie ...

Haben Sie AuthType Digest ausprobiert?

Antwort3

Radius hat recht – das geht nicht.

Nach weiteren Recherchen wurde mir klar, dass dies im Grunde ein Musterszenario für eine Identitätsbestätigung ist: Ein vertrauenswürdiger Identitätsanbieter „beweist“ der Client-Anwendung die Identität des Benutzers. Die SAML 2.0-Spezifikation scheint hierfür gut zu passen.

Ich hatte gehofft, ohne weitere Infrastrukturschichten auszukommen, werde aber simpleSAMLphp[1] für den IDP und mod_mellon[2] für die Apache-Seite verwenden. (Nach einem Tag Herumprobieren funktioniert es.) Das löst das Passwortproblem zwar nicht, bringt es aber in eine kontrollierbare Richtung.

Abgesehen davon: Suns OpenSSO ist ziemlich leistungsstark, wurde aber von Oracle eingestellt und die Zukunft des zugehörigen OpenAM-Projekts ist noch immer ungewiss.

[1]:http://rnd.feide.no/simplesamlphpsimpleSAMLphp

[2]:http://code.google.com/p/modmellon/mod_mellon

Antwort4

Ich habe einen Workaround. Ich habe meiner .htaccess Folgendes hinzugefügt

php_value auto_prepend_file "global_prepend.php"

In der Datei „global_prepend.php“ habe ich folgende PHP-Zeile hinzugefügt:

$_SERVER["PHP_AUTH_PW"]="Shh! It's a secret!";

Ich kann mich jetzt mit meinen Anmeldeinformationen anmelden und mein echtes Passwort ist nicht mehr gespeichert.

verwandte Informationen