[FloB]

An fopen() hatte ich noch gar nicht gedacht .. kann man das nicht per CHMOD verbieten?

Natürlich kann jemand einfach so die DB verwüsten, es ist aber nochmal etwas anderes, wenn andere Personen die Verbindungsdaten kennen.

Aber wenn ihr meint, dass meine Vorgehensweise nicht effektiv ist, kann ich es auch lassen.


Soll ich dann eine Methode einbauen, die die DB-Daten aus der Config-Klasse ausliest oder sollen die per Parameter übergeben werden und im aufrufenden Script die Daten aus der Conf-Klasse lesen?

[robo47]

Zitat von FloB

An fopen() hatte ich noch gar nicht gedacht .. kann man das nicht per CHMOD verbieten?

Natürlich kann jemand einfach so die DB verwüsten, es ist aber nochmal etwas anderes, wenn andere Personen die Verbindungsdaten kennen.

Aber wenn ihr meint, dass meine Vorgehensweise nicht effektiv ist, kann ich es auch lassen.


Soll ich dann eine Methode einbauen, die die DB-Daten aus der Config-Klasse ausliest oder sollen die per Parameter übergeben werden und im aufrufenden Script die Daten aus der Conf-Klasse lesen?

wovor hast du angst, woher kommt denn dein potentieller angreifer ? wenn er eh schon zugriff auf dein htdocs-verzeichnis hat und dort ein script platzieren kann .... dann brauchst du dir um sicherheit keine gedanken mehr zu machen

[FloB]

Es geht mir eher ums Prinzip - so wenig Schwachstellen wir möglich bieten!

[Artemis]

Zitat von FloB

An fopen() hatte ich noch gar nicht gedacht .. kann man das nicht per CHMOD verbieten?

Nein. Jedes Script wird mit der gleichen Benutzerkennung ausgeführt und ich denke, wenn man mit fopen nicht mehr darauf zugreifen kann, kann man dass auch nicht mehr per include einbinden. Außerdem ist es so wie robo sagt. Wenn du eventuellen Modulen nicht trauen kannst, die andere in dein System einbringen, musst du sie halt vorher prüfen.

[Basti]

Was genau sind denn die Anforderungen?

Du willst eine Anwendung schreiben und kodiert auf deinen Server legen und allen möglichen Kunden darauf Zugriff geben, die dann selbstständig für "ihre Instanz" der Anwendung Module installieren können, richtig?

Hier muss doch eh jeder Kunde eine eigene Datenbank bekommen, denn was nützen versteckte Zugangsdaten (was du, denke ich nur hinbekommst, wenn du die Daten als globale variable in den verschlüsselten Quellcode schreibst und nach dem Verbindungsaufbau wieder löschst), wenn die Kunden eh via mysql_query die ganze Datenbank lesen und manipulieren können.

Und, wozu dann überhaupt eine Abstraktion, wenn die Vorgaben derart speziell sind.

Mir kommt es so vor, als hättest du dein Ziel gar nicht klar vor Augen, sondern schreibst mal was, das möglichst flexibel und sicher in alle möglichen Richtungen sein soll. Damit kannst du eigentlich nur auf die Nase fallen, denn sowas braucht kein Mensch. Niemand will mit einer MySQL-Klasse arbeiten, in die er die Verbindungsdaten direkt reinschreiben muss - zumindest nicht, solange der dadurch entstehende Nutzen nicht ganz klar definiert ist und so womöglich die Anforderungen einiger Anwender erfüllt.

Was genau ist dein Ziel, was ist die Anforderung?

Basti