php.ini lesbar für alle
0 0 0 
globe
0 
Der Martin
0 0
0 globe
2 globe
2 Der Martin
1
php.ini lesbar für alle
suitIch habe bei meinem Webhosting-Paket eine eigene php.ini-Datei angelegt. Diese liegt in http://www.domain.de/php.ini
Das Problem, ist, dass diese Datei nun natürlich auch über den Webbrowser durch Eingabe der URL lesbar ist. Die Rechte stehen auf 644. Eine Änderung bringt nichts, wird immer wieder automatisch zurückgesetzt.
Gibt es sonst eine Möglichkeit den Zugriff von aussen auf die php.ini einzuschränken? Beim Provider kann ich nichts dazu finden.
Haltet ihr das für ein hohes Risiko oder kann man das einfach so lassen?
-
Hallo,
Ich habe bei meinem Webhosting-Paket eine eigene php.ini-Datei angelegt. Diese liegt in http://www.domain.de/php.ini
Das Problem, ist, dass diese Datei nun natürlich auch über den Webbrowser durch Eingabe der URL lesbar ist. Die Rechte stehen auf 644. Eine Änderung bringt nichts, wird immer wieder automatisch zurückgesetzt.
Gibt es sonst eine Möglichkeit den Zugriff von aussen auf die php.ini einzuschränken? Beim Provider kann ich nichts dazu finden.
Was soll die php.ini bringen? Völlig unabhängig davon kannst du über .htaccess und "Rewrite" dem Apachen vielleicht "sagen", er solle sie nicht ausliefern.
Haltet ihr das für ein hohes Risiko oder kann man das einfach so lassen?
Naja, hängt von Deinen Ansprüchen ab.
Gruß
jobo
-
Hallo jobo,
Was soll die php.ini bringen? Völlig unabhängig davon kannst du über .htaccess und "Rewrite" dem Apachen vielleicht "sagen", er solle sie nicht ausliefern.
das ist nicht der vorgesehene Weg, Zugriffskontrolle zu erstellen, auch wenn es funktioniert.
Gruß aus Berlin!
eddi--
Wer mit Kanonen auf Spatzen schießt, mag zwar immernoch Augen für die Tauben auf dem Dach haben, aber keine Hand mehr zum reichen.-
n'abend,
das ist nicht der vorgesehene Weg, Zugriffskontrolle zu erstellen, auch wenn es funktioniert.
Würde man es richtig™ machen, würde der Kram außerhalb des DocumentRoot liegen. Wie viele 0815-Hoster kannst du nennen, bei denen du dies auch tatsächlich umsetzen kannst?
weiterhin schönen abend...
--
#selfhtml hat ein Forum?
sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:|-
Hallo,
Würde man es richtig™ machen, würde der Kram außerhalb des DocumentRoot liegen.
<eriwan>Im Prinzip ja.</eriwan>
Allerdings gilt eine php.ini nur für das Verzeichnis, in dem sie liegt. Diese Datei außerhlab des Document Root unterzubringen, wäre also sinnlos.Wie viele 0815-Hoster kannst du nennen, bei denen du dies auch tatsächlich umsetzen kannst?
Zugegeben: Es gibt viele, die dem Kunden kein Verzeichnis außerhalb des Document Root zugänglich machen.
Ciao,
Martin--
Alleine sind wir stark ...
gemeinsam sind wir unausstehlich!-
Hallo Martin,
Diese Datei außerhlab des Document Root unterzubringen, wäre also sinnlos.
Jain: vgl. configure-Option --with-config-file-scan-dir; weiterhin gibt es auch noch ganz andere Möglichkeiten: Konfiguration/PHP als CGI
Gruß aus Berlin!
eddi--
Wer mit Kanonen auf Spatzen schießt, mag zwar immernoch Augen für die Tauben auf dem Dach haben, aber keine Hand mehr zum reichen.
-
-
Hallo Globe,
| das ist nicht der vorgesehene Weg, Zugriffskontrolle zu erstellen, auch wenn es funktioniert.
Würde man es richtig™ machen, würde der Kram außerhalb des DocumentRoot liegen. Wie viele 0815-Hoster kannst du nennen, bei denen du dies auch tatsächlich umsetzen kannst?
Deinem ersten Satz stimme ich ja voll zu, nur verstehe ich nicht, was Du aber mit dem zweiten Satz tatsächlich in Erfahrung bringen willst. Die meisten Webhosts gestatten die Nutztung der Rewrite-Engine. Diese ist ursprünglich nicht für Zugriffskontrolle konzipiert.
Gruß aus Berlin!
eddi--
Wer mit Kanonen auf Spatzen schießt, mag zwar immernoch Augen für die Tauben auf dem Dach haben, aber keine Hand mehr zum reichen. -
[latex]Mae govannen![/latex]
Würde man es richtig™ machen, würde der Kram außerhalb des DocumentRoot liegen. Wie viele 0815-Hoster kannst du nennen, bei denen du dies auch tatsächlich umsetzen kannst?
Ja. Macht meiner auch nicht. Was aber oft funktioniert:
Wenn mir der Hoster /web0815/ zur Verfügung stellt, erstelle ich eben z.B. /web0815/htdocs/, mache das zum doc_root und kann
dann in /web0815/ Date(ie)n ablegen. Immerhin.Cü,
Kai
--
„It's 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it's dark, and we're wearing sunglasses“.
„Hit it!“
Selfzeugs
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
-
-
n'abend,
Was soll die php.ini bringen?
Es gibt diverse Möglichkeiten PHP anzusprechen, mod_php ist nicht die einzige. Z.B. bei der Integration via CGI schaut der PHP Interpreter nach, ob irgendwo im (Eltern)Pfad eine php.ini liegt, die er als lokale Konfiguration heranziehen kann.
Völlig unabhängig davon kannst du über .htaccess und "Rewrite" dem Apachen vielleicht "sagen", er solle sie nicht ausliefern.
<Files> ist Teil des Apache Cores (also überall verfügbar, sofern nicht "explizit" für's Überschreiben in .htaccess verboten, siehe "AllowOverride"). Order ist Teil der mod_access, ein Standardmodul mit einer vermutlich größeren Verbreitung als mod_rewrite.
»» Haltet ihr das für ein hohes Risiko oder kann man das einfach so lassen?
Naja, hängt von Deinen Ansprüchen ab.Es ist prinzipiell niemals Ratsam seine Konfiguration zu veröffentlichen. Speziell dann nicht, wenn sie evtl. Informationen enthalten könnte, die es einem potentiellen Angreifer die "Arbeit" vereinfachen würde.
weiterhin schönen abend...
--
#selfhtml hat ein Forum?
sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:|-
Hallo,
n'abend,
»» Was soll die php.ini bringen?
Es gibt diverse Möglichkeiten PHP anzusprechen, mod_php ist nicht die einzige. Z.B. bei der Integration via CGI schaut der PHP Interpreter nach, ob irgendwo im (Eltern)Pfad eine php.ini liegt, die er als lokale Konfiguration heranziehen kann.
"Aber" .../cgi-bin liegt parallel zu .../htdocs, zumindest nicht unselten? Also kein "Elternpfad"?
<Files> ist Teil des Apache Cores (also überall verfügbar, sofern nicht "explizit" für's Überschreiben in .htaccess verboten, siehe "AllowOverride"). Order ist Teil der mod_access, ein Standardmodul mit einer vermutlich größeren Verbreitung als mod_rewrite.
Schön, wenn sich einer damit auskennt (;-). Wieso kompliziert, wenns auch einfacher geht.
Es ist prinzipiell niemals Ratsam seine Konfiguration zu veröffentlichen. Speziell dann nicht, wenn sie evtl. Informationen enthalten könnte, die es einem potentiellen Angreifer die "Arbeit" vereinfachen würde.
Daher meine Verwunderung, dass das überhaupt geht.
Gruß
jobo
-
你好 jobo,
"Aber" .../cgi-bin liegt parallel zu .../htdocs, zumindest nicht unselten? Also kein "Elternpfad"?
CGI-Scripte kann man auch außerhalb von cgi-bin ausführen. Siehe Options ExecCGI.
再见,
克里斯蒂安--
http://wwwtech.de/
On the day *I* go to work for Microsoft, faint oinking sounds will be heard from far overhead, the moon will not merely turn blue but develop polkadots, and hell will freeze over so solid the brimstone will go superconductive. (Eric Raymond als Antwort auf ein Job-Angebot von MS)
CFPropertyList: PHP-Klassen zur Manipulation von Apples property lists – AdHoc-Distribution via IPA-Format
-
-
-
-
n'abend,
Gibt es sonst eine Möglichkeit den Zugriff von aussen auf die php.ini einzuschränken? Beim Provider kann ich nichts dazu finden.
Ich gehe davon aus, dass ein Apache Webserver im Einsatz ist und du mittels einer .htaccess Datei bestimmte Regeln setzen darfst. Ist dem so, solltest du mittels der folgenden Files Regel den Zugriff auf deine php.ini (resp. in diesem Beispiel alle ini-Dateien) verbieten können:
<Files "\.ini$"> Order Deny,Allow Deny from all </Files>weiterhin schönen abend...
--
#selfhtml hat ein Forum?
sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:| -
Hallo,
Ich habe bei meinem Webhosting-Paket eine eigene php.ini-Datei angelegt. Diese liegt in http://www.domain.de/php.ini
bist du Inhaber der Domain "domain.de", die du hier so selbstverständlich verwendest? Verwende bitte für Beispiele nur Domains, die ausdrücklich dafür vorgesehen sind, anstatt real existierende, die jemand anderem gehören.
Das Problem, ist, dass diese Datei nun natürlich auch über den Webbrowser durch Eingabe der URL lesbar ist.
Ist das ein Problem?
Gibt es sonst eine Möglichkeit den Zugriff von aussen auf die php.ini einzuschränken? Beim Provider kann ich nichts dazu finden.
Eine .htaccess mit einem einfachen "Deny from all" in einem <Files>-Container könnte dich glücklich machen. Vorausgesetzt, dein Webserver ist ein Apache.
So long,
Martin--
Keine Sorge, wir finden für jede Lösung ein Problem. -
Hallo erstmal!
wenn Dein Webhost den Apachen einsetzt, kannst Du den Zugriff mittels
<Files "php.ini"> [link:http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order@title=Order] [link:http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#deny@title=Deny], [link:http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#allow@title=Allow] Deny from all </Files>in der .htaccess verweigern lassen. Sollte der Webhost keinen Apachen verwenden, oder es zu Problemen kommen, einfach nochmals hier in diesem Thread melden! ;)
Gruß aus Berlin!
eddi--
Wer mit Kanonen auf Spatzen schießt, mag zwar immernoch Augen für die Tauben auf dem Dach haben, aber keine Hand mehr zum reichen.-
# Zugriff auf php.ini verbieten <Files "php.ini"> Order Deny, Allow Deny from all </Files>So habe ich es jetzt in die .htaccess eingetragen.
Dafür kommt jetzt aber ein 500er-Fehler
Internal Server Error
Die Error-Logdatei sagt:
[Wed Jun 17 10:25:08 2009] [alert] [client XXX.XXX.XXX.XXX] /home/benutzer/public_html/.htaccess: order takes one argument, 'allow,deny', 'deny,allow', or 'mutual-failure'
-
n'abend,
Zugriff auf php.ini verbieten
<Files "php.ini">
Order Deny, AllowDas Leerzeichen zwischen "Deny," und "Allow" muss weg. "Deny,Allow" ist der erwartete Wert.
Deny from all
</Files>weiterhin schönen abend... -- #selfhtml hat ein Forum? sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:|-
n'abend,
weiterhin schönen abend...Es ist Mittag :D
-
-
-