Apache, htaccess, mod_cgi, REMOTE_USER

Hallo,

Drecksding, elendiges, verflixte Kiste.

in $www/wwwroot/protected liegen (PHP-) Dokumente, welche von

AuthName "protected"
AuthType Basic
AuthUserFile /path/to/.htpasswd
Require valid-user

in $www/wwwroot/protected/.htaccess geschuetzt werden. Beim Aufruf der Dokumente werde ich auch nach dem user/pw gefragt. In diesen gibt es ein

Der apache2 hat ein[1]

ScriptAlias /cgi-sbin/ $www/cgi-bin/sbin/

 Options +ExecCGI

(natuerlich mit ausgeschriebenem $www).

In $www/cgi-bin/sbin existiert die gleiche .htaccess wie oben[2]. script.pl ist perl und wird auch artig vom apache2 gestartet. Ungluecklicherweise legt er in die Umgebung des scripts nicht REMOTE_USER, so dass der Zugriff via %ENV nicht fruchtet. Das Hinzufuegen von ‚AddHandler cgi-script .pl‘ oder[3] ‚SetHandler cgi-script‘ [4] aendert daran nichts.

Ich braeuchte aber eben genau jene Variable, um den angemeldeten Nutzer zu identifizieren. Richtig debuggen laesst es sich auch nicht, da mein HTTPS noch etwas holprig ist und ich bin nicht der grosse apache-Experte. Hat irgendwer noch Ideen, was ich noch uebersehen hab?

Danke im Voraus,
Gruss vom Frank.
===footnotes===
[1] Nach: http://httpd.apache.org/docs-2.1/mod/mod_cgi.html
[2] Nach: http://www.wer-weiss-was.de/cgi-bin/forum/showarchiv…
[3] Echtes (logisches) „oder“.
[4] Nach: http://httpd.apache.org/docs-2.1/howto/cgi.html

Hi,

kannst Du nicht im Formular
unter
die benötigte Info unterbringen?

Gruß
Fred

Hi,

Hallo,

kannst Du nicht im Formular
unter
die benötigte Info unterbringen?

Aeh… ja, kann ich. Und die kann ich dann vom browser des Nutzers wieder zuruecknehmen, oder? Ich kann mir natuerlich die user-Authenfizierung auch ganz sparen, oder? Ich kann Dich natuerlich auch absolut falsch verstehen.

Nichts fuer ungut,
Gruss vom Frank.

Tschuldigung!
ENV enthält den remote_user nur, wenn dieser auch abgefragt wurde!
Dein Script mit dem Formular darf das pl-Script ohne Passwort-Abfrage aufrufen, also ist der remote_user nicht gefüllt.
Das Hinterlegen der benötigten Informationen habe ich vorgeschlagen, da das Formular selbst ja bereits in einem geschützten Bereich liegt.

Sollten wir auch jetzt noch aneinander vorbeireden, will ich auch nicht weiter nerven.

Gruß
Fred

Tschuldigung!

Schon okay, vielleicht will ich ja auch was, was gar nicht geht.

ENV enthält den remote_user nur, wenn dieser auch abgefragt
wurde!

Hm… in den steht ungefaehr sowas:

foo
click me

bar
click me

Dies wird von einer dump.php generiert, fuer die sich der user identifizieren und authentisieren musste. Dementsprechend hat dump.php dort Zugriff auf $_SERVER[„PHP_AUTH_USER“]. Allerdings hat auch script.php, dass direkt daneben im Verzeichnis liegt, diese Umgebungsvariable, obwohl sich user dafuer nicht nochmal anmeldem muss[1].

Dein Script mit dem Formular darf das pl-Script ohne
Passwort-Abfrage aufrufen, also ist der remote_user nicht
gefüllt.

Das waere aber sehr haesslich.

Das Hinterlegen der benötigten Informationen habe ich
vorgeschlagen, da das Formular selbst ja bereits in einem
geschützten Bereich liegt.

Du wuerdest also so vorschlagen, dass ich von dump.php etwas in dieser Art generiere:

Hab ich Dich da richtig verstanden? Ich koennte dann im perl die ‚id‘ auseinanderfummeln und so user und id rauskriegen. Das waere super. Wenn es nur einen Nutzer fuer die Dokumente gaebe oder nur welche, denen ich total vertraue.

Wie kann ich sicher gehen, dass sich Nutzer mit ‚frank‘ angemeldet hat, ich im ordnungsgemaess

(usw.) generiert habe, mir der total kaputtgehackte webbrowser[2] des Nutzers mir da aber nicht zufaellig

reininterpretiert und diesen Mist wieder zurueck in mein perlscript schickt? Das denkt treudoof, es wuerde mit ‚fred‘ reden, und liefert an ‚frank‘ das streng geheime Rezept der Coca-Cola, das doch eigentlich nur ‚fred‘ sehen sollte.

Sollten wir auch jetzt noch aneinander vorbeireden, will ich
auch nicht weiter nerven.

Schon okay. Aber browser-Daten sind boese Daten und kommen potentiell aus einer unsicheren Umgebung.

Trotzdem Danke,
Gruss vom Frank.
===footnotes===
[1] Nein, ich kann kein PHP nehmen.
[2] Im Lande Microsoft, wo die browser closed source (und supersicher) sind, waere das nicht passiert.

ENV enthält den remote_user nur, wenn dieser auch abgefragt
wurde!

Vorstehende Aussage bleibt!

Hm… in den steht ungefaehr
sowas:

foo
clickme

bar
clickme

Dies wird von einer dump.php generiert,
fuer die sich der user identifizieren und authentisieren
musste. Dementsprechend hat dump.php dort Zugriff auf
$_SERVER[„PHP_AUTH_USER“]. Allerdings hat auch script.php,
dass direkt daneben im Verzeichnis liegt, diese
Umgebungsvariable, obwohl sich user dafuer nicht nochmal
anmeldem muss[1].

Ja, PHP hat diese Var gesetzt und kann sie dementsprechend auch nutzen!
Ich verstehe auch nicht, was Links im Formular verloren haben, aber das ist eine andere Geschichte.

Dein Script mit dem Formular darf das pl-Script ohne
Passwort-Abfrage aufrufen, also ist der remote_user nicht
gefüllt.

Das waere aber sehr haesslich.

Ist aber so! Das Script mit dem Formular kommt nicht „von aussen“, sondern über das „Filesystem“, warum sollte es sich dann authentifizieren?

Das Hinterlegen der benötigten Informationen habe ich
vorgeschlagen, da das Formular selbst ja bereits in einem
geschützten Bereich liegt.

Du wuerdest also so vorschlagen, dass ich von dump.php etwas
in dieser Art generiere:

Hab ich Dich da richtig verstanden? Ich koennte dann im perl
die ‚id‘ auseinanderfummeln und so user und id rauskriegen.
Das waere super. Wenn es nur einen Nutzer fuer die Dokumente
gaebe oder nur welche, denen ich total vertraue.

Wenn ein User sich im ersten Script authentifiziert hat, kann das Script auch nur DEN User liefern!

Wie kann ich sicher gehen, dass sich Nutzer mit ‚frank‘
angemeldet hat, ich im ordnungsgemaess

(usw.) generiert habe,
mir der total kaputtgehackte webbrowser[2] des Nutzers mir da
aber nicht zufaellig

reininterpretiert und diesen Mist wieder zurueck in
mein perlscript schickt? Das denkt treudoof, es wuerde mit
‚fred‘ reden, und liefert an ‚frank‘ das streng geheime Rezept
der Coca-Cola, das doch eigentlich nur ‚fred‘ sehen sollte.

Weil jeder, der nicht über das Org-FormularScript kommt automatisch in den Dialog zur Authentifizierung gerät!

MfG
Fred

Morgen,

also, ich hab eigentlich echt keine Lust, Dir das jetzt zu erklaeren, aber, nimm es mir bitte nicht uebel, Du hast ganz offensichtlich keine Ahnung, wie man in scripts in sicherheitsrelevanten Bereichen richtig identifiziert, authentisiert und authentifiziert. Ich hoffe, Du hast in der Machart, wie Du sie vorschlaegst, nicht irgendwo scripts rumliegen, weil Du sonst evtl. ein Problem kriegen koenntest. (BTW: arbeitest Du zufaellig bei T-Online?)

ENV enthält den remote_user nur, wenn dieser auch abgefragt
wurde!

Vorstehende Aussage bleibt!

Meinethalben. Dann frag ich mich, wozu mod_cgi gut ist.

Ist aber so! Das Script mit dem Formular kommt nicht „von
aussen“, sondern über das „Filesystem“, warum sollte es sich
dann authentifizieren?

Das ist falsch, wie ich inzwischen rausgekriegt hab. Letzten Endes war es PEBKAC: ich war so bloed, fuer das CGI-Verzeichnis ‚AllowOverride None‘ zu setzen. Dadurch wurde die dortige .htaccess gar nicht ausgewertet. Ja, ich hab das in meiner Frage nicht verraten. Ja, ich bekenne mich schuldig. My fault.

Weil jeder, der nicht über das Org-FormularScript kommt
automatisch in den Dialog zur Authentifizierung gerät!

Nochmal langsam zum mitmeiseln: fuer das Formular gibt es zwei Nutzer, (eg.) Alice und Bob. Beide haben unterschiedliche Zugangsberechtigungen fuer die Formulardaten. Alice darf darueber ihre Rezeptesammlung einsehen und bearbeiten, Bob den Bestand an Sportwagen in seiner Tiefgarage. Beide muessen sich vor dem Formular identifizieren und authentisieren, das PHP-script authentifiziert sie und autorisiert sie, ihre jeweiligen Daten zu sichten und zu bearbeiten. Du schlaegst mir jetzt allen Ernstes vor, ich solle fuer Alice ungefaehr sowas generieren:

Rezept Wegwerfen?
Alice:Blaubeermuffins []
Alice:Erdbeertorte []

bzw.

Fahrzeug Wegwerfen?
Bob:smiley:odge Viper []
Bob:stuck\_out\_tongue:orsche 911 []

(Natuerlich werden die Zeichenfolge ‚Alice‘ bzw. ‚Bob‘ nicht dargestellt, sondern sind irgendwelche Formularparameter, trotzdem werden sie an den browser der Nutzer weitergegeben und untersteht somit deren Kontrolle und dienen der Kommunikation mit dem CGI-script.)

Wenn Alice eine Gute ist, klickt sie artig und schickt mir sowas wie ‚Alice:Erdbeertorte‘. Das CGI-script identifiziert erneut ‚Alice‘ anhand der Zeichenkette vor dem ‚:‘ und macht einen Zugriff auf ihren Datenbestand indem es das Rezept fuer Erdbeertorte wegwirft. Und genau hier liegt das Problem: Alice wird erneut identifiziert, aber nicht authentisiert und somit auch nicht authentifiziert.

Folgendes Szenario: wenn Alice eine Boese ist, kann sie so garstig sein, nicht klicken, sondern mir den selbst zusammengebauten string ‚Bob:stuck_out_tongue:orsche 911‘ an mein script schicken. Das identifiziert (ohne zu authentisieren) Bob und wirft seinen neuen Porsche weg.

Merken: browser-Daten sind boese Daten! Nimm es bitte wirklich nicht persoenlich, aber die Loesung die Du hier vorschlaegst, mag zwar im guenstigen Fall funktionieren, ansonsten halte ich sie aber fuer sehr fahrlaessig. Sorry, wenn ich hier gegen Dich, der Du mir eigentlich helfen wolltest, argumentieren muss, aber ich konnte das nicht so stehen lassen.

Freundlichen
Gruss vom Frank.

Hallo,

Ich braeuchte aber eben genau jene Variable, um den
angemeldeten Nutzer zu identifizieren. Richtig debuggen laesst
es sich auch nicht, da mein HTTPS noch etwas holprig ist

wenn das das Problem ist, könnte man das testweise abschalten.

und ich bin nicht der grosse apache-Experte.

Ich auch nicht. Wirklich.

Hat irgendwer noch
Ideen, was ich noch uebersehen hab?

Eventuell d.c.s.w

Gruß,

Sebastian

schade
Mahlzeit!

Der Frank ist jetzt also der Meinung, dass ich keine Ahnung habe…

Nachdem ich jetzt verstanden habe, wie Du versuchst in Scripten in sicherheitsrelevanten Bereichen richtig zu identifizieren, authentisieren und authentifizieren, muss ich Dir leider beinahe das Recht absprechen, darüber zu urteilen, ob jemand etwas davon versteht oder nicht.
Bei der von Dir dargestellten Vorgehensweise bin ich jetzt doppelt froh, dass ich darauf verzichtet habe, Dir einen ganz anderen, richtigen Weg vorzuschlagen, denn Du hättest es nicht verstanden.

Bitte sei mir ebenfalls nicht böse, aber auch ich konnte Deinen Beitrag jetzt nicht so stehen lassen.

Mit freundlichem Gruß
und besten Wünschen für eine sichere Zukunft.

Fred

Mahlzeit!

Tach,

Bei der von Dir dargestellten Vorgehensweise bin ich jetzt
doppelt froh, dass ich darauf verzichtet habe, Dir einen ganz
anderen, richtigen Weg vorzuschlagen, denn Du hättest es nicht
verstanden.

Ich war immer und bin bereit, einzuraeumen, dass ich Dich grundlegend falsch verstanden hab. Ich bin nach wie vor neugierig ueber einen Vorschlag Deinerseits, aber eine Identifizierung anhand von Daten, die der browser des Nutzers schickt, ohne erneut eine Authentisierung zu verlangen, ist ein Weg, den ich nicht als richtig ansehe und daher nicht gehen werde.

Sag an, wie soll ich’s machen? Ich bin lernfaehig.

Mit [snip] besten Wünschen für eine sichere Zukunft.

Danke,
Gruss vom Frank.

[MOD]: bitte woanders!
Hallo Ihr beiden,

falls es euch nix aucmacht verlagert doch eure eher philosophische Diskussion aufs E-mail oder per ICQ.
Mit der ursprungsfrage hats nich mehr viel zu tun.

Danke.

Gruß
Moderator - Brett Server-Software

1 Like