nicht angemeldet
PHP & Sicherheit
Hallo!
Ich habe folgendes Problem...
Meine MySQL-Zugangsdaten (und weitere sensible Werte) liegen in einem Verzeichnis ausserhalb des Document-Roots (sind also nicht über das WWW erreichbar).
Allerdings haben meine User die Möglichkeit eigene Homepages hochzuladen. Ich denke hierbei an den Bericht der c't, daß man per PHP die Verzeichnisstruktur und deren Inhalt auslesen kann.
In diesem Falle könnte ein böswilliger User einfach das oben genannte Script includen und so auf meine DB zugreifen oder anderen Unfug anstellen.
Die einfachste Möglichkeit wäre das Hochladen von PHP-Scripts (bzw. das nachträgliche Umbenennen nach .php) einfach zu unterbinden, aber dazu habe ich mich noch nicht durchgerungen.
Gibt es eine andere Möglichkeit sensible Scripts zu schützen (z.B. per chmod, oder per .htaccess?)
Danke und Grüsse
Sven Mayer
-
Hallo sven,
wenn ich mich recht erinnere, dann waren in der c't auch Tipps hinsichtlich der Rechtevergabe mit drin.
Aber davon mal abgesehen: Ist denn der Dateiname überhaupt rauszufinden um ihn einbinden zu können? Evtl. wäre es auch denkbar, dass Du in die include-Datei eine Abfrage einbaust, und sie ihre Daten nur bei Aufruf aus bestimmten Verzeichnissen oder bestimmter Dateien preisgibt.Grüße aus Würzburg
Julian -
Meine MySQL-Zugangsdaten (und weitere sensible Werte) liegen in einem Verzeichnis ausserhalb des Document-Roots (sind also nicht über das WWW erreichbar).
Allerdings haben meine User die Möglichkeit eigene Homepages hochzuladen. Ich denke hierbei an den Bericht der c't, daß man per PHP die Verzeichnisstruktur und deren Inhalt auslesen kann.
In diesem Falle könnte ein böswilliger User einfach das oben genannte Script includen und so auf meine DB zugreifen oder anderen Unfug anstellen.
Das ist ein generelles Problem von PHP in der Modulversion: PHP läuft als Teil des Webbrowsers, nicht unter dem Namen des eigentlichen Benutzers. Somit sind auf Betriebssystemebene auch alle Dateien für alle Benutzer zugängig.
Die Konfiguration bietet eine Reihe Krücken, um dieses Problem zu umgehen, schau doch mal in die Anleitung: http://www.php.net/manual/de/configuration.php (safe_mode, doc_root, open_basedir). Es gibt dort, man höre und staune, sogar ein richtiges Kapitel zum Thema Sicherheit: http://www.php.net/manual/de/security.php.
Das Problem der Leute, auf die in der c't eingegangen wurde, war wohl hauptsächlich, daß sie die PHP-Anleitung nicht gelesen haben..Gruß,
soenk.e-
Hi,
Die Konfiguration bietet eine Reihe Krücken, um dieses Problem zu umgehen, schau doch mal in die Anleitung: http://www.php.net/manual/de/configuration.php (safe_mode, doc_root, open_basedir). Es gibt dort, man höre und staune, sogar ein richtiges Kapitel zum Thema Sicherheit: http://www.php.net/manual/de/security.php.
safe_mode, doc_root und co helfen nichts gegen das Lesen auf Filesystem-Ebene.
Das einzige hilfreiche ist, das PHP als CGI laufen zu lassen, denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Das Problem der Leute, auf die in der c't eingegangen wurde, war wohl hauptsächlich, daß sie die PHP-Anleitung nicht gelesen haben..
Du aber auch nicht.
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.Das Problem der PHP-Coder ist, dass sie noch immer
von Einzeluser-Systemen ausgehen. Deswegen kennen die einfach nicht das Problem bzw. es gibt keinen Druck da was zu machen.Ciao,
Wolfgang-
Hi!
[...]denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
was ist suxec? Wie muß ich das verstehen?
Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Bei mir läuft es als CGI und das erh gut, die einzigen beiden Einschränkungen bis heute waren das die PHP-Authentifiziereung nicht geht, und auch über htaccess keinen Einfluß auf PHP genommen werden kann. Sonst hatte ich dadurch bis heute keien Nachteile, oder was wäre Dir da was eklatantes bekannt?
Du aber auch nicht.
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.Aber man kann unter Linux doch überall strikte Rechte vergeben, wozu braucht PHP root-Rechte?
Das Problem der PHP-Coder ist, dass sie noch immer
von Einzeluser-Systemen ausgehen. Deswegen kennen die einfach nicht das Problem bzw. es gibt keinen Druck da was zu machen.Hä? PHP wird doch so gut wie nur auf größeren Webservern bei Massenhostern verwendet, und da wird wohl kaum jeder Kunde einen Einzeluser-System haben, oder? Schön wärs...
-
Hi,
[...]denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
was ist suxec? Wie muß ich das verstehen?suexec ist das Apachemodul, das fuer virtuelle Hosts eine Changeroot-Umgebung macht, so dass Skripten ueber die Keunnung asugefuehrt werden,
die mittels
User USERNAME
Group GROUPNAME
in <VirtualHost> definiert sindAber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Bei mir läuft es als CGI und das erh gut, die einzigen beiden Einschränkungen bis heute waren das die PHP-Authentifiziereung nicht geht, und auch über htaccess keinen Einfluß auf PHP genommen werden kann. Sonst hatte ich dadurch bis heute keien Nachteile, oder was wäre Dir da was eklatantes bekannt?Da ich PHP nur fuer Spielereien benutze nicht :)
Allerdings geht der angebliche Geschwindigkeitsvorteil von PHP
floeten, weil bei jedem neuen Aufruf das Skript neu geladen und interpretiert wird.
Also so, als ob man CGI ohne FastCGI benutzt.Du aber auch nicht.
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.
Aber man kann unter Linux doch überall strikte Rechte vergeben, wozu braucht PHP root-Rechte?Von Root-Rechten hat niemand geredet.
Ganz im Gegenteil ist das Problem da, weil kein vernuenftiger Admin
den Apache als Root laufen laesst.Die Hauptinstanz des Webservers und dessen Childs laufen unter der
kennung, die man mit USER und GROUP in der httpd.conf definiert.Der User jedoch, der Webfiles anlegt, hat eine andere Userkennung und eine andere Group.
Da diese meistens nicht kommulieren (d.h. Apacheuser != User der Files
bearbeitet und Webservergroup != usergroup), bleibt dem Webseitenbastler nichts uebrig, als die Webfiles global lesbar zu machen.So weit so gut.
Und nun ist ein dritter oder x weitere User auf dem Filesystem.
Was kann dieser tun? Richtig - per "cat <filename>" oder "less <filename>" einfach die global lesbare Datei anschauen.
Was nicht weiter schlimm ist, wenn es alles eh nur Gimmicks und oeffentliche Daten sind.
Problematisch nur, wenn in der php-File oder dessen Include irgendwo Datenbankzugaenge stehen.Das Problem der PHP-Coder ist, dass sie noch immer
von Einzeluser-Systemen ausgehen. Deswegen kennen die einfach nicht das Problem bzw. es gibt keinen Druck da was zu machen.
Hä? PHP wird doch so gut wie nur auf größeren Webservern bei Massenhostern verwendet, und da wird wohl kaum jeder Kunde einen Einzeluser-System haben, oder? Schön wärs...Eben deswegen hatte der c't-Artikel so eine relevanz.
Dedizierte Server sind nur wenig im Einsatz. Und taugliche Loesungen sind mir nur fuer BSD bekannt.
Das das ganze erst jetzt so langsam auftaucht, leigt auch daran, dass immer mehr Leute einen Shell-Zugang wollen und sich nicht mehr mit einem FTP-Zugang abspeisen lassen wollen (wobei FTP sowieso unsicher ist).Natuerlich haben die c't-Leute verschwiegen, wie eine -machbare- Loesung fuer eine Low-Budget-Umgebung auszusehen haette....
Eine Loesung liegt darin, mit den Unixgruppen rumzuspielen.
Wobei man leider den leichtesten Weg, naemlich den Apacheuser zusammen mit allen einzelnen usern jeweil sin einer Gruppe zu tun, nicht funktioniert, wenn man mehr als 25 User hat. (Ein User kann nicht in mehr als 25 Gruppen sein).Die Loesung die ich in Anwendung hab, beruht auf einen Mix aus Solaris-ACLs, gemounteten Bereichen, auf die nur spezielle User Zugriff haben, einer allgemeinen Webmaster-Gruppe und (und das geht aber nur bei Unis oder Vereinen:) restriktive Benutzungsregeln in Bezug auf einen eigens zu beantragenden 'Webmaster-Zugang'.
Ciao,
Wolfgang
-
-
Die Konfiguration bietet eine Reihe Krücken, um dieses Problem zu umgehen, schau doch mal in die Anleitung: http://www.php.net/manual/de/configuration.php (safe_mode, doc_root, open_basedir). Es gibt dort, man höre und staune, sogar ein richtiges Kapitel zum Thema Sicherheit: http://www.php.net/manual/de/security.php.
safe_mode, doc_root und co helfen nichts gegen das Lesen auf Filesystem-Ebene.
Habe ich das behauptet? Und wo steht, daß das überhaupt eine Frage für Sven ist? Er hatte lediglich gefragt, was man dagegen tun kann, daß einzelne Leute per PHP (!) fremde Dateien auslesen. Und genau dagegen ist mit safe_mode & Co. ein Kraut gewachsen.
Bei Dateisystemzugriffen, die mit PHP-Funktionen durchgeführt werden, greifen diese Einstellungen sehr gut.Es ging hier (zumindest momentan) nicht darum, daß er Benutzer hat, die per telnet-Zugang direkt auf den Rechner können oder per CGI eigene Programme starten. Somit ist die Aussage, daß safe_mode nicht gegen direkte Dateisystem-Zugriffe hilft zwar richtig, aber an dieser Stelle vollkommen irrelevant.
Das einzige hilfreiche ist, das PHP als CGI laufen zu lassen, denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Klasse, dann muß man für jeden Seitenaufruf den PHP-Interpreter starten..
Und wenn ich das recht überblicke, sollte man CGI-Sachen doch nur in ein bestimmtes Verzeichnis packen, oder irre ich mich da? In der Modulversion kann man die Seiten wenigstens dahin legen, wo man sie gerne haben möchte.
Das Problem der Leute, auf die in der c't eingegangen wurde, war wohl hauptsächlich, daß sie die PHP-Anleitung nicht gelesen haben..
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.
Siehe oben, diese Aussage ist hier momentan vollkommen unnötig.
Gruß,
soenk.e-
Hi,
Habe ich das behauptet? Und wo steht, daß das überhaupt eine Frage für Sven ist? Er hatte lediglich gefragt, was man dagegen tun kann, daß einzelne Leute per PHP (!) fremde Dateien auslesen. Und genau dagegen ist mit safe_mode & Co. ein Kraut gewachsen.
Stimmt. Wobei man aber deswegen dies andere erwaehnen muss, um die Leute nicht in falscher Sicherheit zu wiegen.
Er schrieb naemlich selbst in der letzten Zeile implizit, dass er CHMOD ausfuehren kann.
Folglich gibt es wohl ein Shell-Zugang.
Und wenn es ein Shell-Zugang gibt, gibt es mehrere und die beschriebene Problematik ist vorhanden.Warum hab ich das Gefuehl, dass jegliche Sicherheitsprobleme oder
negative Facetten von PHP unterm Tisch gekehrt werden?Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Klasse, dann muß man für jeden Seitenaufruf den PHP-Interpreter starten..
Eben.
Und wenn ich das recht überblicke, sollte man CGI-Sachen doch nur in ein bestimmtes Verzeichnis packen, oder irre ich mich da? In der Modulversion kann man die Seiten wenigstens dahin legen, wo man sie gerne haben möchte.
Da irrst du dich halb.
Man kann den Webserver so einstellen, dass alle Files mit den Dateinamen *.php auf den Interpreter redirected werden. (Steht doch auch so in der Doku!)
Das Problem der Leute, auf die in der c't eingegangen wurde, war wohl hauptsächlich, daß sie die PHP-Anleitung nicht gelesen haben..
In der Doku von PHP steht genau zu dem Punkt, dass nur PHP ueber CGI in den Faellen bzgl Filesystem-Lesen hilft.
Siehe oben, diese Aussage ist hier momentan vollkommen unnötig.
Aussagen zur Sicherheit eines verwendeten Systems oder eine Applikation sind NIEMALS unnoetig.
(Es sei denn, mann arbeitet fuer Microsoft :) )Ciao,
Wolfgang-
Moin!
Stimmt. Wobei man aber deswegen dies andere erwaehnen muss, um die Leute nicht in falscher Sicherheit zu wiegen.
Er schrieb naemlich selbst in der letzten Zeile implizit, dass er CHMOD ausfuehren kann.
Folglich gibt es wohl ein Shell-Zugang.Vielleicht meinte er FTP?
Und wenn es ein Shell-Zugang gibt, gibt es mehrere und die beschriebene Problematik ist vorhanden.
Ja, aber was hat das denn jetzt mit PHP zu tun??? Vermutlich hat man z.B. für SSH einen eigenen User, der nur auf die Verzeichnisse des eigenen virtuellen Host zugreifen darf. Zwar kann man hier auch PHP-Scripte ausführen(auch bei der CGI-Version), aber doch dann mit dem aktuellen User des Shell-Zugangs, oder? Warum soll das kritischer sein als ein Script im www zu starten?
Warum hab ich das Gefuehl, dass jegliche Sicherheitsprobleme oder
negative Facetten von PHP unterm Tisch gekehrt werden?tun Sie gar nicht, siehe CT-Artikel und der vielen Fragen alleine heute hier im Forum. Ich vermute das die meisten PHP - Nutzer/Programmierer davon genau so wenig verstehen wie ich, und mich zumindest interessiert das Thema sehr!
Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Klasse, dann muß man für jeden Seitenaufruf den PHP-Interpreter starten..
Eben.
Ist das jetzt ein sicherheitsbedachtes positives "eben", oder eher ein seufzendes performancefessendes "eben"?
Aussagen zur Sicherheit eines verwendeten Systems oder eine Applikation sind NIEMALS unnoetig.
sehe ich auch so.
(Es sei denn, mann arbeitet fuer Microsoft :) )
Sind die Sprüche nicht lamgsam ausgelutscht?
Viele Grüße
Andreas-
Hi,
Folglich gibt es wohl ein Shell-Zugang.
Vielleicht meinte er FTP?Kann auch sein.
ER braucht meine Message ja nicht zu lesen, wenn ich ihn
falsch interpretierte.Und wenn es ein Shell-Zugang gibt, gibt es mehrere und die beschriebene Problematik ist vorhanden.
Ja, aber was hat das denn jetzt mit PHP zu tun??? Vermutlich hat man z.B. für SSH einen eigenen User, der nur auf die Verzeichnisse des eigenen virtuellen Host zugreifen darf. Zwar kann man hier auch PHP-Scripte ausführen(auch bei der CGI-Version), aber doch dann mit dem aktuellen User des Shell-Zugangs, oder? Warum soll das kritischer sein als ein Script im www zu starten?Einen eigenen User fuer SSH macht keinen Sinn. Man moechte ja dieselben Dateien bearbeiten, die man auch im Web hat.
Also um ein Beispiel zu geben:Bei Login per Web kommst du nur an die Dateien im Document-Root ran.
Also z.B. an alles was UNTER /home/user1/public_html/ liegt.
An /home kommst du nicht.
Bei Login per SSH dagegen kommst du auch an /home und damit
auch in /home/user2/public_html/ .Warum hab ich das Gefuehl, dass jegliche Sicherheitsprobleme oder
negative Facetten von PHP unterm Tisch gekehrt werden?
tun Sie gar nicht, siehe CT-Artikel und der vielen Fragen alleine heute hier im Forum. Ich vermute das die meisten PHP - Nutzer/Programmierer davon genau so wenig verstehen wie ich, und mich zumindest interessiert das Thema sehr!Das laesst mich hoffen :)
Bisher kam es fast sofort zu einem Schlagabtausch zwischen
CGI-Programmierer und PHP-Coder, wenn man irgendwas sagte.Eben.
Ist das jetzt ein sicherheitsbedachtes positives "eben", oder eher ein seufzendes performancefessendes "eben"?Eher letzteres, aber 10% waere ersteres wohl auch ein bischen sinnvoll.
(Es sei denn, mann arbeitet fuer Microsoft :) )
Sind die Sprüche nicht lamgsam ausgelutscht?Nein, weil MS seine Politik bisher nicht wesentlich geaendert hat.
Also haben die doofen Sprueche noch immer Gueltigkeit.
Nichts mehr zu sagen, waere nichts anderes als hinnehmen lassen und somit recht geben.Ciao,
Wolfgang-
Hallo!
Einen eigenen User fuer SSH macht keinen Sinn. Man moechte ja dieselben Dateien bearbeiten, die man auch im Web hat.
Also um ein Beispiel zu geben:Bei Login per Web kommst du nur an die Dateien im Document-Root ran.
Also z.B. an alles was UNTER /home/user1/public_html/ liegt.
An /home kommst du nicht.
Bei Login per SSH dagegen kommst du auch an /home und damit
auch in /home/user2/public_html/ .Nun, ich habe bei meinem Webspace einen Benutzernamen(zum einloggen., oder ist das was anders?) für SSH, der mit "SSH-" anfängt, daher habe ich einfach mal gedacht das wäre ein eigener Benutzer. Dann habe ich immer mein Hauptverzeichnis: /www/noch_ein_Verzeichnis/ in dem der Document Root des Apache liegt. Wenn ich mich mit SSH einlogge ist auch genau dieses Verzeichnis dort mein Root-verzeichnis, tiefer komme ich nicht, also nicht nach /www/ und schon gar nicht nach /
Warum hab ich das Gefuehl, dass jegliche Sicherheitsprobleme oder
negative Facetten von PHP unterm Tisch gekehrt werden?
tun Sie gar nicht, siehe CT-Artikel und der vielen Fragen alleine heute hier im Forum. Ich vermute das die meisten PHP - Nutzer/Programmierer davon genau so wenig verstehen wie ich, und mich zumindest interessiert das Thema sehr!Das laesst mich hoffen :)
Bisher kam es fast sofort zu einem Schlagabtausch zwischen
CGI-Programmierer und PHP-Coder, wenn man irgendwas sagte.Und was mit denen die mit der CGI Version von PHP arbeiten(ich z.B.) da schlagen dann 2 Herzen in meiner Brust oder was?
Grüße
Andreas
-
-
-
Habe ich das behauptet? Und wo steht, daß das überhaupt eine Frage für Sven ist? Er hatte lediglich gefragt, was man dagegen tun kann, daß einzelne Leute per PHP (!) fremde Dateien auslesen. Und genau dagegen ist mit safe_mode & Co. ein Kraut gewachsen.
Stimmt. Wobei man aber deswegen dies andere erwaehnen muss, um die Leute nicht in falscher Sicherheit zu wiegen.
Er schrieb naemlich selbst in der letzten Zeile implizit, dass er CHMOD ausfuehren kann.
Folglich gibt es wohl ein Shell-Zugang.Sicher. Nur wenn jemand von "meinen Usern" schreibt, gehe ich mal davon aus, daß er der Systemadministrator ist und somit selbstverständlich einen Shell-Zugang hat. Das heißt aber noch lange nicht, daß alle seine User auch einen Shell-Zugang haben. Er sprach ja nur davon, daß man PHP-Seiten raufladen kann.
Warum hab ich das Gefuehl, dass jegliche Sicherheitsprobleme oder
negative Facetten von PHP unterm Tisch gekehrt werden?Ich will nichts unter den Tisch kehren, aber man sollte die zwei Sachen klar auseinanderhalten. Ich bin von Problemen der Modulversion ausgegangen, da das, was er anspricht, eigentlich vom Prinzip her in der CGI-Version nicht auftreten kann.
Wenn's also um die Modulversion geht, solltest man nicht einwerfen, daß Sicherheitseinstellungen der Modulversion nicht bei Dingen greifen, die in der Modulversion in dieser Form überhaupt keine Rolle spielen (direkte Dateisystem-Zugriffe).Siehe oben, diese Aussage ist hier momentan vollkommen unnötig.
Aussagen zur Sicherheit eines verwendeten Systems oder eine Applikation sind NIEMALS unnoetig.
Ok, da hast Du recht. Aber doch bitte klar zuordnen.
Gruß,
soenk.e
-
-
Hallo!
Es ging hier (zumindest momentan) nicht darum, daß er Benutzer hat, die per telnet-Zugang direkt auf den Rechner können oder per CGI eigene Programme starten.
Das habe ich auch schonmal gehört, das man mit Telnet htaccess umgehen können soll, aber wie soll das bitte gehen? Ich habe auf meinem Server keinen Telnet-Zugang, an Port23 ist nix los. Wie soll man dann mit Telnet drauf zugreifen? Wenn man das könnte, ist eh alles verloren! Außerdem braucht man doch auch für Telnet Zugangsdaten, OK, wahrscheinlcih könnte man die da das unverschlüselt abläuft mitlesen, aber ist das das große Problem das htaccess nicht 100%ig sicher ist? Mit FTP besteht dann dasselbe Problem. Ich weiß, das gehört nicht direkt in diesen Thread, aber interessiert mich trotzdem, warum sind htaccess geschützte Dateien unsicherer als Dateien außerhalb des Document-root? Wenn der Server wie bei mir nur http, https, ssh, smtp und pop3 erlaubt, wo soll da eine Lücke sein die .htaccess unsicherer macht?
Das einzige hilfreiche ist, das PHP als CGI laufen zu lassen, denn dann kann man mit suxec die PHP-Files allein fuer den Owner lesbar machen, anstelle fuer global.
Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Klasse, dann muß man für jeden Seitenaufruf den PHP-Interpreter starten..
Also von folgendem Provider weiß ich das PHP als CGI Läuft, und da dauern Requests an dynamische Seiten zu über 99% unter 0,8 Sekunden und durschnittlich 0,17 Sekunden. Statische Seiten sind zwar geringfügig schneller, dürfte man aber kaum merken. Die Probleme liegen meist woanders. Guck Dir dagegen mal die Werte von anderen providern an, die von CT im Test genannt wurden und daher PHP als Modul laufen lassen!
http://monitor.ig4internetuser.de/view.php3?aktion=month&month=07&year=2002&provider=domainfactoryUnd wenn ich das recht überblicke, sollte man CGI-Sachen doch nur in ein bestimmtes Verzeichnis packen, oder irre ich mich da? In der Modulversion kann man die Seiten wenigstens dahin legen, wo man sie gerne haben möchte.
Nein. Das Merkst Du gar nicht. Sowohl PERL als auch PHP - Scripte können überall ausgeführt werden, wie gesagt, die einzigen mir bis jetzt untergekommenen Nachteile sind PHP auth. und htaccess Zugriff auf die php.ini.
Viele Grüße
Andreas-
Es ging hier (zumindest momentan) nicht darum, daß er Benutzer hat, die per telnet-Zugang direkt auf den Rechner können oder per CGI eigene Programme starten.
Das habe ich auch schonmal gehört, das man mit Telnet htaccess umgehen können soll, aber wie soll das bitte gehen? Ich habe auf meinem Server keinen Telnet-Zugang, an Port23 ist nix los. Wie soll man dann mit Telnet drauf zugreifen?Der Zugang per telnet bzw. ssh muß auf dem Server natürlich freigeschaltet sein. Aber wenn er für Dich freigeschaltet ist, kannst Du auf dem Server genauso arbeiten, wie Du es vielleicht schon aus der MS-DOS-Kommandozeile kennst (bzw. besser, weil Unix-Shells wesentlich komfortabler sind). Im Kern bedeutet das: Du kannst Programme auf dem Server starten.
Das man damit die .htaccess umgehen kann sollte klar sein, denn die .htaccess wir nur vom Webserver (dem Programm) ausgewertet. Wenn Du mit anderen Programmen im Dateisystem arbeitest, ist die .htaccess deshalb vollkommen nutzlos - sie ist einfach nur eine weitere Textdatei.
Hier greift dann der Schutzmechanismus des Dateisystems.Ich weiß, das gehört nicht direkt in diesen Thread, aber interessiert mich trotzdem, warum sind htaccess geschützte Dateien unsicherer als Dateien außerhalb des Document-root?
Per .htaccess geschütze Dateien sind insofern unsicherer als Dateien außerhalb des DocumentRoots des Webservers, weil der Webserver letztere überhaupt nicht ausliefert wird. Per .htaccess geschützte Dateien hingegen werden natürlich grundsätzlich schon ausgeliefert (dafür sind sie ja da).
Ich finde diese Aussage, die Du da zitiert hast, aber irgendwie ein wenig unsinnig, denn, wie gesagt, das Dateien, die überhaupt nicht vom Webserver zur Auslieferung vorgesehen sind ein paar Ticks "sicherer" sind als solche, die zur Auslieferung vorgesehen sind, sollte logisch sein.
Ein Fahrrad, das Du in die Garage sperrst, steht schließlich auch sicherer als eines, daß Du mit einem Panzerschloss an eine Laterne kettest..Aber PHP als CGI laufen zu lassen, waere ja ein Sakrelik :)
Klasse, dann muß man für jeden Seitenaufruf den PHP-Interpreter starten..
Also von folgendem Provider weiß ich das PHP als CGI Läuft, und da dauern Requests an dynamische Seiten zu über 99% unter 0,8 Sekunden und durschnittlich 0,17 Sekunden.Ok, ich mag da etwas sehr altmodisch sein, mir ist es halt grundsätzlich etwas unangenehm, wenn man noch extra ein nicht gerade kleines Programm wie hier zum Beispiel den PHP-Interpreter starten muß. Je nach Serverhardware und -auslastung fällt das natürlich mehr oder weniger deutlich auf. Und diese Leistungseinbußen muß man selbstredend mit Sicherheitsaspekten aufwiegen.
Gruß,
soenk.e
-
-
-
-