Sicherheit

[Gast]

Guten Tag

Bin im Moment noch Anfänger... Nach dem Lesen von unmengen an Theorie ist einiges noch unklar...
Hoffe hier bekomme ich eine Antwort auf folgende Fragen... Oder zumindest eine Anlaufstelle...

Wie funktioniert das mit PHP und Sicherheit? Wie kann ich zum Beispiel meine Datenbankpasswörter schützen, bzw. verhindern das ein User Zugriff auf meine ungeparste PHP-Datei hat?

Allgemein, wie ist ein Webverzeichnis aufgebaut?

Zum Beispiel Wo kommt ein Javascript File, wo ein PHP File, wo die Html Files und Wo zum Beispiel ein Bild? Wie sieht das ganze punkto Sicherheit aus?

Möchte mich in kürze an meiner ersten Website versuchen... Eine kleine feine Website über einen Kleinbetrieb... Dort soll auch ein Gästebuch zum Einsatz kommen, wo für ich PHP verwenden will...

Ich danke euch schon jetzt für eure Hilfe, Tipps oder sonstiges!

Freundliche Grüsse

[Der Martin]

Hallo,

Hoffe hier bekomme ich eine Antwort auf folgende Fragen... Oder zumindest eine Anlaufstelle...

deine Fragen sind leider recht unspezifisch.

Wie kann ich zum Beispiel meine Datenbankpasswörter schützen, bzw. verhindern das ein User Zugriff auf meine ungeparste PHP-Datei hat?

Welcher User? Gegen jemand, der Zugriff auf das Dateisystem des Servers hat, kannst du dich nicht mehr wehren. Das kann ein Mitarbeiter beim Hoster sein (denen wirst du bis zu einem gewissen Grad vertrauen *müssen*), oder auch ein Hacker, der es schließlich geschafft hat.

Also kann es nur um Schutz vor unbefugten Zugriffen per HTTP gehen. Prinzipiell muss die PHP-Datei aber von außen zugänglich sein, und den ungeparsten Quellcode sieht ein Besucher nur, wenn in der Serverkonfiguration mal ein böser Unfall passiert, was selbstveständlich vorkommen kann.
Gut ist dann, wenn man die wirklich sensiblen Daten in eine include-Datei auslagert und diese außerhalb des Document Root ablegt, so dass sie von außen nicht erreichbar ist.

Allgemein, wie ist ein Webverzeichnis aufgebaut?

Zum Beispiel Wo kommt ein Javascript File, wo ein PHP File, wo die Html Files und Wo zum Beispiel ein Bild? Wie sieht das ganze punkto Sicherheit aus?

Da gibt es keine allgemeinen Regeln. Das macht jeder Hoster bzw. jeder Web-Ersteller so, wie er es mag. Es herrscht nicht einmal Einigkeit darüber, ob man z.B. Javascripts, Stylesheets, Bilder und andere untergeordnete Ressourcen *überhaupt* in separate Verzeichnisse stecken soll. Je nach Projekt kann auch eine andere Organisation günstiger sein.

Möchte mich in kürze an meiner ersten Website versuchen... Eine kleine feine Website über einen Kleinbetrieb... Dort soll auch ein Gästebuch zum Einsatz kommen, wo für ich PHP verwenden will...

Da kommt also schon der Themenkomplex "Schutz gegen Spam, Vandalismus und Missbrauch" ins Spiel. Ich hoffe, dass du dir das eine oder andere Mal fachkundigen Rat holst, wenn es soweit ist. Es gibt auch fertige Scripts, die man "nur noch" einbinden muss, aber auch da gibt es neben ein paar guten auch sehr viel Schlechtes im Netz.

Ciao,
 Martin

[Gast]

Guten Tag

Also kann es nur um Schutz vor unbefugten Zugriffen per HTTP gehen. Prinzipiell muss die PHP-Datei aber von außen zugänglich sein, und den ungeparsten Quellcode sieht ein Besucher nur, wenn in der Serverkonfiguration mal ein böser Unfall passiert, was selbstveständlich vorkommen kann.
Gut ist dann, wenn man die wirklich sensiblen Daten in eine include-Datei auslagert und diese außerhalb des Document Root ablegt, so dass sie von außen nicht erreichbar ist.

Genau um das geht es;-) Aber ich verstehe eben nicht genau was das Root Verzeichnis ist und wiso nicht jeder dort eindringen kann, aber der Server die Datei (z.B Eben die PHP) dort holen kann...
Wer definiert diese Rechte, ich oder der Hoster? Kann ich auch an eine andere Stelle als ins Root Verzeichnis Dateien hochladen per FTP?

Da kommt also schon der Themenkomplex "Schutz gegen Spam, Vandalismus und Missbrauch" ins Spiel. Ich hoffe, dass du dir das eine oder andere Mal fachkundigen Rat holst, wenn es soweit ist. Es gibt auch fertige Scripts, die man "nur noch" einbinden muss, aber auch da gibt es neben ein paar guten auch sehr viel Schlechtes im Netz.

Für das Gästebuch werde ich vermutlich ein fertiges Skript auf meine Bedürfnisse anpassen... Zudem überlege ich mir auf MySQL zu verzichten und stattdessen ein Txt-Dokument zu verwenden...

Grundsätzlich ist es so das ich mir ein paar Html-Files (Css), Js-Files und PHP-Files zusammenschustern kann, nicht zuletzt dank eurer umfangreichen Doku hier (Danke an dieser Stelle) Leider habe ich noch Schwierigkeiten den ganzen Ablauf nach dem Ersteleln der Dateien zu verstehen...

Was kommt dann und wie schützt man seine Website?
Vieleicht kann mir das jemand kurz evtl. in Stichworten näher bringen?

Vielen Dank und freundliche Grüsse

[T-Rex]

Ich mal wieder...

Ich sehe das Thema etwas rationaler. Wenn du eine kleine Webseite für dich und deine Freunde baust, dann wird es wahrscheinlich niemanden auf der Welt geben der sich die mühe macht diese Seite zu hacken. Wozu auch, selbst wenn er an die Datenbank kommt was wird da wohl drin stehen?

Betreibst du hingegen einen erfolgreichen Onlineshop mit sagen wir mal 100.000 Euro Umsatz im Monat mit Kreditkartennummern etc... dann ist das Thema Sicherheit sehr relevant. Bei 100.000 Euro haste dann aber die entsprechenden Mittel einen Fachmann auf das Thema an zu setzen.

So wie du die Fragen stellst, denke ich bist du bei dem Thema noch am Anfang. Daraus schließe ich auch, dass du wahrscheinlich kein großes Portal betreust. Deshalb mein Rat an dich, die einfachsten Sicherheitsmechanismen z.B. Passwörter nicht im Root-Verzeichnis haben reichen erstmal vollkommen aus.
Auch Captchas oder ähnliches für Spamschutz würde ich erstmal ignorieren und mich erst mit dem Thema beschäftigen, wenn der Traffic der Seite ein gewisses Niveau hat.

Gruß
Bitte gibt folgendes Ein
L_54v
T-Rex (deine Eingabe ist falsch)

[suit]

Ich sehe das Thema etwas rationaler. Wenn du eine kleine Webseite für dich und deine Freunde baust, dann wird es wahrscheinlich niemanden auf der Welt geben der sich die mühe macht diese Seite zu hacken. Wozu auch, selbst wenn er an die Datenbank kommt was wird da wohl drin stehen?

Die Wahrscheinlichkeit eines _gezielten_ Angriffs sinkt drastisch, aber viele Angriffe sind ungezielt - Mass Defacements sind der Regelfall, es gibt ausreichend Werkzeuge um Websites/Webserver nach bestimmten Schwachstellen zu testen und dann fast automatisiert anzugreifen.

"Ich bin ja eh unwichtig" ist ein denkbar schlechtes Argument nicht auf Sicherheit zu achten - es ist dann immer eine Frage des Schadens - was passiert bei einem "Einbruch"? Zieh ich ein Backup drüber, schließe die Lücke und gut ist oder habe ich einen wirtschaftlichen oder sozialen Schaden?

Betreibst du hingegen einen erfolgreichen Onlineshop mit sagen wir mal 100.000 Euro Umsatz im Monat mit Kreditkartennummern etc... dann ist das Thema Sicherheit sehr relevant. Bei 100.000 Euro haste dann aber die entsprechenden Mittel einen Fachmann auf das Thema an zu setzen.

Sicherheit soll keine Budgetfrage in deinem Extrembeispiel sollte das klar sein - aber du hast ja keine Ahnung was alles herumgondelt, ich hatte letztens mit dem Backend einer Website zu tun, die hatten ein Bestellformular welches Kreditkartendaten annimmt, speichert (inklusive Sicherheitscode) und dann in einer Tabelle ablegt - noch dazu war es ein sehr altes ungepachtes TYPO3 mit einer sehr bekannten Sicherheitslücke die binnen Minuten Vollzugriff auf das System erlaubt - und das System ist so angeblich durch ein "Security Audit" gekommen. Wir haben dem Kunden in diesem Fall geraten das System ersatzlos zu streichen oder ordentlich umzusetzen, was bei einem Online-Shop natürlich dann nicht mit ein paarhundert Euro, wie bei einem Formmailer, möglich ist.

[dedlfix]

Tach!

Ich sehe das Thema etwas rationaler. Wenn du eine kleine Webseite für dich und deine Freunde baust, dann wird es wahrscheinlich niemanden auf der Welt geben der sich die mühe macht diese Seite zu hacken. Wozu auch, selbst wenn er an die Datenbank kommt was wird da wohl drin stehen?

Nun, es mag durchaus sein, dass die Inhalte seiner Seiten für Angreifer uninteressant sind. Was aber interessant ist, ist der Speicherplatz, die Rechenpower und die gute Netzwerkanbindung. Alles kann man sehr gut für irgendwelchen Mist missbrauchen. Und das ist leider nicht nur Theorie sondern gängige Praxis. Ein DSL-Anschluss mit einer geringen Upload-Rate ist weniger interessant als ein Server mit ordentlicher Leitung. Selbst wenn man nur ein Gast bei einem Massenhoster ist, ist man als Ziel nicht uninteressant.

dedlfix.

[T-Rex]

Ein guter Punkt! Der wird assimiliert!

Gruß
Sicherheitsberater
T-Rex

[suit]

Genau um das geht es;-) Aber ich verstehe eben nicht genau was das Root Verzeichnis ist und wiso nicht jeder dort eindringen kann, aber der Server die Datei (z.B Eben die PHP) dort holen kann...

Das DocumentRoot ist unter Apache das Stammverzeichnis für deine Website welches ausgeliefert wird, wenn du einen URL ohne Pfad eingibst - bzw. üblicherweise wird dort ein index.php oder index.html-File platziert und jenes ausgeliefert.

Die Verzeichnisstruktur am Webserver kann so aussehen:
/data/www/log/example.com-error.log
/data/www/log/example.com-access.log
/data/www/conf/example.com.conf
/data/www/example.com/index.php
/data/www/example.com/foo/bar.php

example.com ist das DocumentRoot für den Virtual Host der auf example.com reagiert - wenn jemand also http://example.com/ anfordert, bekommt er index.php ausgeliefert, wenn er http://example.com/foo/bar.php anfordert bekommt er jenes ausgelierfert - er kann aber unmöglich irgendwas außerhalb dieses Verzeichnisses per HTTP von außen anfordern.

Wer definiert diese Rechte, ich oder der Hoster? Kann ich auch an eine andere Stelle als ins Root Verzeichnis Dateien hochladen per FTP?

Derjenige der den Server technisch betreut - das kannst du oder der Hoster sein - je nach Art des Zugriffs auf den Server, bei Webhostingpaketen ist das idR. vorgegeben, wenn du einen Rechner mit root-Zugriff mietest, dann bist du dafür selbst verantwortlich.

»» Zudem überlege ich mir auf MySQL zu verzichten und stattdessen ein Txt-Dokument zu verwenden...

Wozu? Natürlich fügt jede zusätzliche Software mehr Komplexität und mehr Sicherheitsrisiken hinzu, aber der nutzen einer SQL-Datenbank für strukturierte Daten übersteigt die verwaltung als Plaintext idR. bei weitem - von Speziallösungen mal abgesehen.

Was kommt dann und wie schützt man seine Website?

Dafür ist Erfahrung und Ausprobiererei nötig - ein Vorteil ist aber wenn du sachen die du selbst noch nicht weißt an jemanden auslagerst der das kann und das trifft besonders auf das Hosting zu.

[suit]

Wie funktioniert das mit PHP und Sicherheit? Wie kann ich zum Beispiel meine Datenbankpasswörter schützen, bzw. verhindern das ein User Zugriff auf meine ungeparste PHP-Datei hat?

Prinzipiell sollte ein Webserver mit ordentlich konfiguriertem PHP keinen Zugriff auf den Quelltext erlauben und immer nur die interpretierten Daten ausliefern.

Je nach Konfiguration kann es aber auch möglich sein, dass man einfach durch das anhängen eines "s" an die Ressource den Sourcecode ausgeben kann - dafür gibt es eigenen eigenen Handler der sich "php-source" nennt.

Prinzipiell sollte in keinem deiner Files irgendetwas drinnen stehen, was einem Angreifer einen Vorteil verschaffen könnte - dh, selbst wenn er den kompletten Quelltext hat, muss er nur "ja, schön" sagen können und dastehen wie am Anfang. Man muss hier nur verbreitete Open-Source-Software nehmen, da kann der Server abgesichert sein wie er will - wenn jemand an den Quelltext will muss er dich theoretisch nur fragen oder den Code aus der offiziellen Quelle laden.

Aber wir reden hier ja von Zugangsdaten, Schlüssel, usw. - diese liegen hoffentlich in isolierten Files und die gilt es getrennt zu schützen, sollte irgend ein Mechanismus fehlschlagen.

Hier kann man einen Datei- oder Verzeichnisschutz über den Webserver einrichten - z.B. per .htaccess oder direkt über die Webserverkonfiguration.

Aber auch dies kann fehlschlagen und dann liegen die Daten nackt da - darum ist es die Optimallösung sämtliche Konfigurationsdaten oberhalb des DocumentRoot zu plazieren, dann kann sie der HTTP-Server unmöglich ausliefern - das ist in der Praxis oft aber nicht möglich.

Darum sollten besonders Zugangsdaten die z.B. für den Datenbankserver gedacht sind niemals Vollzugriff haben sondern nur die rechte die gerade gebraucht werden - das kann z.B. nur lesender und schreibender Zugriff auf Tabellen sein, aber verbieten diese in ihrer Struktur zu verändern oder neue zu erzeugen oder gar neue Benutzer anzulegen (ALTER, GRANT ...)

Allgemein, wie ist ein Webverzeichnis aufgebaut?

Siehe oben.

Zum Beispiel Wo kommt ein Javascript File, wo ein PHP File, wo die Html Files und Wo zum Beispiel ein Bild? Wie sieht das ganze punkto Sicherheit aus?

Das ist eher persönliche Präferenz alsdass es mit Sicherheit zu tun hätte - mit Ausnahme natürlich sensibler Daten die von außen nicht (oder nur über "Umwege") gelesen werden dürfen.

Möchte mich in kürze an meiner ersten Website versuchen... Eine kleine feine Website über einen Kleinbetrieb... Dort soll auch ein Gästebuch zum Einsatz kommen, wo für ich PHP verwenden will...

Nimm eine fertige Lösung für das CMS oder das Gästebuch (und nicht einfach die erstbeste die du findest), wähle ein Hostingpaket bei einem professionellen Hoster der dir Backups macht und für die einwandfreie Funktion des Webservers steht - das ist bereits die halbe Miete.

Wordpress könnte in diesem Kontext für dich Interessant sein - das eignet sich womöglich ganz gut für eine kleine Website mit Gästebuch.

Wenn du alles selbst stricken willst, wird - ohne dich jetzt demotivieren zu wollen - dein erster Versuch ziemlich in die Hose gehen. Das ist wie beim Häuser bauen:

Baue dein erstes Haus für deinen schlimmsten Feind, baue das zweite Haus für deinen besten Freund und baue erst dein drittes Haus für dich selbst.

[Sven Rautenberg]

Moin!

Bin im Moment noch Anfänger... Nach dem Lesen von unmengen an Theorie ist einiges noch unklar...
Hoffe hier bekomme ich eine Antwort auf folgende Fragen... Oder zumindest eine Anlaufstelle...

Webapplikations-Sicherheit ist ein sehr komplexes Thema, weil es viele verschiedene Stellen innerhalb der Applikation gibt, an der jenen jeweils unterschiedliche Probleme auftreten können. Am einfachsten ist es daher, sich nicht zuerst mit dem Gesamtsytem zu beschäftigen, sondern anhand der Einzelteile jeweils die typischen Anfälligkeiten kennenzulernen. Wenn man an jeder einzelnen Stelle alles richtig macht, sieht die Gesamtsicherheit automatisch viel besser aus.

Eine gute Anlaufstelle für Websicherheit ist OWASP. Die geben eine Top 10 Liste heraus mit den typischen Sicherheitslücken in Websoftware.

Es gibt den Anfang einer deutschsprachigen Wiki-Seite dazu: OWASP Top 10 für Entwickler

Das englische Original: OWASP Top 10 - die Ausgabe von 2013 ist gerade im Entstehen, die noch aktuelle Version ist von 2010.

Die OWASP Top 10 listen eigentlich die gesamte Vielfalt an Angriffen auf, denen eine Software ausgesetzt ist. Sie beschreiben aber nicht direkt, was man dagegen tun kann - dazu gibts die "Cheat Sheets" - beispielsweise das SQL Injection Prevention Cheat Sheet.

Dieses listet allerdings auch wieder noch nicht direkt auf, wie man SQL Injection konkret in PHP verhindert - dazu braucht es einerseits das Wissen, welche Datenbank verwendet wird, und zweitens dann dazugehörig das Wissen, wie man in PHP mit dieser Datenbank Escaping oder Stored Procedures verwendet.

Wie du siehst, ist nur für diesen einen Teilaspekt "SQL Injection" als Untergruppe von "Top A1: Injections" Wissen auf recht vielen Ebenen notwendig, wenn man von oben ausgeht und "Sicherheit" will. Allerdings führt kein Weg drum herum: Sicherheit entsteht nur, indem man alle Unsicherheitsaspekte kennt oder nachlesen kann, und entsprechend handelt.

Andererseits ist es weit weniger schlimm, als es für dich jetzt vielleicht aussieht: In einer kleinen, typischen Gästebuch-Applikation sind die Transportwege der Daten übersichtlich und nicht ausufernd, du hast es also nicht mit der kompletten Liste an Top10-Problemen zu tun, und die, die zutreffen, sind in deiner Situation recht simpel zu berücksichtigen, weil du keine komplexe Applikation schreibst: Viele Aspekte treffen einfach nicht zu.

Wenn man es wirklich herunterbricht auf den kleinstmöglichen Level, lautet die generelle Antwort gegen alle Probleme: Kontextgerecht escapen! Details stehen bei SELFHTML im Wiki: http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel

Wie funktioniert das mit PHP und Sicherheit? Wie kann ich zum Beispiel meine Datenbankpasswörter schützen, bzw. verhindern das ein User Zugriff auf meine ungeparste PHP-Datei hat?

Ungeparste PHP-Dateien entstehen nur, wenn der Webserver falsch konfiguriert ist. Aber um doppelt sicherzugehen, legt man solche Dateien gern außerhalb des konfigurierten Document-Root-Verzeichnisses ab (das ist das Verzeichnis, dessen index.html oder index.php erscheint, wenn man "www.example.org/" eingibt). Außerhalb heißt: Auf Dateisystemebene des Servers ein Verzeichnis weiter nach oben, und dort ggf. in ein anderes Unterverzeichnis. PHP greift auf diese Datei nicht als URL zu (das geht ja auch nicht mehr, würde außerdem nicht funktionieren, da dann der Quellcode nicht ausgeliefert wird, sondern das ausgeführte Skript-Ergebnis), sondern auch über das Dateisystem.

Allgemein, wie ist ein Webverzeichnis aufgebaut?

Es gibt irgendwo ein Verzeichnis als Document-Root. Wenn dein Webanbieter gut ist, lässt er dich via SFTP, SCP oder (leider, weil unverschlüsselt) FTP auf deinen Webspace zugreifen, so dass du in deinem Webspace beliebig Verzeichnisse erstellen kannst, und in der Konfigurationsoberfläche erlaubt er dir dann die Auswahl eines Verzeichnisses als "Hauptverzeichnis" deiner Webseite. Eventuell ist das ganze auch festverdrahtet, so dass z.B. schon ein Verzeichnis "public", "html" oder "htdocs" in deinem Webspace erscheint, und du daneben weitere Verzeichnisse erstellen kannst.

Außer der Unterscheidung zwischen Verzeichnissen und Dateien innerhalb der Document-Root-Verzeichnisse (per HTTP erreichbar) und außerhalb (unerreichbar) gibt es keine technischen Vorgaben - das ist im Prinzip alles dir überlassen. Wenn man allerdings diverse Frameworks einsetzt, hat sich etabliert, den PHP-Code möglichst außerhalb zu platzieren, und nur eine kleine index.php innerhalb des Document-Root zu speichern, die ihrerseits dann die Applikation außerhalb aufruft und startet. Das verhindert recht effektiv, dass man einzelne PHP-Skripte als Angreifer direkt ansteuern kann.

Für ein schlichtes Gästebuch ist das allerdings nicht zwingend nötig.

Alle anderen Dateien, die an den Browser ausgeliefert werden sollen, also pures HTML, CSS, Javascript, Bilder u.ä. müssen innerhalb des Document-Root platziert werden, sonst kann der Browser sie nicht abrufen.

Zum Beispiel Wo kommt ein Javascript File, wo ein PHP File, wo die Html Files und Wo zum Beispiel ein Bild? Wie sieht das ganze punkto Sicherheit aus?

Server-Sicherheit ist bei diesen Ressourcen (außer PHP) nicht relevant, weil diese statischen Dateien nicht auf dem Server ausgeführt werden. Die Ordnung sollte sich aus deiner Programmierung heraus ergeben: Dort, wo die Dateien sinnvoll platziert sind, solltest du sie ablegen. Mir fällt dazu kein sinnvolles, immer gültiges Schema ein, dass man anwenden sollte.

Bedenke allerdings, dass die URL für Suchmaschinen interessant ist. Und der Pfad innerhalb des Document-Root zu den Dateien ist automatisch Bestandteil der URL. Es ist also schlau, hier sinnvolle Worte zu verwenden, genauso wie für die Dateinamen selbst. Zumindest für HTML-Dateien (Bilder, CSS und Javascript werden ja nicht direkt vom Browser aufgerufen, sondern nur nachgeladen).

Möchte mich in kürze an meiner ersten Website versuchen... Eine kleine feine Website über einen Kleinbetrieb... Dort soll auch ein Gästebuch zum Einsatz kommen, wo für ich PHP verwenden will...

Du solltest dir unbedingt lokal einen Webserver installieren, damit du ohne dass die ganze Welt schon zugreifen kann, deine Webseite ausprobieren kannst. Insbesondere PHP erfordert das, ansonsten würde der PHP-Code nicht ausgeführt werden.

Mögliche Lösungen sind XAMPP, oder als Virtuelle Maschine z.B. VirtualBox mit Vagrant und einem passenden Image (das ist allerdings die technisch aufwendigere Lösung, die von dir erfordert, dass du dich mit Serveradministration besser auskennst).

- Sven Rautenberg

[dedlfix]

Tach!

Dieses listet allerdings auch wieder noch nicht direkt auf, wie man SQL Injection konkret in PHP verhindert - dazu braucht es einerseits das Wissen, welche Datenbank verwendet wird, und zweitens dann dazugehörig das Wissen, wie man in PHP mit dieser Datenbank Escaping oder Stored Procedures verwendet.

Kleine Korrektur: Du meintest vermutlich Prepared Statements statt Stored Procedures. Letztere wären kein "oder" zum Escaping.

dedlfix.

[Sven Rautenberg]

Moin!

Dieses listet allerdings auch wieder noch nicht direkt auf, wie man SQL Injection konkret in PHP verhindert - dazu braucht es einerseits das Wissen, welche Datenbank verwendet wird, und zweitens dann dazugehörig das Wissen, wie man in PHP mit dieser Datenbank Escaping oder Stored Procedures verwendet.

Kleine Korrektur: Du meintest vermutlich Prepared Statements statt Stored Procedures. Letztere wären kein "oder" zum Escaping.

Ja, ich meinte Prepared Statements - also das, von dem viele reden, als wäre es die ultimative Waffe gegen SQL-Injection, und die dabei vergessen, dass man damit eben leider längst nicht alle Queries realisieren kann, oder alternativ trotzdem Injection-Probleme bekommt.

- Sven Rautenberg

[Gast]

Guten Tag

Ungeparste PHP-Dateien entstehen nur, wenn der Webserver falsch konfiguriert ist. Aber um doppelt sicherzugehen, legt man solche Dateien gern außerhalb des konfigurierten Document-Root-Verzeichnisses ab (das ist das Verzeichnis, dessen index.html oder index.php erscheint, wenn man "www.example.org/" eingibt). Außerhalb heißt: Auf Dateisystemebene des Servers ein Verzeichnis weiter nach oben, und dort ggf. in ein anderes Unterverzeichnis. PHP greift auf diese Datei nicht als URL zu (das geht ja auch nicht mehr, würde außerdem nicht funktionieren, da dann der Quellcode nicht ausgeliefert wird, sondern das ausgeführte Skript-Ergebnis), sondern auch über das Dateisystem.

Dann funktioniert das ganze auf dem Webserver? Das heisst ich kann z.B auch nicht über den Windows-Explorer mit der IP des Servers und dem Dateinamen der PHP auf den Sourcecode zugreifen (vorausgesetzt die PHP wird nicht geparst)?

Angenommen ich hoste die Website bei einem Standarthoster, kann ich dort überhaupt ein Verzeichnis ausserhalb des Root Verzeichnisses erstellen für die PHP? Oder muss ich da auf ein spezielles Angebot zurückgreifen?

Hat jemand ein Codebeispiel für eine index.php, damit ich sehen kann wie das mit der Verlinkung auf eine andere PHP-Datei (Ausserhalb Root-Verzeichnis) funktioniert?

Vielen Dank für alle die nützlichen Beiträge! Nicht umsonst mein Lieblingsforum;-)

Liebe Grüsse

[dedlfix]

Tach!

Dann funktioniert das ganze auf dem Webserver? Das heisst ich kann z.B auch nicht über den Windows-Explorer mit der IP des Servers und dem Dateinamen der PHP auf den Sourcecode zugreifen (vorausgesetzt die PHP wird nicht geparst)?

Üblicherweise sind die Webserver beim Provider nicht mit SMB/CIFS (das Windows-Netzwer-Datei-Protokoll (= Freigaben verbinden)) ausgestattet. Allerdings gibt es einen Zugang für dich, über den du deine Dateien verwalten und hochladen musst. Der ist mit einer mehr oder weniger guten Login-Mechanismus (sprich üblicherweise: schwer erratbares Passwort) gesichert.

Angenommen ich hoste die Website bei einem Standarthoster, kann ich dort überhaupt ein Verzeichnis ausserhalb des Root Verzeichnisses erstellen für die PHP?

Ja. Nein. Kommt auf den Hoster und dessen Standard an. 1&1 zum Beispiel kann das.

Hat jemand ein Codebeispiel für eine index.php, damit ich sehen kann wie das mit der Verlinkung auf eine andere PHP-Datei (Ausserhalb Root-Verzeichnis) funktioniert?

Verlinkung? Dateisystemzugriff. Alles was auf Dateien zugreift, wie zum Beispiel require/include(_once). Dazu muss man das Prinzip der relativen Adressierung kennen, also ../ zeigt ein Verzeichnis nach oben, ../foo zeigt auf den Nachbarn mit Namen foo.

dedlfix.

[Malware-Schleuder]

Mein Tipp: Achte unbedingt darauf dich gegen Spam abzusichern. Gästebücher werden dermaßen zugemüllt in den letzten Jahren das es nicht mehr schön ist. Ein "gutes" Captcha bzw. andere Maßnahmen wie eine Blacklist etc. wären da sehr sinnvoll

[Der Martin]

Hi,

Mein Tipp: Achte unbedingt darauf dich gegen Spam abzusichern. Gästebücher werden dermaßen zugemüllt in den letzten Jahren das es nicht mehr schön ist. Ein "gutes" Captcha bzw. andere Maßnahmen wie eine Blacklist etc. wären da sehr sinnvoll

warum erzählst du das Sven, und nicht dem Thread-Starter?

So long,
 Martin