Wie eine http-Seite mit Zugriffsbeschränkungen versehen?

[Thak Hinnerk]

Hallo,

ich möchte eine Webseite (als Unterseite einer Webseite) nur für einen
begrenzten Personenkreis zugänglich machen - am bestern per Passwort
oder Name/Passwort.

Wie läßt sich sowas realisieren? Vielleicht helfen einfach nur einige
wenige Stichworte, zudenen ich dann im WWW eine Anleitung finde.

--
Thak.

[Martin Schoenbeck]

Hallo Thak,

Thak Hinnerk schrieb:

> Wie läßt sich sowas realisieren? Vielleicht helfen einfach nur einige
> wenige Stichworte, zudenen ich dann im WWW eine Anleitung finde.

.htaccess
htpasswd

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

[Thak Hinnerk]

Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:

> .htaccess
> htpasswd

Hallo,

ich habe die beiden ausprobiert. Nach der Anleitung von Selfhtml. Es
funktioniert bis zur Passwortabfrage. Dann kommt jedoch nur ein
'Internal Server Error'. Leider sagt der IE nicht, um was für einen
Fehler es sich handelt.

In der Selfhtml-Anleitung steht:

> Es sollte der vollständige absolute Pfadname angegeben werden. Das ist
also nicht der Pfad ab dem Wurzelverzeichnis Ihres Web-Projekts. Fragen
Sie dazu gegebenenfalls Ihren Webhosting-Provider oder Webmaster. Sie
können zwar auch eine Angabe machen, die relativ zum Wurzelverzeichnis
des Webservers (das oft /usr/lib/apache/ lautet) interpretiert wird. In
der Regel ist das aber ein zentrales Installationsverzeichnis, auf das
Sie keinen Zugriff haben.

_Sollte_ ist nicht _muß_. Sollte mein Problem oben damit zusammenhängen,
das ich die Datei .-htusers im gleichem Verzeichnis abgelegt habe wie
die .htaccess? (Mein Provider hat mir die Info bzgl. des absoluten
Pfades noch nicht geschickt)
Falls dem so ist, wo kann ich die .htusers ablegen, bis mein Provider
antwortet?


--
Thak.

[Thomas 'PointedEars' Lahn]

Thak Hinnerk wrote:

> Martin Schoenbeck <ms.usene...@schoenbeck.de> wrote:
>> .htaccess
>> htpasswd
>

> […]

> ich habe die beiden ausprobiert. Nach der Anleitung von Selfhtml.

_SELFHTML_ ist jetzt fünf Jahre alt und eignete sich (leider) noch nie als
Referenz. Darüberhinaus ist obige, für die Leute, die Dir helfen könnten,
eine nutzlose Aussage.

> Es funktioniert bis zur Passwortabfrage. Dann kommt jedoch nur ein
> 'Internal Server Error'. Leider sagt der IE nicht, um was für einen
> Fehler es sich handelt.

Und meine Kristallkugel, mit der das ohne Angabe der
Konfigurationsdirektiven herauszufinden wäre, ist schon im Bett.
Sie hatte heute wieder ein sehr einen anstrengenden Tag …

> In der Selfhtml-Anleitung steht:
>
>> Es sollte der vollständige absolute Pfadname angegeben werden. Das ist
> also nicht der Pfad ab dem Wurzelverzeichnis Ihres Web-Projekts. Fragen
> Sie dazu gegebenenfalls Ihren Webhosting-Provider oder Webmaster. Sie
> können zwar auch eine Angabe machen, die relativ zum Wurzelverzeichnis
> des Webservers (das oft /usr/lib/apache/ lautet) interpretiert wird. In
> der Regel ist das aber ein zentrales Installationsverzeichnis, auf das
> Sie keinen Zugriff haben.
>
> _Sollte_ ist nicht _muß_.

Hier schon. Siehe oben.

> Sollte mein Problem oben damit zusammenhängen, das ich die Datei .-htusers
> im gleichem Verzeichnis abgelegt habe wie die .htaccess?

Grundsätzlich? Nein.

> (Mein Provider hat mir die Info bzgl. des absoluten Pfades noch nicht
> geschickt)

<http://php.net/phpinfo> könnte helfen.

> Falls dem so ist, wo kann ich die .htusers ablegen, bis mein Provider
> antwortet?

Überall.

<http://www.tty1.net/smart-questions_de.html>


PointedEars
--
Aber das Sperren der rechten Maustaste hat auch seine Vorteile: so
bleibt uns der Anblick einer ganzen Menge dilettantisch und lieblos
zusammengewurstelten Quellcodes erspart. (Ulrich 'Droeppez' Kritzner in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=5&id=31594&thread=31592)

[Thak Hinnerk]

Thomas 'PointedEars' Lahn <Point...@web.de> wrote:

> <http://php.net/phpinfo> könnte helfen.

Danke für die Mühe, aber nach ca. 25% lesens dieser Webseite habe ich
aufgegeben - weil nichts mehr verstanden.
Wie sollte ich denn überhaupt den Befehl auf den Webserver bekommen UND
ausführen? html-Dateien kann ich da hochladen, aber wie irgendwas
ausführen???

> <http://www.tty1.net/smart-questions_de.html>

Da verstehe ich den Zusammenhang gar nicht was hat die Seite mit meiner
Frage zu tun?
tty - Fernschreiber?
Was habe ich mit Hackern zu tun?
Was hat das newsnet mit Foren zu tun?
Zugegeben - nur quer gelsen und die blauen Sachen gesehen...

> _SELFHTML_ ist jetzt fünf Jahre alt und eignete sich (leider) noch nie als
> Referenz.

Oh doch, diese Sammlung hat mir in mehr als 5 Jahren sehr viele
nützliche Hilfe geleistet.

> Und meine Kristallkugel, mit der das ohne Angabe der
> Konfigurationsdirektiven herauszufinden wäre, ist schon im Bett.

Welche Direktiven? Meinst du die .htaccess?

> # .htaccess-Datei für Web-Verzeichnis Schal
> AuthType Digest
> AuthName "Bilder Weihnachtsfeier"
> AuthUserFile .htusers
> Require user Schal

Es gibt dann noch eine .htusers, die nur eine Zeile enthält:
<Name>:<Schüssel>

--
Thak.

[Martin Schilling]

Moin,

Thak Hinnerk schrieb:

> ich möchte eine Webseite (als Unterseite einer Webseite) nur für einen
> begrenzten Personenkreis zugänglich machen - am bestern per Passwort
> oder Name/Passwort.

wenn die Webseite auf deinem eigenen Rechner liegt, wo Du den Apache
selbst konfingurieren kannst/mußt - dann lies da weiter.

Wenn Du nur irgendwo Webspace gemietet hast, dann weiß dein Provider,
wie das geht - und dir wird hoffentlich ein Interface zur Verfügung
gestellt. Ich hab mir bei 1&1 die Finger wundprobiert bis ich drauf kam,
daß ich das im "Kundenlogin" machen muß...

HTH,
Martin.
--
If you get too old to serve as bad example, you can always give bad advice

[Bjoern Hoehrmann]

* Thak Hinnerk wrote in de.comm.infosystems.www.authoring.misc:

>ich habe die beiden ausprobiert. Nach der Anleitung von Selfhtml. Es
>funktioniert bis zur Passwortabfrage. Dann kommt jedoch nur ein
>'Internal Server Error'. Leider sagt der IE nicht, um was für einen
>Fehler es sich handelt.

Das steht im error_log. Wenn du darauf keinen Zugriff hast, dann kannst
du möglicher Weise durch ein passendes ErrorDocument umgehen, konkret
musst du dir die Umgebungsvariable REDIRECT_ERROR_NOTES ausgeben lassen,
in http://www.worldmusic.de/perl/dclpc-faq.txt ist mein Beispiel

Einbinden in die .htaccess Datei:

ErrorDocument 500 /cgi-bin/internal-error.pl

Das Script internal-error.pl sieht folgendermaßen aus:

#!/usr/bin/perl -w
print "Content-type: text/plain\r\n\r\n";
print "Internal Server Error: $ENV{REDIRECT_ERROR_NOTES}\n";

Vermutlich reicht es auch, eine PHP Datei mit `<?php phpinfo(); ?>` als
ErrorDocument anzugeben und dort nach REDIRECT_ERROR_NOTES zu suchen.

>_Sollte_ ist nicht _muß_. Sollte mein Problem oben damit zusammenhängen,
>das ich die Datei .-htusers im gleichem Verzeichnis abgelegt habe wie
>die .htaccess? (Mein Provider hat mir die Info bzgl. des absoluten
>Pfades noch nicht geschickt)

Der richtige Pfad sollte auch in der "phpinfo" stehen.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

[Thak Hinnerk]

Bjoern Hoehrmann <bjo...@hoehrmann.de> wrote:

> ErrorDocument 500 /cgi-bin/internal-error.pl

Danke für die Info, aber ich habe bewußt nur statische Webseiten, eben
weil ich mich dabei micht mit phhp auseinandersetzten muß.

Die Zeile oben in die .htaccess einzubinden ist kein Problem, aber was
ich mit dem Rest anfangen soll weis ich nicht, da ich keinen Pfad
cgi-bin im Bereich meiner Webseite habe.

> Vermutlich reicht es auch, eine PHP Datei mit `<?php phpinfo(); ?>` als
> ErrorDocument anzugeben und dort nach REDIRECT_ERROR_NOTES zu suchen.

Auch hier wieder: ???

Um ehrlich zu sein: Dann müssen die lieben Arbeitskollegen eben auf
Bilder der Weihnachtsfeier verzichten, weil der Betriebsrat keine freien
Zugang zu diesen Bildern duldet und ich keine Bilder auf dem
Firmenserver lassen möchte und auch keine Lust habe, mich überhaupt mit
php zu beschäftigen.



--
Thak.

[Thomas 'PointedEars' Lahn]

Thak Hinnerk wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> <http://php.net/phpinfo> könnte helfen.
>
> Danke für die Mühe, aber nach ca. 25% lesens dieser Webseite habe ich
> aufgegeben - weil nichts mehr verstanden.

Falls Englisch Dein Problem ist, es gibt auch eine deutschsprachige Version.

Falls Englisch nicht Dein Problem ist, solltest Du Dir vielleicht lieber ein
weniger technisches Hobby suchen, etwa Briefmarken sammeln. Denn es ist im
PHP-Handbuch wirklich *alles* erklärt, was PHP betrifft.

> Wie sollte ich denn überhaupt den Befehl auf den Webserver bekommen UND
> ausführen? html-Dateien kann ich da hochladen, aber wie irgendwas
> ausführen???

RTFM, STFW.

>> <http://www.tty1.net/smart-questions_de.html>
>
> Da verstehe ich den Zusammenhang gar nicht was hat die Seite mit meiner

> Frage zu tun? [weitere dumme Fragen]

Alles. Deine Fragen bisher sind allesamt *dumm*. Dort steht, wie Du
intelligente Fragen stellen kannst.

>> _SELFHTML_ ist jetzt fünf Jahre alt und eignete sich (leider) noch nie
>> als Referenz.
>
> Oh doch, diese Sammlung hat mir in mehr als 5 Jahren sehr viele
> nützliche Hilfe geleistet.

Du hast nur noch nicht gemerkt, wie Dich SELFHTML bisher in die Irre geführt
hat. Vertrau mir.

>> Und meine Kristallkugel, mit der das ohne Angabe der
>> Konfigurationsdirektiven herauszufinden wäre, ist schon im Bett.
>
> Welche Direktiven? Meinst du die .htaccess?

Natürlich. Was sonst (bei einem Virtual Host)?

>> # .htaccess-Datei für Web-Verzeichnis Schal
>> AuthType Digest

Dort muss

AuthType Basic

stehen, wenn Du die .htusers mit htpasswd(1) erstellst. Falls Du sie mit
htdigest(1) erstellt hast, muss auch das Apache-Modul mod_auth_digest auf
dem Server und für Deinen Virtual Host aktiviert sein und Du musst
zusätzlich

AuthDigestDomain …

angeben, damit `AuthType Digest' grundsätzlich funktioniert. Digest
Authentication wird aber im Unterschied zu Basic Authentication nicht von
jedem HTTP-Client unterstützt und ist AFAIK auch nicht Standard bei Hostern.

<http://httpd.apache.org/docs/2.2/de/mod/mod_auth_digest.html>

>> AuthName "Bilder Weihnachtsfeier"
>> AuthUserFile .htusers

Da steht kein absoluter Pfad. Somit wird die Datei relativ zum ServerRoot
gesucht. Wenn Du nicht zufällig einen dedizierten Server gemietet hast oder
Deinen eigenen Webserver betreibst (was ich aufgrund Deiner Fragen eher
nicht annehme), funktioniert das so nicht. Denn wenn der ServerRoot
/var/www/ ist, befindet sich Deine Site, d. h. die Daten für Deinen Virtual
Host, z. B. unter /var/www/hinnerk.example/ und Du dürftest auf
/var/www/.htusers nicht zugreifen können.

<http://httpd.apache.org/docs/2.2/de/mod/mod_authn_file.html>

>> Require user Schal

Require valid-user

genügt hier wahrscheinlich, denn:

> Es gibt dann noch eine .htusers, die nur eine Zeile enthält:

^^^^^^^^^^^^^^
> <Name>:<Schüssel>

Das soll wohl "Schlüssel" heissen? Hast Du die Datei mit htpasswd(1) oder
mit htdigest(1) erstellt?


PointedEars
--
> HTML ist keine Programmiersprache!!!11111
Wie getzt, immer noch nicht?????³ Wird's da nicht langsam mal Zeit?
repeat tablecells
until Steffi yells (Jygn zu mir in dagø <ai5oel.3...@klingforth.de>)

[Thomas 'PointedEars' Lahn]

Thak Hinnerk wrote:

> Bjoern Hoehrmann <bjo...@hoehrmann.de> wrote:
>> ErrorDocument 500 /cgi-bin/internal-error.pl
>
> Danke für die Info, aber ich habe bewußt nur statische Webseiten, eben
> weil ich mich dabei micht mit phhp auseinandersetzten muß.

Es heisst _PHP_ [1], und .pl deutet üblicherweise ein *Perl*-Script
(seltener und hier nicht sinnvoll: eine Prolog-Wissensbasis) an.

Ohne eine Programmiersprache wie PHP oder Perl, welche Dir ermöglicht, den
Pfad Deines Webspace herauszufinden, musst Du auf Rückmeldung von Deinem
Hoster warten.

> Die Zeile oben in die .htaccess einzubinden ist kein Problem, aber was
> ich mit dem Rest anfangen soll weis ich nicht, da ich keinen Pfad
> cgi-bin im Bereich meiner Webseite habe.

Das ist ein absoluter Pfad, der sich *ausserhalb* Deines Webspace befindet.
Ausserdem hat Björn geschrieben, dass es nur ein *Beispiel* ist.

> > Vermutlich reicht es auch, eine PHP Datei mit `<?php phpinfo(); ?>` als
> > ErrorDocument anzugeben und dort nach REDIRECT_ERROR_NOTES zu suchen.
>
> Auch hier wieder: ???
>
> Um ehrlich zu sein: Dann müssen die lieben Arbeitskollegen eben auf
> Bilder der Weihnachtsfeier verzichten, weil der Betriebsrat keine freien
> Zugang zu diesen Bildern duldet und ich keine Bilder auf dem
> Firmenserver lassen möchte und auch keine Lust habe, mich überhaupt mit
> php zu beschäftigen.

*facepalm*


PointedEars, mit zufällig passender Signatur
___________
[1] <http://www.kirchwitz.de/~amk/dni/netiquette>, Punkt 6
--
Snowboarder können gar kein JavaScript. Sie klicken in Dreamweaver
'was zusammen und glauben, das sei "Programmieren".
-- Andreas Hollmann in dciwam

[Thomas Hochstein]

Thak Hinnerk schrieb:

> ich habe die beiden ausprobiert. Nach der Anleitung von Selfhtml. Es
> funktioniert bis zur Passwortabfrage. Dann kommt jedoch nur ein
> 'Internal Server Error'. Leider sagt der IE nicht, um was für einen
> Fehler es sich handelt.

Das weiß er nicht, weil ihm der Server nur Fehlercodes schickt /
schicken kann; der Fehler steht im Logfile des Servers.

>> Es sollte der vollständige absolute Pfadname angegeben werden. Das ist
> also nicht der Pfad ab dem Wurzelverzeichnis Ihres Web-Projekts. Fragen
> Sie dazu gegebenenfalls Ihren Webhosting-Provider oder Webmaster. Sie
> können zwar auch eine Angabe machen, die relativ zum Wurzelverzeichnis
> des Webservers (das oft /usr/lib/apache/ lautet) interpretiert wird. In
> der Regel ist das aber ein zentrales Installationsverzeichnis, auf das
> Sie keinen Zugriff haben.
>
> _Sollte_ ist nicht _muß_. Sollte mein Problem oben damit zusammenhängen,
> das ich die Datei .-htusers im gleichem Verzeichnis abgelegt habe wie
> die .htaccess?

Ja.

Du mußt Dir das folgendermaßen vorstellen:

Die Webseiten, die Du aufrufst, liegen auf dem Server ganz normal in
Verzeichnissen. Dabei ist das oberste Verzeichnis Deiner Website (also
"http://domain.example/") natürlich nicht das oberste Verzeichnis auf
dem Server, sondern es entspricht bspw. dem Verzeichnis
"/home/benutzer27/webseiten/domain.example/". Dieses Verzeichnis auf
der Festplatte des Servers, daß dem obersten Verzeichnis der
jeweiligen Website entspricht, nennt man auch "DocumentRoot" (denn so
wird es in der Serverkonfiguration bezeichnet).

Der Webserver muß jetzt wissen, in welchem Verzeichnis er Deine
.htusers-Datei finden soll, und das funktioniert regelmäßig nur mit
einer absoluten Angabe, weil eine relative Angabe nicht von Deinem
DocumentRoot ausgeht.

Du mußt also feststellen, welches Verzeichnis Dein DocumentRoot ist,
und dann den Rest des Pfades anhängen.

Nehmen wir an, Deine .htusers liegt (vom Web aus gesehen) in
"http://domain.example/geheim/.htusers". Das entspräche dann in obigem
Beispiel von der Festplatte des Servers aus gesehen
"/home/benutzer27/webseiten/domain.example/geheim/.htusers".

> (Mein Provider hat mir die Info bzgl. des absoluten
> Pfades noch nicht geschickt)

Du kannst das DocumentRoot selbst feststellen, wenn Dir PHP zur
Verfügung steht.

Lege auf Deinem Webspace eine Datei "test.php" (oder sonstwie) an, die
nur folgenden Inhalt enthält:

<?php
phpinfo();
?>

Dann rufst Du diese Seite mit dem Webbrowser auf. Sie zeigt Dir jetzt
die gesamte PHP-Konfiguration an. Jetzt begibst Du Dich ziemlich ans
Ende der (langen) Seite und suchst nach den Überschriften
"Environment" oder "PHP Variables" und dort nach den Angaben zu
"DOCUMENT_ROOT" oder "_SERVER["DOCUMENT_ROOT"]". Du kannst auch
einfach mit der Suchfunktion Deines Browsers auf der Seite nach
"DOCUMENT_ROOT" suchen.

Der Eintrag, der dahinter steht, ist das gesuchte DocumentRoot, also
der absolute Pfad zum obersten Verzeichnis Deines Webspace. Daran
hängst Du den Rest Deines Pfades bis zur .htuser einfach an.

Lösche danach die Datei "test.php" (oder wie auch immer), damit nicht
jeder die Konfiguration des Servers ansehen kann.


Alternativ kannst Du auch einfach in das Verzeichnis, in dem die
.htuser kommen soll, eine PHP-Datei mit folgendem Inhalt ablegen:

<?php
print (_SERVER["SCRIPT_FILENAME"]);
?>

Das sollte Dir den Dateinamen dieser Datei auf der Festplatte des
Severs anzeigen. Da ersetzt Du dann einfach am Ende des Pfades den
Namen der PHP-Datei durch ".htusers".

> Falls dem so ist, wo kann ich die .htusers ablegen, bis mein Provider
> antwortet?

Die Frage ist nicht, wo Du sie ablegen kannst, sondern wie Du dem
Webserver sagst, wo sie liegt. :)

Ein letzter Tip: Du solltest, wenn alles funktioniert, prüfen, ob man
die .htaccess- und .htusers-Dateien vom Web her aufrufen kann. Falls
ja, willst Du das vielleicht abstellen, indem Du in die .htaccess noch
folgende Zeilen aufnimmst:

<FilesMatch "^\.">
order allow,deny
deny from all
</FilesMatch>

Das sperrt den Aufruf aller Dateien durch den Webserver, die mit einem
Punkt beginnen.

Ich hoffe, das hat Dir weitergeholfen.

Falls nicht, einfach noch einmal fragen, ggf. auch in
de.comm.software.webserver, wenn es um die .htaccess-Datei geht; das
wäre strenggenommen sogar die passendere Gruppe.

Grüße & einen guten Start in die Woche,
-thh

[Stefan Froehlich]

On Mon, 16 Jan 2012 08:19:53 Thomas Hochstein wrote:
> Der Webserver muß jetzt wissen, in welchem Verzeichnis er Deine
> .htusers-Datei finden soll, und das funktioniert regelmäßig nur mit
> einer absoluten Angabe

Es wird sicherlich einen guten, technischen Grund dafuer geben, dass
man fuer die Datei mit Benutzernamen und Passwoertern nicht "im gleichen
Verzeichnis wie .htaccess" angeben _kann_. Aber es ist aus Anwendersicht
eine der bescheuertsten Design-Ideen, seit es Apache gibt, ich haette
mir das schon haeufig gewuenscht. :-(

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Geht nicht!? Geht doch: Stefan.
(Sloganizer)

[Thomas 'PointedEars' Lahn]

Thomas Hochstein wrote:

> Ein letzter Tip: Du solltest, wenn alles funktioniert, prüfen, ob man
> die .htaccess- und .htusers-Dateien vom Web her aufrufen kann. Falls
> ja, willst Du das vielleicht abstellen, indem Du in die .htaccess noch
> folgende Zeilen aufnimmst:
>
> <FilesMatch "^\.">
> order allow,deny
> deny from all
> </FilesMatch>
>
> Das sperrt den Aufruf aller Dateien durch den Webserver, die mit einem
> Punkt beginnen.

Korrekt und effizienter ist

<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy all
</Files>

so wie es auch in der Default-Apache-Konfiguration (hier: apache2.conf)
steht. Denn man möchte in der Regel _nicht_ den Zugriff auf *alle* Dateien
verbieten, deren Name mit einem Punkt beginnt.

Für `FilesMatch' bzw. `Files' wird jedoch das Privileg "AllowOverride All"
benötigt, was Hoster ihren Kunden aus Sicherheitsgründen regelmässig nicht
gewähren.

<http://httpd.apache.org/docs/2.2/de/mod/core.html#filesmatch>

Hoster, welche diesen Apache-Default abschalten, gehören jedoch geLARTet,
nicht gestreichelt.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

[Thomas 'PointedEars' Lahn]

Stefan Froehlich wrote:

> On Mon, 16 Jan 2012 08:19:53 Thomas Hochstein wrote:
>> Der Webserver muß jetzt wissen, in welchem Verzeichnis er Deine
>> .htusers-Datei finden soll, und das funktioniert regelmäßig nur mit
>> einer absoluten Angabe
>
> Es wird sicherlich einen guten, technischen Grund dafuer geben, dass
> man fuer die Datei mit Benutzernamen und Passwoertern nicht "im gleichen
> Verzeichnis wie .htaccess" angeben _kann_.

Man kann es ja. Bloss muss man den absoluten Pfad des "gleichen
Verzeichnis"ses kennen, da relative Pfade beginnend vom ServerRoot (z. B.
/etc/apache2) aufgelöst werden, nicht vom DocumentRoot (z. B.
/var/www/froehlich.priv.at/) [1].

Apache basiert auf NCSA¹ HTTPd [2]. Die relative Schreibweise ermöglicht
es, dass z. B. alle .htaccess auf einem Server mit wenig Overhead und
Wartungsaufwand dieselbe globale Nutzerdatenbank referenzieren können. Das
war, als das Web noch in den Kinderschuhen steckte (vor HTTP/1.1 Virtual
Hosts und ähnlichen Errungenschaften), wahrscheinlich in der Mehrzahl der
Fälle sinnvoll. Z. B. kann so ein RZ einer Uni ihren Studenten und
Lehrpersonen ermöglichen, Teile ihrer persönlichen Website mit ihrem zentral
verwalteten Benutzerpasswort zu schützen und anderen Personen über deren
Benutzernamen, Gruppenzugehörigkeit oder Protokolladresse Zugang zu
gewähren, ohne sie nach ihren Benutzerpasswörtern fragen zu müssen:

AuthType Basic
AuthUserFile .htusers
AuthGroupFile .htgroups

# ich selbst und Bekannte
Require user stfr lath-cs hoth-iu

# alle Informatik-Erstsemester
Require group cs101

# vom Wohnheim aus ohne Passwortabfrage
Allow from 10.0.42.23

Satisfy Any

> Aber es ist aus Anwendersicht eine der bescheuertsten Design-Ideen, seit
> es Apache gibt, ich haette mir das schon haeufig gewuenscht. :-(

Eine Möglichkeit, das zu definieren (etwa eine Variable, spezielle Notation
oder besondere Direktive) wäre nett, ja. Vor allem Umzüge werden so bei
Virtual Hosts unnötig verkompliziert.


PointedEars
___________
¹ National Center for Supercomputing Applications, eine Abteilung der
University of Illinois at Urbana-Champaign [1].

[1] <http://httpd.apache.org/docs/2.2/de/mod/mod_authn_file.html>
[2] <http://httpd.apache.org/ABOUT_APACHE.html>
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:1

[Stefan Froehlich]

On Mon, 16 Jan 2012 12:36:32 Thomas 'PointedEars' Lahn wrote:
> > Es wird sicherlich einen guten, technischen Grund dafuer geben, dass
> > man fuer die Datei mit Benutzernamen und Passwoertern nicht "im
> > gleichen Verzeichnis wie .htaccess" angeben _kann_.

> Man kann es ja. Bloss muss man den absoluten Pfad des "gleichen
> Verzeichnis"ses kennen, da relative Pfade beginnend vom ServerRoot (z. B.

> /etc/apache2) aufgelöst werden, [...]

Ich hatte "im gleichen Verzeichnis wie .htaccess" auch mit
Anfuehrungszeichen geklammert, um genau diese Interpretation
auszuschliessen. Wiewohl der status quo manchmal ganz hilfreich
ist, um das:

> [...] alle .htaccess auf einem Server mit wenig Overhead und

> Wartungsaufwand dieselbe globale Nutzerdatenbank referenzieren können.

zu erreichen, haette ich _auch_ gerne eine alternative Syntax, die
relative Pfade ausgehend vom Standort der .htaccess aufloest.

Beispielsweise binde ich haeufig Software ueber symbolische Links in
vhosts ein. Da waere es mehr als praktisch in der (gemeinsamen, weil immer
gleichen) .htaccess mit einer Angabe wie "../.htpasswd" (mit welcher
zusaetzlichen Notation auch immer) die Zugaenge des jeweiligen vhosts
verwenden zu koennen, anstatt zwangsweise die .htaccess fuer die einzelnen
vhosts replizieren zu muessen, weil jeweils eine eigene Passwort-Datei
verwendet wird.

> Vor allem Umzüge werden so bei Virtual Hosts unnötig verkompliziert.

Auch das, ja.

Apache kann inzwischen _so_ viel, dass mich diese Luecke wirklich erstaunt.
Eventuell gibt es ja Sicherheitsueberlegungen, die dagegen sprechen?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Für zornige Katzen, gegen die Stunden des Wahns!
(Sloganizer)

[Thomas Braun]

Thomas 'PointedEars' Lahn wrote:

>> Da verstehe ich den Zusammenhang gar nicht was hat die Seite mit meiner
>> Frage zu tun? [weitere dumme Fragen]
>
> Alles. Deine Fragen bisher sind allesamt *dumm*. Dort steht, wie Du
> intelligente Fragen stellen kannst.

Schade das es kein entsprechendes Dokument gibt in dem steht wie gutes
Benehmen funktioniert und man intelligente Antworten gibt *ohne* andere zu
beleidigen - du hättest das bitter nötig.

Du hast das richtig erkannt - ich lege keinen Wert auf eine Antwort von
dir.

[Thomas 'PointedEars' Lahn]

Stefan Froehlich wrote:

[AuthUserFile relativ zum DocumentRoot oder CWD]

> Apache kann inzwischen _so_ viel, dass mich diese Luecke wirklich
> erstaunt. Eventuell gibt es ja Sicherheitsueberlegungen, die dagegen
> sprechen?

Unwahrscheinlich. Die Zugriffsmöglichkeit über den absoluten Pfad ist
sicherheitstechnisch wesentlich brisanter.

Siehe auch:

<https://issues.apache.org/bugzilla/show_bug.cgi?id=25469>
<https://issues.apache.org/bugzilla/show_bug.cgi?id=45302>


PointedEars
--
Lass es mich so ausdrücken: Eigentlich werde ich keine Zeit haben, aber die
fürs Usenet übliche nehme ich mir. Nähme ich mir noch zusätzlich was vor,
würde ich womöglich das tun, um nicht das, das ich tun sollte, tun zu
müssen.
(Christoph Päper in <darw/> <avl5ul$30fp$1...@ariadne.rz.tu-clausthal.de>)

[Thak Hinnerk]

Thomas Hochstein <t...@inter.net> wrote:

> Ich hoffe, das hat Dir weitergeholfen.

Ja, grossen Dank, DAS war eine Antwort mit der ich was anfangen kann.
Ich werde jetzt mal ein wenig testen.

--
Thak.

[Thomas 'PointedEars' Lahn]

Thomas Hochstein wrote:

> Nehmen wir an, Deine .htusers liegt (vom Web aus gesehen) in
> "http://domain.example/geheim/.htusers". Das entspräche dann in obigem
> Beispiel von der Festplatte des Servers aus gesehen
> "/home/benutzer27/webseiten/domain.example/geheim/.htusers".

Nachtrag:

Es wird aus Sicherheits- und Wartungsgründen *dringend* empfohlen, die
Dateien für HTTP-Authentication _nicht_ im oder unterhalb des DocumentRoot
abzulegen. Also z. B. gerade _nicht_ als

/home/benutzer27/webseiten/domain.example/geheim/.htusers'

wenn

/home/benutzer27/webseiten/domain.example/

der DocumentRoot ist. Sondern z. B. als

/home/benutzer27/webseiten/.htusers

Wenn sich eine Ablage im oder unterhalb des DocumentRoot nicht vermeiden
lässt, sollte optimal der Hoster oder das Hosting gewechselt werden. Oder
die Datei sollte im DocumentRoot abgelegt werden und die erwähnte Files-
bzw. FilesMatch-Direktiven sollte in Kraft sein.

Es sollte jedoch unbedingt vermieden werden, die .htusers-Datei in das zu
schützende Verzeichnis zu legen, da es sonst möglich sein könnte, diese
Datei herunterzuladen [1]. Der Passwort-Teil in einer .htusers-Datei für
Apache ist jeweils entweder eine spezielle MD5-Prüfsumme des Passworts oder
es ist das mit (mit crypt(3)) DES-verschlüsselte Passwort; diese können –
z. B. mit Crack(1) – relativ leicht entschlüsselt werden (siehe auch
htpasswd(1) und [2]).


PointedEars
___________

[1] <http://httpd.apache.org/docs/2.2/mod/mod_authn_file.html>, Abschnitt
"Security".
[2] <http://de.wikipedia.org/wiki/Data_Encryption_Standard>
--
Nimm VerBrecherSCRIPT, denn das ist kein JavaScript-Objekt, wird also bei
keinem vernünftigen Browser geschweige denn auf einer vernünftigen Plattform
funktionieren, so daß Du auch [...] gleich mit VBSCRIPT arbeiten kannst und
dies auch tun solltest. -- Georg Maaß in dcljs

[Gustaf Mossakowski]

Stefan Froehlich schrieb:

> Apache kann inzwischen _so_ viel, dass mich diese Luecke wirklich erstaunt.
> Eventuell gibt es ja Sicherheitsueberlegungen, die dagegen sprechen?

Vielleicht ist das Interesse an einer Weiterentwicklung in diesem
Bereich gering. Neben der standardmäßig nicht sonderlich sicheren
Paßwortverschlüsselung spricht ja auch das nicht oder nur umständlich
mögliche Abmelden gegen die Verwendung dieser Authentifizierungsmethode.
Das sind natürlich keine Sicherheitsüberlegungen in puncto relativer
oder absoluter Pfad, aber generelle gegen die Verwendung von HTTP Auth.

Viele Grüße
Gustaf

[U l f Kadner]

Am 16.01.2012 08:19, schrieb Thomas Hochstein:

> Die Webseiten, die Du aufrufst, liegen auf dem Server ganz normal in
> Verzeichnissen. Dabei ist das oberste Verzeichnis Deiner Website (also
> "http://domain.example/") natürlich nicht das oberste Verzeichnis auf
> dem Server, sondern es entspricht bspw. dem Verzeichnis
> "/home/benutzer27/webseiten/domain.example/". Dieses Verzeichnis auf
> der Festplatte des Servers, daß dem obersten Verzeichnis der
> jeweiligen Website entspricht, nennt man auch "DocumentRoot" (denn so
> wird es in der Serverkonfiguration bezeichnet).
>
> Der Webserver muß jetzt wissen, in welchem Verzeichnis er Deine
> .htusers-Datei finden soll, und das funktioniert regelmäßig nur mit
> einer absoluten Angabe, weil eine relative Angabe nicht von Deinem
> DocumentRoot ausgeht.
>
> Du mußt also feststellen, welches Verzeichnis Dein DocumentRoot ist,
> und dann den Rest des Pfades anhängen.
>
> Nehmen wir an, Deine .htusers liegt (vom Web aus gesehen) in
> "http://domain.example/geheim/.htusers".

> Das entspräche dann in obigem
> Beispiel von der Festplatte des Servers aus gesehen
> "/home/benutzer27/webseiten/domain.example/geheim/.htusers".

Nur der Vollständigkeit halber:

Auch das muss nicht zwingend richtig sein. Wenn die Webpräsenz z.B. je
Kunde chrootet ist, dann findet sich noch eine "Zwischenstufe" und der
Nutzer der in der chrooted Umgebung seinen Webspace hat kann garnicht
aufs eigentliche Serverroot zugreifen. Dann könnte z.B.
/webseiten/domain.example/geheim/.htusers die nötige absolute Angabe
sein wenn das Basisverzeichnis der chroot Umgebung auf /home/benutzer27
zeigt.

Das gibts bei zahlreichen Webspaceanbietern so in der Form.

Gruß, Ulf

[Thomas Hochstein]

Thomas 'PointedEars' Lahn schrieb:

> Es wird aus Sicherheits- und Wartungsgründen *dringend* empfohlen, die
> Dateien für HTTP-Authentication _nicht_ im oder unterhalb des DocumentRoot
> abzulegen. Also z. B. gerade _nicht_ als
>
> /home/benutzer27/webseiten/domain.example/geheim/.htusers'
>
> wenn
>
> /home/benutzer27/webseiten/domain.example/
>
> der DocumentRoot ist. Sondern z. B. als
>
> /home/benutzer27/webseiten/.htusers

Korrekt. Das ist allerdings vergleichsweise unproblematisch, weil man
den Zugriff via HTTP auf diese Dateien unterbinden kann.

Solange - wie im Regelfall - Benutzername und Paßwort (bei jedem
Request) unverschlüsselt übertragen werden (denn welcher Massenhoster
bietet für seine Webspace-Pakete Zugriff via SSL an?), halte ich das
für ein für die Praxis irrelevantes Problem.

> Es sollte jedoch unbedingt vermieden werden, die .htusers-Datei in das zu
> schützende Verzeichnis zu legen, da es sonst möglich sein könnte, diese
> Datei herunterzuladen [1]. Der Passwort-Teil in einer .htusers-Datei für
> Apache ist jeweils entweder eine spezielle MD5-Prüfsumme des Passworts oder
> es ist das mit (mit crypt(3)) DES-verschlüsselte Passwort; diese können –
> z. B. mit Crack(1) – relativ leicht entschlüsselt werden (siehe auch
> htpasswd(1) und [2]).

Selbst das halte ich angesichts einer unverschlüsselten
Paßwort-Übertragung für ein vergleichsweise geringes Problem.

-thh

[Thomas Hochstein]

U l f Kadner schrieb:

> Auch das muss nicht zwingend richtig sein. Wenn die Webpräsenz z.B. je
> Kunde chrootet ist, dann findet sich noch eine "Zwischenstufe" und der
> Nutzer der in der chrooted Umgebung seinen Webspace hat kann garnicht
> aufs eigentliche Serverroot zugreifen. Dann könnte z.B.
> /webseiten/domain.example/geheim/.htusers die nötige absolute Angabe
> sein wenn das Basisverzeichnis der chroot Umgebung auf /home/benutzer27
> zeigt.

Ah, das hatte ich gar nicht bedacht, Du hast recht.

Dann müßte aber via phpinfo() auch dieser "scheinbar" absolute Pfad
angezeigt werden, oder?

Grüße,
-thh

[Thomas Hochstein]

Thomas 'PointedEars' Lahn schrieb:

> Thomas Hochstein wrote:
>> <FilesMatch "^\.">
>> order allow,deny
>> deny from all
>> </FilesMatch>
>>
>> Das sperrt den Aufruf aller Dateien durch den Webserver, die mit einem
>> Punkt beginnen.
>
> Korrekt und effizienter ist
>
> <Files ~ "^\.ht">
> Order allow,deny
> Deny from all
> Satisfy all
> </Files>

Die Dokumentation empfiehlt, wenn ich sie richtig lese, statt "Files
~" besser "FilesMatch" zu verwenden. "Satisfy" scheint mir in diesem
Fall überflüssig zu sein:
| This directive is only useful if access to a particular area is being
| restricted by both username/password *and* client host address.

> [...] Denn man möchte in der Regel _nicht_ den Zugriff auf *alle* Dateien

> verbieten, deren Name mit einem Punkt beginnt.

Das ist schlicht Geschmackssache.

> Für `FilesMatch' bzw. `Files' wird jedoch das Privileg "AllowOverride All"
> benötigt, was Hoster ihren Kunden aus Sicherheitsgründen regelmässig nicht
> gewähren.
>
> <http://httpd.apache.org/docs/2.2/de/mod/core.html#filesmatch>

Ah, stimmt, das hatte ich übersehen.

Dann sollte man das lieber erst einmal weglassen, um nicht auf diese
Weise einen 500er-Fehler zu produzieren.

Grüße,
-thh
--
/'\ --- JOIN NOW! ---
\ / ASCII ribbon campaign
X against HTML
/ \ in mail and news

[Thomas 'PointedEars' Lahn]

Thomas Hochstein wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Es wird aus Sicherheits- und Wartungsgründen *dringend* empfohlen, die
>> Dateien für HTTP-Authentication _nicht_ im oder unterhalb des
>> DocumentRoot
>> abzulegen. Also z. B. gerade _nicht_ als
>>
>> /home/benutzer27/webseiten/domain.example/geheim/.htusers'
>>
>> wenn
>>
>> /home/benutzer27/webseiten/domain.example/
>>
>> der DocumentRoot ist. Sondern z. B. als
>>
>> /home/benutzer27/webseiten/.htusers
>
> Korrekt. Das ist allerdings vergleichsweise unproblematisch, weil man
> den Zugriff via HTTP auf diese Dateien unterbinden kann.

Das funktioniert solange gut, wie der Admin die Konfiguration nicht
versehentlich oder aufgrund von Inkompetenz vermurkst. Bei der Ablage
oberhalb des DocumentRoot kann man sich hingegen *sicher* sein, dass
niemand ausser Apache an die Passwortdatei herankommt.

> Solange - wie im Regelfall - Benutzername und Paßwort (bei jedem
> Request) unverschlüsselt übertragen werden (denn welcher Massenhoster
> bietet für seine Webspace-Pakete Zugriff via SSL an?),

Definiere: Massenhoster. Hier in der Schweiz gibt es mindestens einen.

> halte ich das für ein für die Praxis irrelevantes Problem.

Du irrst.

>> Es sollte jedoch unbedingt vermieden werden, die .htusers-Datei in das zu
>> schützende Verzeichnis zu legen, da es sonst möglich sein könnte, diese
>> Datei herunterzuladen [1]. Der Passwort-Teil in einer .htusers-Datei für
>> Apache ist jeweils entweder eine spezielle MD5-Prüfsumme des Passworts
>> oder es ist das mit (mit crypt(3)) DES-verschlüsselte Passwort; diese
>> können – z. B. mit Crack(1) – relativ leicht entschlüsselt werden (siehe
>> auch htpasswd(1) und [2]).
>
> Selbst das halte ich angesichts einer unverschlüsselten
> Paßwort-Übertragung für ein vergleichsweise geringes Problem.

Siehe oben. Die Wahrscheinlichkeit, dass jemand gezielt Passwörter auf
einer temporären TCP-Verbindung zwischen Client und Server mitlauscht, ist
geringer als die, dass z. B. eine Suchmaschine mittels Brute-Force-Methode
die Passwortdatei im/unterhalb des DocumentRoot liest (Google etwa probiert
mögliche Domains und Pfade durch, um möglichst viel zu indexieren).


PointedEars
--
Mozilla ist ein Webbrowser. Das ist ein Programm, dass es ermoeglicht,
Webseiten anzusehen. Das ist nicht sowas wie ein Programm, das es
Webdesignern erlaubt, den Nutzer zu belaestigen, indem man seine
Arbeitsumgebung unsinnig manipuliert. -- Boris 'pi' Piwinger in dcljs

[Thomas 'PointedEars' Lahn]

Thomas Hochstein wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Thomas Hochstein wrote:
>>> <FilesMatch "^\.">
>>> order allow,deny
>>> deny from all
>>> </FilesMatch>
>>>
>>> Das sperrt den Aufruf aller Dateien durch den Webserver, die mit einem
>>> Punkt beginnen.
>>
>> Korrekt und effizienter ist
>>
>> <Files ~ "^\.ht">
>> Order allow,deny
>> Deny from all
>> Satisfy all
>> </Files>
>
> Die Dokumentation empfiehlt, wenn ich sie richtig lese, statt "Files
> ~" besser "FilesMatch" zu verwenden.

Wo genau liest Du das (heraus)?

> "Satisfy" scheint mir in diesem Fall überflüssig zu sein:
> | This directive is only useful if access to a particular area is being
> | restricted by both username/password *and* client host address.

Will man später weitere Beschränkungen einführen, kann man die Satisfy-
Direktive nicht vergessen. Vermutlich deshalb sieht auch der Apache-Default
(zumindest bei der Debian-Distribution) so aus.

>> [...] Denn man möchte in der Regel _nicht_ den Zugriff auf *alle* Dateien
>> verbieten, deren Name mit einem Punkt beginnt.
>
> Das ist schlicht Geschmackssache.

Nein, Praxiserfahrung.


PointedEars
--
Du fragst Leute, die normalerweise gern Information weitergeben, wie Du
Information verheimlichen kannst? Ist das nicht ein bisschen ... nunja ...
seltsam? (Ulrich 'Droeppez' Kritzner zu einem Quelltextsperrer in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=2&id=39654&thread=39241)

[Stefan Froehlich]

On Wed, 18 Jan 2012 02:57:21 Thomas 'PointedEars' Lahn wrote:
> geringer als die [Wahrscheinlichkeit], dass z. B. eine Suchmaschine

> mittels Brute-Force-Methode die Passwortdatei im/unterhalb des
> DocumentRoot liest (Google etwa probiert mögliche Domains und Pfade
> durch, um möglichst viel zu indexieren).

Natuerlich koennte das jemand im Fall einer Fehlkonfiguration tun. Aber
Google (und anderen Suchmaschinen) ist in dieser Hinsicht nichts
vorzuwerfen - in keiner einzigen meiner Logdateien finde ich einen
Zugriffsversuch auf .ht*.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Happy mit Stefan, herzig und geklaut!
(Sloganizer)

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Thomas Hochstein wrote:
>

>> Thomas 'PointedEars' Lahn schrieb:

>>> Korrekt und effizienter ist
>>>
>>> <Files ~ "^\.ht">
>>> Order allow,deny
>>> Deny from all
>>> Satisfy all
>>> </Files>
>>
>> Die Dokumentation empfiehlt, wenn ich sie richtig lese, statt "Files
>> ~" besser "FilesMatch" zu verwenden.
>
> Wo genau liest Du das (heraus)?

<http://httpd.apache.org/docs/2.1/mod/core.html#files>:
| <FilesMatch> wird jedoch bevorzugt.

>>> [...] Denn man möchte in der Regel _nicht_ den Zugriff auf *alle*
>>> Dateien verbieten, deren Name mit einem Punkt beginnt.
>>
>> Das ist schlicht Geschmackssache.
>
> Nein, Praxiserfahrung.

Eine Frage des URL-Designs. URLs, die einen Pfadbestandteil haben, der
mit einem oder mehreren Punkten beginnt, sind meist umständlicher, da
länger, und bringen weder für den Menschen noch die Suchmaschine einen
Mehrwert. Daher würde ich davon abraten.

Viele Grüße
Gustaf

[U l f Kadner]

Am 17.01.2012 22:10, schrieb Thomas Hochstein:

> U l f Kadner schrieb:
>> Auch das muss nicht zwingend richtig sein. Wenn die Webpräsenz z.B. je

>> Kunde chrootet ist…

>
> Ah, das hatte ich gar nicht bedacht, Du hast recht.
>
> Dann müßte aber via phpinfo() auch dieser "scheinbar" absolute Pfad
> angezeigt werden, oder?

Korrekt!

Gruß, Ulf

>
> Grüße,
> -thh

[Thomas 'PointedEars' Lahn]

Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:

>> Thomas Hochstein wrote:
>>> Die Dokumentation empfiehlt, wenn ich sie richtig lese, statt "Files
>>> ~" besser "FilesMatch" zu verwenden.
>> Wo genau liest Du das (heraus)?
>
> <http://httpd.apache.org/docs/2.1/mod/core.html#files>:
> | <FilesMatch> wird jedoch bevorzugt.

Diese Aussage ist unzureichend und per se _keine_ Empfehlung. Von *wem*
wird es bevorzugt? *Weshalb*?

>>>> [...] Denn man möchte in der Regel _nicht_ den Zugriff auf *alle*
>>>> Dateien verbieten, deren Name mit einem Punkt beginnt.
>>> Das ist schlicht Geschmackssache.
>> Nein, Praxiserfahrung.
>
> Eine Frage des URL-Designs. URLs, die einen Pfadbestandteil haben, der
> mit einem oder mehreren Punkten beginnt, sind meist umständlicher, da
> länger, und bringen weder für den Menschen noch die Suchmaschine einen
> Mehrwert. Daher würde ich davon abraten.

Siehst Du, genau das meinte ich mit "Praxiserfahrung".

IndexOptions +FancyIndexing +DescriptionWidth=* +NameWidth=* +IconWidth
+IconHeight +IgnoreCase +FoldersFirst


PointedEars
--
> Einfach die xml Tags durch html Code ersetzen und gut...
Lass es mich so sagen: Die dunkle Seite gewählt Du hast. Den schnellen
Erfolg Du suchst, aber auf die Füsse fallen die Komplexität Dir wird.
Unterschätze niemals die Bugs der dunklen Seite! -- Geggo in fcc

[Thomas 'PointedEars' Lahn]

Stefan Froehlich wrote:

> On Wed, 18 Jan 2012 02:57:21 Thomas 'PointedEars' Lahn wrote:
>> geringer als die [Wahrscheinlichkeit], dass z. B. eine Suchmaschine
>> mittels Brute-Force-Methode die Passwortdatei im/unterhalb des
>> DocumentRoot liest (Google etwa probiert mögliche Domains und Pfade
>> durch, um möglichst viel zu indexieren).
>
> Natuerlich koennte das jemand im Fall einer Fehlkonfiguration tun. Aber
> Google (und anderen Suchmaschinen) ist in dieser Hinsicht nichts
> vorzuwerfen - in keiner einzigen meiner Logdateien finde ich einen
> Zugriffsversuch auf .ht*.

robots.txt?

Vielleicht hätte ich einen Cracker als Beispiel nehmen sollen.


PointedEars

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Gustaf Mossakowski wrote:
>
>> Thomas 'PointedEars' Lahn schrieb:
>>> Thomas Hochstein wrote:
>>>> Die Dokumentation empfiehlt, wenn ich sie richtig lese, statt "Files
>>>> ~" besser "FilesMatch" zu verwenden.
>>> Wo genau liest Du das (heraus)?
>>
>> <http://httpd.apache.org/docs/2.1/mod/core.html#files>:
>> | <FilesMatch> wird jedoch bevorzugt.
>
> Diese Aussage ist unzureichend und per se _keine_ Empfehlung. Von *wem*
> wird es bevorzugt? *Weshalb*?

Sonderlich ausführlich ist das Statement nicht, da gebe ich dir Recht.
Eine Empfehlung ist es schon (sonst stände es nicht in der offiziellen
Dokumentation).

Aber es scheint nicht soviel dahinter zu stecken:
<http://mail-archives.apache.org/mod_mbox/httpd-users/200310.mbox/%3CPine
.WNT.4.58.0310121204390.1376@bronfman504%3E>
| Why is is <Files ~> deprecated? Just because <FilesMatch> is clearer
| and there is no reason to mix two different syntaxes.

Es geht also nur um die Klarheit.

>>>>> [...] Denn man möchte in der Regel _nicht_ den Zugriff auf *alle*
>>>>> Dateien verbieten, deren Name mit einem Punkt beginnt.
>>>> Das ist schlicht Geschmackssache.
>>> Nein, Praxiserfahrung.
>>
>> Eine Frage des URL-Designs. URLs, die einen Pfadbestandteil haben, der
>> mit einem oder mehreren Punkten beginnt, sind meist umständlicher, da
>> länger, und bringen weder für den Menschen noch die Suchmaschine einen
>> Mehrwert. Daher würde ich davon abraten.
>
> Siehst Du, genau das meinte ich mit "Praxiserfahrung".

Jetzt kann ich nicht ganz folgen. Wenn man meiner Praxiserfahrung
folgte, könnte man theoretisch den Zugriff auf alle Dateien mit ».« am
Anfang verbieten. Ich mache das allerdings nicht, ich halte mich an die
Standard-Apache-Einstellung, z. B.

| <FilesMatch "^\.([Hh][Tt]|[Dd][Ss]_[Ss])">

> IndexOptions +FancyIndexing +DescriptionWidth=* +NameWidth=* +IconWidth
> +IconHeight +IgnoreCase +FoldersFirst

? Da sind keine Punkte.

Viele Grüße
Gustaf

[Stefan Froehlich]

On Fri, 20 Jan 2012 02:55:20 Thomas 'PointedEars' Lahn wrote:
> > Google (und anderen Suchmaschinen) ist in dieser Hinsicht nichts
> > vorzuwerfen - in keiner einzigen meiner Logdateien finde ich einen
> > Zugriffsversuch auf .ht*.

> robots.txt?

Nein, auch das nicht.

> Vielleicht hätte ich einen Cracker als Beispiel nehmen sollen.

Waere ja naheliegend, alleine: bei mir gibt es _gar_ keine Zugriffe auf
.ht*, von niemandem und auf mehr als einem Dutzend URLs bzw. IP-Adressen.
(Was nichts daran aendert, dass die Dinger tunlichst nicht lesbar sein
sollten, klar).

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Entzücken, mehr als man erwartet. Stefan: superb und lahm.
(Sloganizer)

[Thomas 'PointedEars' Lahn]

Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:

>> Gustaf Mossakowski wrote:
>>> Eine Frage des URL-Designs. URLs, die einen Pfadbestandteil haben, der
>>> mit einem oder mehreren Punkten beginnt, sind meist umständlicher, da
>>> länger, und bringen weder für den Menschen noch die Suchmaschine einen
>>> Mehrwert. Daher würde ich davon abraten.
>>
>> Siehst Du, genau das meinte ich mit "Praxiserfahrung".
>
> Jetzt kann ich nicht ganz folgen. Wenn man meiner Praxiserfahrung
> folgte, könnte man theoretisch den Zugriff auf alle Dateien mit ».« am
> Anfang verbieten. Ich mache das allerdings nicht, ich halte mich an die
> Standard-Apache-Einstellung, z. B.
>
> | <FilesMatch "^\.([Hh][Tt]|[Dd][Ss]_[Ss])">

Die völlig ausreichende Apache-Standardeinstellung sieht anders aus. Ich
hatte sie bereits gepostet.

>> IndexOptions +FancyIndexing +DescriptionWidth=* +NameWidth=* +IconWidth
>> +IconHeight +IgnoreCase +FoldersFirst
>
> ? Da sind keine Punkte.

man IndexOptions. Wenn man den Besucherzugriff auf *sämtliche* Dateien,
deren Name mit `.' beginnt, verbietet, können diese z. B. auch nicht mehr
gelistet werden. Manchmal ist der Zugriff bzw. das Listing aber gewollt.
Unixoid versteckte Dateien (dere Name beginnt mit einem `.') sind eben
_nicht_ *ausschliesslich* Apache-Konfigurationsdateien.


PointedEars
--
Bedenke, daß Mozilla bereits 4 Jahre alt ist. Du kannst Dir also ausrechnen,
wie veraltet NN4 ist. Trotzdem ist er der erfolgreichste Browser aller
Zeiten. Kein Fossil ist je so alt geworden wie dieser Browser einen aussehen
läßt. ;-) -- Georg Maaß in dcljs <aouobi$q4qm6$1...@ID-3551.news.dfncis.de>

[Gustaf Mossakowski]

Thomas 'PointedEars' Lahn schrieb:

> Gustaf Mossakowski wrote:
>> | <FilesMatch "^\.([Hh][Tt]|[Dd][Ss]_[Ss])">
>
> Die völlig ausreichende Apache-Standardeinstellung sieht anders aus. Ich
> hatte sie bereits gepostet.

Das ist auf einem Mac. Dann werden auch keine ».DS_Store«-Dateien
angezeigt. Aber auch die aktuellen Apache-Sourcen schlagen als Standard

| <FilesMatch "^\.ht">

vor, nicht, wie du schriebst, <Files ~ "^\.ht">
Aber so richtig wichtig ist das auch nicht, denke ich.

> man IndexOptions. Wenn man den Besucherzugriff auf *sämtliche* Dateien,
> deren Name mit `.' beginnt, verbietet, können diese z. B. auch nicht mehr
> gelistet werden. Manchmal ist der Zugriff bzw. das Listing aber gewollt.
> Unixoid versteckte Dateien (dere Name beginnt mit einem `.') sind eben
> _nicht_ *ausschliesslich* Apache-Konfigurationsdateien.

Natürlich sind es nicht ausschließlich Apache-Dateien, aber gerade unter
Unix-basierten Systemen sind es häufig Dateien, die versteckt werden
sollen.