Verzeichnis schützen, jedoch ohne Passworteingabe

[cr]

Hallo,

ich habe ein Verzeichnis auf meinem Webspace, in dem ein paar Dateien liegen die aber nur von beswtimmten personen benutzt werden dürfen.

eine möglichkeit die ich gefunden habe ist .htaccess...jedoch müsste der benutzer da ein passwort eingeben oder ich übermittel das passwort über die domain wie  http://benutzername:[e-mail]

Da jedoch bekommt der Benutzer und das gesamte Web die Zugangsdaten mit. Wie kann ich entwerder die Daten verschlüsselt und nicht über die Domain übergeben oder wie könnte man das verzeichnis anders schützen?

vielen dank.
cr

[Andavos]

Hallo,
der Schutz über ein Passwort ist der einzig praktikable Weg, den du hast (zumindest der mir einfällt). Alle anderen Wege sind entweder sehr unsicher oder recht unpraktisch.

Eine Möglichkeit wäre mit Cookies zu arbeiten, wie man es aus gänigen Web Applikationen (z.B. Boards) kennt, ob dies auch mit .htaccess geht, weiß ich nicht (glaube nicht).

Mit PHP ist das recht einfach, wenn kein Cookie vorhanden ist, dann fragst du ihn nach ein Passwort.
Wenn er ein Passwort eingibt, überprüfst du dies alles und setzt ein Cookie mit dem Passwort, bzw. mit dem Hash des Passworts.

Wenn er die Seite besucht und ein Cookie vorhanden ist, überprüfst du ob das PW aus dem Cookie passt und lässt ihn rein.

Nachteil: Jeder der den Cookie ergaunern kann, hat Zutritt zum System + Verzeichnisschutz ist per PHP nicht möglich.

Mehr zu Cookies hier: Cookies Tutorial

Grüße
Andavos

[Beat]

Wenn er die Seite besucht und ein Cookie vorhanden ist, überprüfst du ob das PW aus dem Cookie passt und lässt ihn rein.

Nö. Du willst echt nicht jedes mal das PW senden?
habe immer gedacht, dass Sessions das Senden eines PW abnehmen sollen, ausser beim Login.

Nachteil: Jeder der den Cookie ergaunern kann, hat Zutritt zum System + Verzeichnisschutz ist per PHP nicht möglich.

Jau, genau.
Wenn du statt dem PW eine Session-ID zur Fortsetzung der durch erfolgreiches Login eröffneten Session sendest, hast du nur noch das Problem, dass jemand die Session klauen kann, was sich aber bei geeigneten Methoden ebenfalls weitestgehend unterbinden lässt.

mfg Beat

[Andavos]

Hallo,

Wenn er die Seite besucht und ein Cookie vorhanden ist, überprüfst du ob das PW aus dem Cookie passt und lässt ihn rein.

Nö. Du willst echt nicht jedes mal das PW senden?
habe immer gedacht, dass Sessions das Senden eines PW abnehmen sollen, ausser beim Login.

Dein Browser sendet beim Reguest der Seite automatisch alle Cookie Daten, die er für diese Domain hat, sprich, bei jedem Aufruf wird, gewollt oder nicht, das Cookie mit dem PW gesendet.
Dennoch empfiehlt es sich, nach dem erfolgreichen Login per Cookie eine Session zu registieren, tut mir leid falls ich mich in dem Punkt falsch ausgedrückt habe.

(Wobei bei .htaccess wird normalerweise nach dem Login auch bei jedem weiteren Seiten-Request das Passwort (base64-kodiert) mitgesendet)

Nachteil: Jeder der den Cookie ergaunern kann, hat Zutritt zum System + Verzeichnisschutz ist per PHP nicht möglich.

Jau, genau.
Wenn du statt dem PW eine Session-ID zur Fortsetzung der durch erfolgreiches Login eröffneten Session sendest, hast du nur noch das Problem, dass jemand die Session klauen kann, was sich aber bei geeigneten Methoden ebenfalls weitestgehend unterbinden lässt.

Der Threadsteller möchte (zumindest interpretiere ich das so), dass die bestimmten Leute dauerhaft und ohne Eingabe des Passwortes die Seite nutzen können. Hier funktionieren Session nicht, da diese i.d.R. nach einer bestimmten Zeit gelöscht (~30 Min) werden und das Cookie mit der SID eh nach beenden des Browser gelöscht wird.

Natürlich könnte man ewig lebende Sessions + Session Cookies konstruieren, wäre aber extrem unschön und kein Sicherheitgewinn gegenüber von Cookie + Passwort.

MFG
Andavos

[Beat]

Du hast gewiss sicherlich ganz fest Recht mit deiner Ausführung, die mir leider im Moment etwas zu hoch ist, und ich ausserdem mit einem Bier und einer Wurst gerade zu kämpfen habe.

mfg Beat
--
Selber klauen ist schöner

[ChrisB]

Hi,

(Wobei bei .htaccess wird normalerweise nach dem Login auch bei jedem weiteren Seiten-Request das Passwort (base64-kodiert) mitgesendet)

Ersetze ".htaccess" durch "HTTP Authentification"; und streiche "normalerweise nach dem Login auch" ersatzlos, denn diese Worte haben im vorliegenden Zusammenhang keinerlei sinnvolle Bedeutung.

MfG ChrisB

[Andavos]

Hallo,

(Wobei bei .htaccess wird normalerweise nach dem Login auch bei jedem weiteren Seiten-Request das Passwort (base64-kodiert) mitgesendet)

Ersetze ".htaccess" durch "HTTP Authentification"; und streiche

Ja da hast du recht, mir lag das Wort nicht auf der Zunge.

"normalerweise nach dem Login auch" ersatzlos, denn diese Worte haben im vorliegenden Zusammenhang keinerlei sinnvolle Bedeutung.

Dieses "normalerweise" könnte man auch auf das "base64-kodiert" beziehen, da dies beim 'HTTP Digest access authentication' nicht der Fall ist, da dort MD5 und nonces verwendet werden um das Passwort zu 'verschleiern'.

Wobei, zumindest nach eigenen Erfahrungen, dieses recht selten verwendet wird, da es auch einige Nachteile aufweist.

Siehe:
http://en.wikipedia.org/wiki/Digest_access_authentication

Aber da HTTP nuneinmal ein zustandloses Protokoll ist, muss irgendetwas gesendet werden, welches den User ausweist.
Entweder das Passwort (base64 kodiert), wie beim HTTP basic access auth. oder die SID wenn man mit Sessions arbeitet.

MFG

[ChrisB]

Hi,

"normalerweise nach dem Login auch" ersatzlos, denn diese Worte haben im vorliegenden Zusammenhang keinerlei sinnvolle Bedeutung.
Dieses "normalerweise" könnte man auch auf das "base64-kodiert" beziehen

Womit "nach dem Login" immer noch unsinnig bleibt.

MfG ChrisB

[josh]

Hallo,

Also entweder du benutzt SSL und verschlüsselst damit die Kommunikation, oder das Passwort wird tatsächlich im Klartext gesendet. SSL muss aber sowohl vom Webserver als auch vom Client (in dem Fall Browser) unterstützt werden. Wie sieht denn das System aus?

Da jedoch bekommt der Benutzer und das gesamte Web die Zugangsdaten mit.

Der Benutzer sollte seine Zugangsdaten doch kennen - ansonsten macht die Authentifizierung keinen Sinn. Andere Möglichkeiten außer Passwörtern gibt es keine in diesem Anwendungsfall.

Gruß

[dedlfix]

echo $begrüßung;

ich habe ein Verzeichnis auf meinem Webspace, in dem ein paar Dateien liegen die aber nur von beswtimmten personen benutzt werden dürfen.
eine möglichkeit die ich gefunden habe ist .htaccess...jedoch müsste der benutzer da ein passwort eingeben oder ich übermittel das passwort über die domain wie  http://benutzername:[e-mail]

Diese Methode ist nicht (mehr) in allen Browsern per default freigeschaltet, fällt also sowieso weg.

Wie kann ich entwerder die Daten verschlüsselt und nicht über die Domain übergeben oder wie könnte man das verzeichnis anders schützen?

Verzeichnisschutz ist Sache desjenigen, der den Inhalt ausliefert. In deinem Fall ist es der Webserver. Etwas anderes als die bekannte Authentifizierungsmethode ist nicht vorgesehen (zumindest beim Apachen nicht zum Standard gehörend und damit nicht überall verfügbar).

Um zu verhindern, dass etwas ausgeliefert wird, legt man es am besten irgendwo neben das DocumentRoot, in ein Verzeichnis, das nicht vom Webserver ausgeliefert wird. Leider lassen nicht alle Provider zu, dass man all seine Domains auf Unterverzeichnisse des zugewiesenen Kundenverzeichnisses zeigen lassen kann, so dass man keinen nicht durch das Web erreichbaren Platz konfigurieren kann. In dem Fall kannst du dir ein Verzeichnis anlegen, das mit deny from all für alle Webzugriffe gesperrt wird.
Wie auch immer du das Verzeichnis anlegst, du brauchst nun ein Script im zugänglichen Bereich, das die gewünschte Datei durchreicht und dabei die gewünschte Zugriffberechtigung realisiert.

echo "$verabschiedung $name";

[cr]

hallo dedlfix,

danke für deine antwort und auch ein danke erstmal an alle anderen!

ich denke das eine htaccess mit deny from all sinvoll ist für meine bedürfnisse. dann werde ich mittels php (wenn die geschützte datei angezeigt werden soll) die datei in ein temporäres verzeichnis kopieren. von dort dann den aufruf zum öffnen der datei. jedoch soll die datei bzw. die in ein "freigeschaltetes" verzeichnis kopierte dann natürlich auch wieder "verschwinden" bzw gelöscht werden.

wie kann ich dies realisieren? mit einem cronjob der alle dateien die dort drin liegen regelmäßig löscht? was könnte man da sinvoller weise machen?

danke für eure hilfe

cr

[sebuzztian]

Hallo cr,

du musst nicht die Datei temporär kopieren und dann aufrufen.

Includiere doch einfach die entsprechende Datei oder gebe sie mit dem passenden Conten-header und readfile aus; je nachdem um was für Daten es sich handelt.

Grüße
sebuzztian

[cr]

Hallo sebuzztian

das versteh ich grad net ganz. lol

also das mit dem aufrufen und include ja, es handelt sich um alle arten von text und präsentationsdatein (txt,pdf,word, excel, ppt, openoffice formate usw)

kannst du mir einen hinweis dazu geben wie ich das umsetzen kann bzw an welche funktionen du dabei gedacht hast. steh da grad aufm schlauch

danke

cr

[josh]

Hallo,

Darf ich auch antworten ;-) Naja ich machs einfach mal. Includen wäre in dem Fall wirklich nicht das Richtige. Allerdings kann die bereits erwähnte readfile() Funktion eine beliebige Datei öffnen, an die PHP drankommt, diese auslesen und dann eins-zu-eins über HTTP an den Browser schicken, als hätte dieser sie direkt aufgerufen. Weil Apache hier aber automatisch den MIME-Typ "text/html" verschickt, glaubt der Browser auch, dass er HTML-Daten bekommt. Tut er aber bei den von dir genannten Dateien nicht. Deswegen muss mit der header() Funktion der richtige MIME-Typ im "Content-Type" Feld ausgegeben werden (aber vor readfile() sonst gibts nur zu gut bekannte Probleme). Um an den passenden Typ zu kommen kann man zum Beispiel von der Dateiendung ausgehen. Lies am Besten in der PHP-Dokumentation über die genannten Funktionen nach.

Gruß

[cr]

hallo!

ja ich finde die konstruktive zusammenarbeit grad im moment sehr gut und hilfreich. auch vom ansturm bin ich etwas platt...dachte eher das thema sei "langweilig" für den großteil der menschen hier...aber es scheint anders zu sein.. :-) dafür danke an alle!

diese variante scheint mir etwas umständlich mit dem header, da ich wirklich sämtliche text/schreibdateien nutze und evtl. auch spontan neue hinzukommen...
ich benötige also einen verzeichnisschutz der kompatibel zu allen formaten ist ohne extra einstellungen...deshalb erscheint mir im moment die variante mir aus dem geschützten bereich herauskopieren und dann zu öffnen als praktikabelste...jedoch noch eine frage bezüglich des unlink/löschens der datei anschließend...ist es auch möglich, dass ich die datei nur temporär zu verschieben, zu öffnen und nach dem öffnen ist sie gleich wieder weg (weil nur temorär verschoben)?

cr

[josh]

Hallo,

ja ich finde die konstruktive zusammenarbeit grad im moment sehr gut und hilfreich. auch vom ansturm bin ich etwas platt...dachte eher das thema sei "langweilig" für den großteil der menschen hier...aber es scheint anders zu sein.. :-) dafür danke an alle!

Ich glaube, eher mir ist langweilig ;-)

ist es auch möglich, dass ich die datei nur temporär zu verschieben, zu öffnen und nach dem öffnen ist sie gleich wieder weg (weil nur temorär verschoben)?

Problem: Es gibt keine Möglichkeit mitzubekommen, ob und wann die Datei aufgerufen wurde. Es sei denn, Apache kann Dateien automatisch löschen. Davon weiss ich aber nichts. Eine andere Möglichkeit wäre, die Dateien irgendwo mit einem Timestamp zu listen und bei jeder Ausführung des Scriptes (oder eines cronjobs) alle alten Dateien zu löschen.

Noch mal zu readfile() und co: Es gibt eine Funktion, die den Typ auslesen kann. Da steht aber was von deprecated :-(

Gruß

[Tom]

Hello,

Noch mal zu readfile() und co: Es gibt eine Funktion, die den Typ auslesen kann. Da steht aber was von deprecated :-(

Ersten deprecated, zweitens ist sie nicht in allen Distributionen enthalten. Auf Windows-Systemen benötigt man auch noch das magic.mime-File, das ist auch nicht immer vorhanden.

Ein harzliches Glückauf

Tom vom Berg

[joschjo]

Hallöle,

lese gerade mit und frage mich: Gibt es dann wirklich keine gescheite Lösung den Typ herausufinden? Weil dann kann ich crs bedenken verstehen ...

Gruß

[josh]

Hallo,

lese gerade mit und frage mich: Gibt es dann wirklich keine gescheite Lösung den Typ herausufinden? Weil dann kann ich crs bedenken verstehen ...

Offensichtlich gibt es so was nicht, leider. Aber ein Webserver wie Apache muss ja auch den Typ feststellen. So wie ich die Konfigurationsdateien interpretiere, wird sowohl ein Magic MIME Modul (so wie bei PHP) verwendet als auch eine Zuordnung über die Dateiendung vorgenommen - falls die entsprechenden Module vorhanden bzw. aktiviert sind. Bei unbekannten Dateitypen verwendet mein Apache text/plain. Gibt es da keine Vereinbarung, was man angeben soll, falls der Typ unbekannt ist?

Man könnte jetzt natürlich immer text/plain angeben und mit Content-Disposition den Download erzwingen.

Ich finde diese Möglichkeit immer noch besser als das temporäre Verzeichnis. Aber vielleicht hat jemand anderes noch eine völlig neue Idee...

Gruß

[josh]

Hallo,

ich denke das eine htaccess mit deny from all sinvoll ist für meine bedürfnisse. dann werde ich mittels php (wenn die geschützte datei angezeigt werden soll) die datei in ein temporäres verzeichnis kopieren. von dort dann den aufruf zum öffnen der datei. jedoch soll die datei bzw. die in ein "freigeschaltetes" verzeichnis kopierte dann natürlich auch wieder "verschwinden" bzw gelöscht werden.

Ist da eigentlich nicht ein "order deny, allow" vor dem "deny from all" notwendig?

Das mit dem temporären Verzeichnis verstehe ich so, dass dieses öffentlich zugänglich ist. Das wäre eine Sicherheitslücke. Mit readfile kann die Datei direkt ausgegeben werden (Content-Type nicht vergessen!).

Gruß

[josh]

Hallo,

Nachtrag: Laut der Apache 2.2 Dokumentation ist "Order Deny,Allow" bereits der Default-Wert und in diesem Fall auch nicht notwendig.

Gruß

[Tom]

Hello,

ich denke das eine htaccess mit deny from all sinvoll ist für meine bedürfnisse.

Dann kannst Du das bei der Apache-Standard-Installation bereits "eingebaute .htaccess" benutzen und einfach das Verzeichnis .ht_irgendwas nennen. Durch die Vorsilbe '.ht' wird der Inhalt des Verzeichnisses dann automatisch nicht angezeigt.

Probier es einfach mal aus, ob das bei Dir auch so ist.

Ein harzliches Glückauf

Tom vom Berg

[Rolf]

Hallo Tom,

Dann kannst Du das bei der Apache-Standard-Installation bereits "eingebaute .htaccess" benutzen
und einfach das Verzeichnis .ht_irgendwas nennen.
Durch die Vorsilbe '.ht' wird der Inhalt des Verzeichnisses dann automatisch nicht angezeigt.
Probier es einfach mal aus, ob das bei Dir auch so ist.

so, habe ich gemacht.
Sowohl online als auch local stört den Apache das .ht_irgendwas nicht
bei der Auslieferung von Dateien.
Muss das vielleicht irgendwo/irgendwie aktiviert werden?

mbG Rolf

[Tom]

Hello,

Probier es einfach mal aus, ob das bei Dir auch so ist.
so, habe ich gemacht.
Sowohl online als auch local stört den Apache das .ht_irgendwas nicht
bei der Auslieferung von Dateien.
Muss das vielleicht irgendwo/irgendwie aktiviert werden?

Das ist normalerweise in der Stammkonfiguration aktiviert, durch genau das Stück Script, dass man hier vorgeschlagen hat für eine externe .htaccess

137 # The following lines prevent .htaccess and .htpasswd files from being
138 # viewed by Web clients.
139 #
140 <Files ~ "^.ht">
141    Order allow,deny
142    Deny from all
143 </Files>

In meiner /etc/apache2/apache2.conf sind es diese Zeilen. Kann sein, dass es bei einer anderen Distribution oder wenn man schon etwas geändert hat, wonders im Script steht.
In meinem Xampp sind es in der C:\Programme\xampp\apache\conf\httpd.conf z.B. die Zeilen 242-248, aber sie sind absolut gleichlautend. Du kannst also bewuem danach suchen.

Anderenfalls kannst Du diesen Abschnitt auch in eines Deiner Verzeichnisse mit einer .htaccess-Datei einfügen. Es gint dann für alle Files und Verzeichnisse in und unter diesem Verzeichnis.

Ein harzliches Glückauf

Tom vom Berg

[Rolf]

Hallo Tom,

folgendes habe ich auf Win32 Apache 2.2.2 gefunden:
<FilesMatch "^.ht">
    Order allow,deny
    Allow from all
</FilesMatch>
Bei einer Änderung in:
<FilesMatch ~ "^.ht">
weigert sich der Indianer zu starten.
und bei
<Files ~ "^.ht">
passiert wie oben gar nix ... :-(
Also:

• Ordner-Namen mir .ht_xyz haben keine Auswirkung
• eine .htaccess mit
        <Files "^.ht">
            Order allow,deny
            Deny from all
        </Files>
    erzeugt keinerlei Wirkung ... :-(
• dagegen wird mit
        <Files ~ "^.ht">
        <FilesMatch "^.ht">
        <FilesMatch ~ "^.ht">
    ein 500-er Error ausgelöst.
  So ist ein Zugriff zwar verhindert, aber elegant ist was anderes!

mbG Rolf

[dedlfix]

echo $begrüßung;

[viele Fehlversuche]
So ist ein Zugriff zwar verhindert, aber elegant ist was anderes!

Obwohl das verstecken von .ht* mittlerweile (es war nicht immer so) zur Defaultkonfiguration des Apachen gehört, zeigt sich doch an diesem Beispiel deutlich, dass man es auch irgendwie ausgeschaltet bekommt. Deswegen(, lieber Tom,) bleibe ich lieber beim Vorschlagen, einen Ordner außerhalb des DocumentRoots anzulegen.

echo "$verabschiedung $name";

[Tom]

Hello,

Du hast Recht.
Das funktioniert so nicht.
Und auf Windows schon gar nicht, weil eine ".ht_irgendwas" nicht einfach so angelegt werden kann.

http://selfhtml.bitworks.de/forum/.ht_test/index.html

Das Verzeichnis ist nicht lesbar, aber die Datei darin dann doch wieder.

Allerdings werden alle Files, die entsprechen gekennzeichnet sind, NICHT ausgeliefert.
Die Direktive heißt ja auch <files> und nicht <directory>.
Hätte ich also vorher drüber nachdenken können *sorry*

Aber das brachte mich nun auf diese Idee:

<Directory ~ "^/var/www/selfhtml.bitworks.de/htdocs/forum/.hdir_">
            Order Deny,Allow
            Deny from All
        </Directory>

Im Verzeichnis

http://selfhtml.bitworks.de/forum/.hdir_test/

liegt auch wieder eine index.html.

http://selfhtml.bitworks.de/forum/.hdir_test/index.html

und die wird nun nicht mehr ausgeliefert.

Leider kann man <directory>-Direktiven nicht mehr in der .htaccess festlegen.

siehe: http://httpd.apache.org/docs/2.2/mod/core.html#directory

Ein harzliches Glückauf

Tom vom Berg

[Tom]

Hello,

<Directory ~ "^/var/www/selfhtml.bitworks.de/htdocs/forum/.hdir_">

was wohl auch heißen müsste:

<Directory ~ "^/var/www/selfhtml.bitworks.de/htdocs/forum/.hdir_">

was aber hier im Moment keinen Unterschied macht, sich aber zu einer Lücke auswachsen könnte, wenn auch mit sehr geringer Wahrscheinlichkeit.

Ein harzliches Glückauf

Tom vom Berg

[Der Martin]

Hallo Tom,

Das funktioniert so nicht.
Und auf Windows schon gar nicht, weil eine ".ht_irgendwas" nicht einfach so angelegt werden kann.

wieso nicht?
Aus nahezu jeder Windows-Anwendung kann ich eine Datei als ".ht_fiffi" speichern. Und auf der Kommandozeile ist
 ren anyfile ".ht_flower"
ebensowenig ein Problem, wie vergleichbare Operationen mit dem Kopieren oder Erzeugen von Dateien.

Nur der Explorer stellt sich da etwas dämlich an.
Für die ursprüngliche Frage ist das natürlich völlig unerheblich.

So long,
 Martin

[Tom]

Hello,

wieso nicht?
Nur der Explorer stellt sich da etwas dämlich an.

Das war auch nur ein gemeiner Seitenhieb auf unser aller Lieblingsbetrübssystem. :-)

Ein harzliches Glückauf

Tom vom Berg

[dedlfix]

echo $begrüßung;

Leider kann man <directory>-Direktiven nicht mehr in der .htaccess festlegen.

Warum auch? Man ist da ja bereits in einem.

echo "$verabschiedung $name";

[Tom]

Hello,

folgendes habe ich auf Win32 Apache 2.2.2 gefunden:

Wo? Es muss an der passenden Stelle stehen.

<FilesMatch "^.ht">
    Order allow,deny
    Allow from all
</FilesMatch>

Bei einer Änderung in:

<FilesMatch ~ "^.ht">
weigert sich der Indianer zu starten.

Das würde ich auch tun

<Files ~ "^.ht">

wäre richtig.

und bei
<Files ~ "^.ht">
passiert wie oben gar nix ... :-(

Teste ich gleich nochmal bei meiner Installation

Ein harzliches Glückauf

Tom vom Berg