* Christian Boltz wrote on Thu, Feb 02, 2006 at 22:12 +0100:
* Jan Friedrich Gehring
Oder (meiner bescheidenen Meinung nach die bessere Moeglichkeit) Der Entwickler soll in der .htaccess Datei seine Einstellungen die er benoetigt Taetigen koennen. Dazu musst du in der Apache Konfiguration fuer sein Verzeichnis AllowOverride auf All setzten.
Wenn der Entwickler, dem sozusagen "sein Webserver" gehört, .htaccess anpasst, kann er zu viel ändern? Klingt irgendwie bissel komisch. Obwohl Entwickler eh meist root-Rechte haben, oder? Dafür hat man doch Entwicklersysteme...
Naja, sobald jemand Root-Rechte hat, darf er eh alles ;-)
Eben, also kann er auch AllowOverride All haben :)
Na ja, falls man keinen Webmaster oder Entwickler hat ;) Sonst hat man vermutlich einen wwwadm oder so, der die Configs schreiben darf, aber ich weiss, Haarspalterei :)
Dieser jemand braucht dann aber auch Rechte für ein rcapache reload (und kann natürlich mit einer kaputten Configdatei den Apache auch abschießen).
Einen Entwickler, der nicht in der Lage ist, einen Apache abzuschiessen, auf dem er entwickelt, kann ich mir kaum vorstellen ;) Ob nu mit oder ohne rcapache :)
So, genug Haare gespalten.
Ein hab ich noch :-) rcapache reload ginge auch via sudo. So, aber jetzt fertig.
AllowOverride AuthConfig Indexes Limit halte ich für OK, FileInfo ist ein Grenzfall und Options will man auf keinen Fall freigeben. [...] (Gründe auf Anfrage - *gähn* ;-)
ANFRAG! :) Paar Stichpunkte (PM?) wären nett - falls die Allgemein gelten (ich kann mir natürlich genügend Spezialfälle denken, wo man Options nicht erlauben möchte, klar).
Ich bin gerade etwas wacher ;-)
Fangen wir mit FileInfo an: Allow use of the directives controlling document types (DefaultType, ErrorDocument, ForceType, LanguagePriority, SetHandler, SetInputFilter, SetOutputFilter, and mod_mime Add* and Remove* directives, etc.).
- SetHandler: kann dazu führen, dass interne Infos über den Apache (z. B. server-status) nach außen kommen. Sowas macht es im Zweifelsfall einem Angreifer leichter, weil er gezielter handeln kann.
Und mit PHP und CGI soll das nicht nachzubauen gehen?
- Set*Filter will ich nicht unbedingt jedem erlauben - laut Apache-Doku kann man (mit mod_ext_filter) auch externe Programme als Filter einbinden - die können dann mit wwwrun(?)-Rechten alles mögliche anstellen.
Da reicht ein AllowOverride, um externe Programme einzubinden? Wie bekommt ein Angreifer sein Programm in das wwwrun-exec-Verzeichnis um das zu überschreiben? CGI kann ja auch externe Programme starten (wenn auch bei suexec nicht unbedingt als wwwrun). Na, und gerade für'n Entwickler, mmm....
Beispielsweise sämtliche Dateien verunstalten, die per PHP-Uploadformular hochgeladen wurden - beim Einsatz eines Content Management Systems sind das einige.
Dann lädt man die halt nochmal hoch. Falls man wirklich so viel auf'm Entwicklersystem hat...
Außerdem können sie gemütlich eine Runde MySQL-Passwörter aus PHP-Scripten einsammeln (Apache hat da ja Leserecht) und mit den Datenbanken spielen ;-)
MySQL-Passwörter kriegt man doch nicht raus? Die sind doch sicherlich nirgendwo im Klartext gespeichert und den Hash darf man nur vergleichen, nicht lesen...
Zugegeben, mit PHP (ohne open_basedir-Beschränkung) und CGIs (ohne suExec) geht das auch, aber PHP kann man ja entsprechend einschränken und CGIs muss man nicht jedem erlauben ;-) - Habe ich etwas vergessen? Egal, die beiden genannten reichen schon ;-)
Na, weiss ja nicht, ob ich dem PHP da trauen würde... Ich mein, so ziemlich die wurstigste der verbreiteten Sprachen, linkt gegen /usr/lib/lib*a, in der Vergangenheits Bugs ohne Ende, oben aufgeklatschtes "Sicherheitssystem", etc. aber anderes Thema. Ja, und eure Entwickler drüfen kein CGI? Ist schon komisch. Na ja. Also klar, wenn man jetzt ein Produktionssystem hätte, dann nimmt man natürlich am besten gar kein PHP und suExec-CGIs, klar.
Kommen wir zu AllowOverride Options: Allow use of the directives controlling specific directory features (Options and XBitHack).
XBitHack on oder full "fördert" die Serverlast, da alle HTML-Dateien geparst werden.
lol, das ist ja ne schöne Beschreibung. Durch das Verwenden von PHP wird die Serverlast aber bestimmt noch mehr erhöht hihi Ich verwende viel SHTML, das ist IMHO auch richtig, kann heut bloss kaum noch einer, aber das Internet muss ja auch so schlecht wie alle Software sein, klar. Da macht man dann Menüs mit Java oder so, aber ist ja auch egal.
ExecCGI Execution of CGI scripts using mod_cgi is permitted.
CGIs will ich zentral halten und nicht quer in allen Verzeichnissen verteilt - deshalb ist diese Option nicht schön.
iihhh, /cgi-bin/? Find ich sowas von hässlich... Da hab ich dann Dienst X mit /xdata und /cgi-bin/xexec/ etc, furchtbar... Nee, ich möchte /vendor/package-version/ haben, und da ist alles drin. Manchmal tauscht man ja auch Bilder gegen JPEGs, und welcher Package gehört /cgi-bin/show.jpg? Na egal.
IncludesNOEXEC Server-side includes are permitted, but the #exec cmd and #exec cgi are disabled. [...]
Vergleichsweise harmlos (und deutlich sicherer als Includes).
ja OK, aber wie soll denn ein Entwickler entwickeln, wenn er keinen Code benutzen darf? Dann kann man ihm ja gleich ein Frontpage oder so'n GUI Mist hinschmeissen. Dann darf man sich natürlich nicht wundern, dass die Webseiten genauso schlecht sind wie die, die man durchschnittlich so im Internet findet... Die sind dann redundant, verwenden vielleicht Javascript und sind Browserabhängig, obwohl man alles Serverseitig hätte machen können. Meiner Meinung nach der falsche Weg (aber ich weiss, dass 99% der Internetnutzer anderer Meinung sind).
FollowSymLinks The server will follow symbolic links in this directory.
Symlink zu /etc/passwd gefällig? ;-) Mehr muss ich dazu wohl nicht sagen, oder?
Doch: wo ist das Problem? Dass der Entwickler die Useracountnamen rauskriegt? Er kann dazu auch "cat" verwenden. Hier ist meine passwd, jedenfalls der Anfang: root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash Oder hast Du das einzige Linux-System, das ich kenn, das kein shadow verwendet?
SymLinksIfOwnerMatch The server will only follow symbolic links for which the target file or directory is owned by the same user id as the link.
Geht aber halt auch nur, wenn der Owner matcht. Wenn man ein RPM installiert, und die Files dadrin root gehören (z.B. damit wwwrun die nicht ändern darf), funktioniert das schon nicht mehr.
Die sicherere Variante von FollowSymLinks - und Mindestvoraussetzung für den Einsatz von mod_rewrite. Dadurch ist diese Option für mich quasi lebensnotwendig ;-)
- oder glaubt hier jemand ernsthaft, dass ich auf www.Landjugend-Insheim.de für jedes Bild in der Galerie eine HTML-Datei geschrieben habe? ;-) [2]#
(URL geht bei mir nicht) mod_rewrite verbraucht bestimmt Serverlast :) In meiner Galarie hab ich für jedes Bild eine HTML-Datei. Natürlich nicht selbst geschrieben, sondern "make" und "wml".
Fazit: Insbesondere AllowOverride Options erlaubt mehr als man möchte.
Mehr als /Du/ in bestimmten Fällen möchtest, ja. Ich hoffe, ich konnte zu jedem Punkt mindestens ein überzeugendes Gegenbeispiel finden :)
PHP sollte man mit open_basedir pro vHost "einsperren" und möglichst auch den safe_mode einschalten - wobei letzterer leider oft zu restriktiv ist (Stichwort Dateiupload und dadurch "falscher" Dateieigentümer).
(oder deinstallieren, ist noch sicherer und spart Serverlast SCNR.)
Ach ja: Wer einen wirklich sicheren Webserver betreiben will, erlaubt nur statische Dateien (also kein PHP, keine CGIs, kein SSI, ...) und beschränkt natürlich AllowOverride passend.
Oder er erlaubt CGIs und SSI und erlaubt AllowOverride halt. Wie soll denn ein Angreifer, der nur HTTP sprechen kann, das CGI missbrauchen, nur allein weil es da ist? Banken verwenden bei Online-Banking-Frontends CGI, weil statisches HTML für Kontostände bissel schwer ist. ( Gut, Banken sind nicht unbedingt Biespiele für "wirklich sichere Webserver", aber im Durchschnitt schon nicht schlecht. SCNR. ) Ich halte das nach wie vor für situationsabhängig, gilt also alles nicht allgemein, sondern nur in verschiedenen, speziellen Fällen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.