Subunternehmer des Kunden aus der Hölle

[suit]

Subunternehmer beschwert sich bei Kunden, dass wir es nicht schaffen ihm einen Datenbankzugang einzurichten, Benutzerdaten funktionieren nicht - bekommt immer Fehlermeldung. Frechheit, unprofessionell usw. - das geht jetzt schon im Ping-Pong etwa seit 15. September so dahin.

Heute wieder dasselbe - ich geb' das an unseren Servermenschen weiter, der schaut sich das an und bestätigt mir hoch und heilig, dass alles funktioniert und er sich das nicht erklären kann warum die Zugangsdaten nicht funktionieren. Auf der Shell gehts, in einem Testscript gehts und mit MySQL-Workbench auch. Eine halbe Stunde später meldet er sich wieder und sagt, dass ihm dass keine Ruhe gelassen hat und er jetzt mal in den Code von dem Subunternehmer des Kunden geschaut hat - dabei hat er das hier gefunden:

define("DB_PASS", "1$xgz7BD");

Anm.: das Passwort hier ist nicht das tatsächliche, folgt aber demselben Schema. Wer findet den Fehler? btw: das Syntaxhighlighting ist bewusst aus.

Einmal mit Profis arbeiten sag' ich euch :(

[Steffen]

Danke :-) (Und mein Beileid)

Schreib ihm zurück, er soll die fehlende Variable $xgz7BD="$xgz7BD"; definieren. Vielleicht kommt er dann von selber drauf. :-D

MMD

[suit]

Schreib ihm zurück, er soll die fehlende Variable $xgz7BD="$xgz7BD"; definieren. Vielleicht kommt er dann von selber drauf. :-D

In order to understand recursion, one must first understand recursion :)

[Steffen]

Hi!

Aber eigentlich liegt ja der Fehler ganz bei Dir.
Das richtige Passwort ist wahrscheinlich 1$xgz7BD. Mit Deinem Beispielcode kannst Du's eh leicht überprüfen. ;-)

Grüße

• Steffen

PS
Oder schick ihm das "neue" Passwort "sorryrm -rf ..". ;-)

[1UnitedPower]

Meine Herren,

Aber eigentlich liegt ja der Fehler ganz bei Dir.
Das richtige Passwort ist wahrscheinlich 1$xgz7BD. Mit Deinem Beispielcode kannst Du's eh leicht überprüfen. ;-)

Er kann doch den Kontext nicht erraten, indem das Passwort verwendet wird. Die Kontext-gerechte Maskierung liegt in der Verantwortung des Anwenders.

[suit]

Aber eigentlich liegt ja der Fehler ganz bei Dir.
Das richtige Passwort ist wahrscheinlich 1$xgz7BD. Mit Deinem Beispielcode kannst Du's eh leicht überprüfen. ;-)

Er kann doch den Kontext nicht erraten, indem das Passwort verwendet wird. Die Kontext-gerechte Maskierung liegt in der Verantwortung des Anwenders.

Ja, aber nachdem das ganze auf einem von uns betreuten Server läuft kann ich den Code reinschaun - wird sicher spassig - das nächste mal bekommt er als Passwort 1';die();/* zugeschickt :D

[1UnitedPower]

Meine Herren,

das nächste mal bekommt er als Passwort 1';die();/* zugeschickt :D

Oder:
";´sudo shutdown -h now´;

[Ole]

Little Bobby Tables

Gruß
Ole

[MudGuard]

Hi,

define("DB_PASS", "1$xgz7BD");
Anm.: das Passwort hier ist nicht das tatsächliche, folgt aber demselben Schema. Wer findet den Fehler? btw: das Syntaxhighlighting ist bewusst aus.

Fehler? Kommt drauf an, ob die Variable definiert ist und welchen Inhalt sie hat ...

cu,
Andreas

[Linuchs]

define("DB_PASS", "1$xgz7BD");

Ich rate mal mit.

Bei doppelten Gänsefüßen interpretiert PHP den Inhalt, etwa echo "Hallo\n"; und da könnte die Währung stören.

Wie wäre es so: define("DB_PASS", '1$xgz7BD');

Linuchs

[dedlfix]

Tach!

define("DB_PASS", "1$xgz7BD");

Das ist eines der wenigen Prinzipien, die ich habe: PHP-Strings immer in '' einzufassen, wenn die Merkmale von "" nicht benötigt werden.

Außerdem: Mit error_reporting == E_ALL wäre das auch nicht passiert.

dedlfix.

[hotti]

hi,

define("DB_PASS", "1$xgz7BD");

Das ist eines der wenigen Prinzipien, die ich habe: PHP-Strings immer in '' einzufassen, wenn die Merkmale von "" nicht benötigt werden.

Passworte haben in PHP-Scripts überhaupt nichts zu suchen.

Außerdem: Mit error_reporting == E_ALL wäre das auch nicht passiert.

Ergänzung: Da wo ein Passwort notiert ist, gibt es weder

• error_reporting
  noch
• Syntaxhighlighting

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Ganz einfach.
Horst

[dedlfix]

Tach!

Passworte haben in PHP-Scripts überhaupt nichts zu suchen.

Sagt wer?

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Es ist kein Gesetzesverstoß und nicht unüblich, Konfigurationswerte als PHP-Code zu notieren. Werte aus einer geparsten Konfigurationsdatei können immer nur in Variablen abgelegt werden. Damit sind sie gegenüber Konstanten manipulierbar, was oftmals nicht gewünscht ist. Aus meiner Sicht spricht nichts gegen den generellen Einsatz von Konstanten oder PHP-Code für Konfigurationswerte.

dedlfix.

[hotti]

hi,

[..] Sicht spricht nichts gegen den generellen Einsatz von Konstanten oder PHP-Code für Konfigurationswerte.

Denk mal ein bischen weiter. Z.B. wenn PHP-Dateien einer Versionskontrolle unterliegen. Neues Passwort => neue Version einchecken. Wäre doch Quatsch, wenn sich am Code nichts geändert hat. Und in einer Repository haben Passworte erst recht nix verloren.

Schönen Abend ;)

[Lispler]

Hoch!

[..] Sicht spricht nichts gegen den generellen Einsatz von Konstanten oder PHP-Code für Konfigurationswerte.

Denk mal ein bischen weiter. Z.B. wenn PHP-Dateien einer Versionskontrolle unterliegen. Neues Passwort => neue Version einchecken. Wäre doch Quatsch, wenn sich am Code nichts geändert hat. Und in einer Repository haben Passworte erst recht nix verloren.

Es geht ja generell um Konfigurationswerte. Und ja, auch das muss versioniert werden. Keine Frage. Aber grundsätzlich ist es keine schlechte Idee, Passworte in entsprechenden Dateien bereitzustellen.

[dedlfix]

Tach!

[..] Sicht spricht nichts gegen den generellen Einsatz von Konstanten oder PHP-Code für Konfigurationswerte.
Denk mal ein bischen weiter. Z.B. wenn PHP-Dateien einer Versionskontrolle unterliegen.

Am Ende bleibt sich gleich, ob man nun die config.ini oder die config.php nicht unter Versionskontrolle (die auch nicht generell gebraucht wird) stellt.

dedlfix.

[M.]

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Und wenn der Server die Datei nicht parst sondern als Plain ausgibt?
Dann baut dir dein "Gesetz" ein Sicherheitsloch, indem er das Passwort im Klartext anzeigt.

Solche Pauschalaussagen, ohne die Servervorrausetzungen zu kennen, sind echt gefährlich.

[tinita]

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Und wenn der Server die Datei nicht parst sondern als Plain ausgibt?
Dann baut dir dein "Gesetz" ein Sicherheitsloch, indem er das Passwort im Klartext anzeigt.

Das kann ja wohl kein Grund sein, keine Konfigurationsdatei zu verwenden.
Configs gehören nicht ins document root.

[M.]

Das kann ja wohl kein Grund sein, keine Konfigurationsdatei zu verwenden.

Also soll der Programmierer immer eine .ini benutzen anstatt einer .php,nur weil "man es einfach so macht"?

Configs gehören nicht ins document root.

Und auch hier gibt es Server, die das nicht zulassen. Da nimmst du das Sicherheitsloch dann einfach in kauf, ist ja nicht dein Problem, oder?

Vielleicht bin ich altmodisch, aber ich bin der Meinung, Software sollte auf möglichst vielen Serverkonfigurationen ohne Änderungen lauffähig sein. Und dass das ohne solchen Sicherheitslücken klappt, beweisen viele Programmierer.

Wenn du und Hotti das anders sehen, ist das ganz allein eure Sache, auf jeden Fall würde ich von euch nichts machen lassen, denn aus Prinzip ein Sicherheitsloch zuzlassen ist ein absolutes NoGo für einen Programmierer.

[tinita]

Das kann ja wohl kein Grund sein, keine Konfigurationsdatei zu verwenden.

Also soll der Programmierer immer eine .ini benutzen anstatt einer .php,nur weil "man es einfach so macht"?

kannst du bitte aufhören, mir dinge in den mund zu legen, die ich nie gesagt habe?
ich habe nirgendwo gesagt, man muss immer eine .ini verwenden.
wenn dann stammt diese aussage von hotti.
(im übrigen redete er von konfigurationsdateien.
ist das so in der PHP-welt, dass man da immer gleich an .ini denkt? nur so nebenbei gefragt. oder gibts auch yaml?)

ich sage nur: wenn die sorge davor, dass eine config-datei über den webserver auslesbar sein könnte, der grund ist, auf configs zu verzichten bzw. davor zu warnen, dann hast du mein mitleid.

Configs gehören nicht ins document root.

Und auch hier gibt es Server, die das nicht zulassen. Da nimmst du das Sicherheitsloch dann einfach in kauf, ist ja nicht dein Problem, oder?

Was hast du denn gefrühstückt? Ich nehme überhaupt kein Sicherheitsloch in Kauf.

Vielleicht bin ich altmodisch, aber ich bin der Meinung, Software sollte auf möglichst vielen Serverkonfigurationen ohne Änderungen lauffähig sein. Und dass das ohne solchen Sicherheitslücken klappt, beweisen viele Programmierer.

Und das das auch *mit* vielen Sicherheitslücken *nicht* klappt, beweisen leider auch sehr viele Programmierer. Die meisten Sicherheitslücken, dir mir so begegnen, sind aber sql-injections und XSS.

Wenn du und Hotti das anders sehen, ist das ganz allein eure Sache,

für dich gibt es offenbar nur schwarz und weiss. alle in einen topf werfen, die dir irgendwas entgegnen.

auf jeden Fall würde ich von euch nichts machen lassen, denn aus Prinzip ein Sicherheitsloch zuzlassen ist ein absolutes NoGo für einen Programmierer.

aha, ich bin also jemand, der aus prinzip ein Sicherheitsloch zulässt. Das schliesst du aus meinen Aussagen in diesem Thread.

Ganz ehrlich, ich würde auch nie was von dir "machen lassen".
Ernsthafte Dinge hostet man nicht auf Billig-Servern, in denen alles im doc root liegen muss.

Falls man sich aus irgendeinem Grund mal mit solchen Begebenheiten rumschlagen muss, tut man das, was in der Situation notwendig ist.

Ich halte nichts davon, zu generalisieren. Weil ein Skript laut deiner Aussage ohne jegliche Änderung auf allen erdenklichen Servern laufen sollte, sollte man auf Configs verzichten, weil die Möglichkeit besteht, dass es Server gibt, auf denen configs über HTTP auslesbar sind.
Das kann doch nicht ernsthaft eine Leitlinie zum Programmieren sein.

[dedlfix]

Tach!

ist das so in der PHP-welt, dass man da immer gleich an .ini denkt? nur so nebenbei gefragt. oder gibts auch yaml?)

Hottis Welt ist Perl. Abgesehen davon, ist es in PHP sehr einfach, eine ini-Datei in einem Zug in ein Array zu bringen. XML geht auch als Konfigurationsdatenquelle, ist aber selbst mit SimpleXML deutlich komplexer zu bedienen. JSON hat ebenfalls eingebaute PHP-Unterstützung, YAML (noch) nicht (im Core, erst PECL).

ich sage nur: wenn die sorge davor, dass eine config-datei über den webserver auslesbar sein könnte, der grund ist, auf configs zu verzichten bzw. davor zu warnen, dann hast du mein mitleid.

Lösungen sollten immer an die Umstände angepasst sein. Die Erfahrung sagt, dass oftmals bei den Hostern kein Platz außerhalb des DocumentRoots vorhanden ist oder die Nutzer das System nicht auf diese Weise zu konfigurieren in der Lage sind. Große populäre Projekte tragen diesem Umstand Rechnung, sie müssen das, weil sie sonst in Support- und "geht nicht"-Meldungen ersticken. Beispielsweise haben Wordpress und Joomla immer leere index.html-Dateien in den Verzeichnissen, die nur für nicht direkt aufrufbare Code-Dateien vorgesehen sind. Die bessere Konfiguration wäre, diese Library-Pfade außerhalb des Docroots abzulegen. Das ist aber so nicht auf allen Systemen installierbar. Selbst das Ausschalten des Directory-Listings kann man nicht voraussetzen. Der Kompromiss ist dann eben die leere index.html, damit man wenigstens ein wenig Sicherheit hat. Wenn man nun mit dem Prinzip "Nur-Code (und Configs) außerhalb des DocumentRoot lagern" daherkommt, ist man auf vielen Systemen nicht verwendbar. Das Prinzip ist zwar generell gut, aber hier eben nicht. Deshalb ist es nicht sonderlich sinnvoll, nur nach Prinzipien zu entscheiden und zu handeln und alles andere nicht mehr zu bedenken. Und genausowenig ist es gut, lediglich die Prinzipien zu vertreten und alles andere auszublenden. Das ist der hauptsächliche Kritikpunkt an Hottis Argumentation.

Configs gehören nicht ins document root.
Und auch hier gibt es Server, die das nicht zulassen. Da nimmst du das Sicherheitsloch dann einfach in kauf, ist ja nicht dein Problem, oder?
Ich nehme überhaupt kein Sicherheitsloch in Kauf.

In aller Regel kann man davon ausgehen, dass - sofern PHP-Unterstützung generell vorhanden ist - *.php-Dateien nicht ungeparst ausgeliefert werden. Bei anderen Dateiendungen kann man das nicht voraussetzen. Und man kann auch nicht voraussetzen, dass der Anwender sich das System ordentlich konfiguriert, selbst wenn man Handlungsanweisungen dazu in die README schreibt. Wer ist nun der Böse, wenn das System leicht hackbar ist? Der Programmierer natürlich, wer sonst? Es ist hier einfach der bessere Kompromiss, die Konfigurationswerte in PHP-Dateien vorzuhalten. - Hat man die volle Kontrolle über das System und die sicherheitstechnisch-administrative Ahnung, dann sollte man das selbstverständlich ordentlich aufsetzen. Leider sind manche Anwendungen zu sehr auf die oben genannten schlechten Voraussetzugnen getrimmt und lassen sich nicht so einfach aufteilen.

Ernsthafte Dinge hostet man nicht auf Billig-Servern, in denen alles im doc root liegen muss.

Schönes Prinzip. Scheitert aber nicht selten an den unverhandelbaren Gegebenheiten.

Falls man sich aus irgendeinem Grund mal mit solchen Begebenheiten rumschlagen muss, tut man das, was in der Situation notwendig ist.
Ich halte nichts davon, zu generalisieren. Weil ein Skript laut deiner Aussage ohne jegliche Änderung auf allen erdenklichen Servern laufen sollte, sollte man auf Configs verzichten, weil die Möglichkeit besteht, dass es Server gibt, auf denen configs über HTTP auslesbar sind. Das kann doch nicht ernsthaft eine Leitlinie zum Programmieren sein.

Sehr gut, du kannst also doch situationsbedingt entscheiden und stellst die Prinzipien, egal wie gut sie unter Idealvoraussetzungen aussehen mögen, nicht über alles. Dann ist ja zumindest aus meiner Sichts noch nicht alles verloren. ;-)

dedlfix.

[M.]

kannst du bitte aufhören, mir dinge in den mund zu legen, die ich nie gesagt habe?
ich habe nirgendwo gesagt, man muss immer eine .ini verwenden.

Wieso antwortest du dann auf meinem Post, in dem ich lediglich gesagt habe, dass ini-Dateien ein Sicherheitsloch darstellen können?
Damit hast du mir, wenn du keinen Bezug zu hottis Post hast, unterstellt, ich würde keine Konfigurationsdateien nutzen, was ich aber nie gesagt habe.

(im übrigen redete er von konfigurationsdateien.
ist das so in der PHP-welt, dass man da immer gleich an .ini denkt?

Zitat von hotti:

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Liest du eigentlich die Beiträge auch? Ich habe diesen text exakt zitert und darauf geantwortet. Wenn du jetzt damit kommst, dass davon nie die Rede war, muss ich dich echt fragen ob du lesen kannst.

ich sage nur: wenn die sorge davor, dass eine config-datei über den webserver auslesbar sein könnte, der grund ist, auf configs zu verzichten bzw. davor zu warnen, dann hast du mein mitleid.

Ich sprach von einer .ini-Datei (nur falls du es immer noch nicht verstanden hast, worum es in diesem Zweig geht) und der _kann_ als Text ausgeliefert werden, wenn der Server nicht passend konfiguriert ist.
Wenn bei dir solche Bedenken Mitleid verursachen, bist du schlichtweg ein programiertechnischer Tiefflieger, denn dir ist Sicherheit völlig egal.

Was hast du denn gefrühstückt? Ich nehme überhaupt kein Sicherheitsloch in Kauf.

Nicht? Dann ist vermutlich deine Schreibe gar nicht von dir?

Und das das auch *mit* vielen Sicherheitslücken *nicht* klappt, beweisen leider auch sehr viele Programmierer. Die meisten Sicherheitslücken, dir mir so begegnen, sind aber sql-injections und XSS.

Dein eigener Code?

für dich gibt es offenbar nur schwarz und weiss. alle in einen topf werfen, die dir irgendwas entgegnen.

Ich sehe nur bei dir schwarz, denn deine Aussagen sind mehr als grenzwertig.

aha, ich bin also jemand, der aus prinzip ein Sicherheitsloch zulässt. Das schliesst du aus meinen Aussagen in diesem Thread.

Ja

Ganz ehrlich, ich würde auch nie was von dir "machen lassen".
Ernsthafte Dinge hostet man nicht auf Billig-Servern, in denen alles im doc root liegen muss.

Aha. Wenn also dein Kunde sagt, er hat einen Server, weigerst du dich, für ihn zu arbeiten, wenn der Server/Webspace nicht deinen Vorstellungen entspricht? Ja, das zeigt nochmal, welche Arbeit du lieferst. Ein guter Programmierer passt sich, soweit möglich, den gegebenheiten an und nicht die gegebenheiten müssen sich dem Programmierer anpassen.

Falls man sich aus irgendeinem Grund mal mit solchen Begebenheiten rumschlagen muss, tut man das, was in der Situation notwendig ist.

Aha, jetzt wirfst du deine gesamten Ausagen von vorher über den haufen? Sehr konsequent.

Ich halte nichts davon, zu generalisieren. Weil ein Skript laut deiner Aussage ohne jegliche Änderung auf allen erdenklichen Servern laufen sollte, sollte man auf Configs verzichten, weil die Möglichkeit besteht, dass es Server gibt, auf denen configs über HTTP auslesbar sind.

Wer, ausser dir, redet eigentlich davon, auf Configs zu verzichten?

[tinita]

Ich sprach von einer .ini-Datei (nur falls du es immer noch nicht verstanden hast, worum es in diesem Zweig geht) und der _kann_ als Text ausgeliefert werden, wenn der Server nicht passend konfiguriert ist.

Oh, das habe ich durchaus verstanden.
Es können noch viel unangenehmere Dinge passieren, wenn der Server nicht passend konfiguriert ist. Da braucht man nicht mal .ini-Dateien zu verwenden.

Und das das auch *mit* vielen Sicherheitslücken *nicht* klappt, beweisen leider auch sehr viele Programmierer. Die meisten Sicherheitslücken, dir mir so begegnen, sind aber sql-injections und XSS.

Dein eigener Code?

Ich weiss nicht, warum du es nötig hast, dich auf ein solches Niveau zu begeben.

• Ich erkläre alle Nase lang jemandem, was CSRF ist.
• Ich erkläre Leuten, warum ich gerne das Template-System so konfiguriere, dass es alles HTML-escaped, es sei denn, man wählt im Template selbst kein oder ein anderes gewünschtes Escaping. Ich habe das in mehreren Firmen eingeführt, in denen ich gearbeitet habe. Deckt den grössten Teil der möglichen Einfallstore für XSS ab.
• Ich verwende schon ewig Platzhalter in SQL-Statements.
• Wenn möglich, setze ich, wenn es um erlaubte Zeichen geht, auf Whitelists statt Blacklists.

Auch ich habe sicher schon Bugs produziert, jeder fängt ja mal an.

Und nur, weil ich "Passwörter gehören in Configs" nicht für eine echt gefährliche Pauschalaussage halte, bin ich plötzlich eine wahnsinnig schlechte Programmiererin, die Sicherheitslücken am laufenden Band erzeugt.

Weisst du, es gibt eine grosse Bandbreite von Aufträgen/Arbeitsstellen.
1. Hoster, bei denen PHP-Dateien ausgeführt werden, alles andere an den Client ausgeliefert wird. Keine Möglichkeit, das Verhalten mit .htaccess zu beeinflussen. Alles liegt im doc root.
2. Hoster wie Nummer 1, bei denen man das Verhalten einzelner Dateien mit .htaccess beeinflussen kann
3. Hoster, bei denen man Dateien ausserhalb des doc root ablegen kann
4. Hoster, bei denen ein spezielles Verzeichnis für Skripte gedacht ist und alle anderen Dateien darin weder ausgeführt noch an den Client geliefert werden
5. Hoster mit Virtual Servern, auf denen man Root-Rechte hat
6. Managed Server
7. Firmen, die Root-Server mieten, um ihre Projekte darauf laufen zu lassen
8. Firmen, die Server in einem Serverraum in ihrem Bürogebäude stehen haben
9. Firmen, die mehrere Rechenzentren - geographisch verteilt - betreiben

Meine Arbeitsstellen erstreckten sich in der Vergangenheit über die Bereiche 7-9

Ich weiss nicht, wieviele Hoster es da draussen gibt, bei denen das spezielle Problem mit der Config-Datei auftreten könnte (Nummer 1). Habe selbst wie gesagt keine Erfahrung mit Gratis-Hostern. (Gibt es tatsächlich auch Hoster, die Geld nehmen und trotzdem kein .htaccess anbieten?)
Und nur weil ich den Ratschlag "Passwörter in Configs" nicht für gefährlich halte, bekomme ich nun gleich vorgehalten, ich sei praktisch die Sicherheitslücke in Person.

Ganz ehrlich, ich würde auch nie was von dir "machen lassen".
Ernsthafte Dinge hostet man nicht auf Billig-Servern, in denen alles im doc root liegen muss.

Aha. Wenn also dein Kunde sagt, er hat einen Server, weigerst du dich, für ihn zu arbeiten, wenn der Server/Webspace nicht deinen Vorstellungen entspricht?

Wie oben beschrieben, ist das nicht mein Metier, bisher gabs immer Server(farmen) mit Root-Rechten.
Aber ja, wenn möglich für mich, weigere ich mich.

Ja, das zeigt nochmal, welche Arbeit du lieferst. Ein guter Programmierer passt sich, soweit möglich, den gegebenheiten an und nicht die gegebenheiten müssen sich dem Programmierer anpassen.

Wenn ich eine Plattform für unsicher halte und ich mich anpasse, dann bin ich gut?
Nein, dann habe ich offensichtlich nicht die Wahl eines vernünftigeren Auftraggebers. Spricht im Zweifel eher dafür, dass man schlecht ist.

Falls man sich aus irgendeinem Grund mal mit solchen Begebenheiten rumschlagen muss, tut man das, was in der Situation notwendig ist.

Aha, jetzt wirfst du deine gesamten Ausagen von vorher über den haufen? Sehr konsequent.

Inwiefern? Ich habe nicht gesagt, was ich konkret machen würde.
Die Ausnahme von der Regel ist natürlich denkbar. In der Not frisst der Teufel Fliegen. Muss jeder für sich entscheiden. Eine Regel "das gehört so" ist jedenfalls in den meisten Fällen eine Regel mit denkbaren Ausnahmen.
Ich würde das Arbeiten in solchen Umgebungen jedenfalls so weit wie möglich vermeiden.

Ich halte nichts davon, zu generalisieren. Weil ein Skript laut deiner Aussage ohne jegliche Änderung auf allen erdenklichen Servern laufen sollte, sollte man auf Configs verzichten, weil die Möglichkeit besteht, dass es Server gibt, auf denen configs über HTTP auslesbar sind.

Wer, ausser dir, redet eigentlich davon, auf Configs zu verzichten?

So habe ich dich verstanden.
Du schriebst:

Vielleicht bin ich altmodisch, aber ich bin der Meinung, Software sollte auf möglichst
vielen Serverkonfigurationen ohne Änderungen lauffähig sein.

D.h. deine Software soll auch auf dem fraglichen Server mit dem Config-Problem sicher laufen. Ergo darfst du keine configs benutzen.
Vielleicht habe ich dich auch falsch verstanden.

[M.]

D.h. deine Software soll auch auf dem fraglichen Server mit dem Config-Problem sicher laufen. Ergo darfst du keine configs benutzen.

Ich habe mich mehrfach explizit auf .ini-Dateien bezogen. _MEHRFACH_

Vielleicht habe ich dich auch falsch verstanden.

Ja

[dedlfix]

Tach!

Weisst du, es gibt eine grosse Bandbreite von Aufträgen/Arbeitsstellen.

Und nicht nur das. Es gibt auch Projekte ohne Auftraggeber und ohne dass man die Bedingungen kennt oder festlegen kann, unter denen dann diese Anwendungen laufen sollen. Projekte wie - ich hab sie schon erwähnt - WordPress oder Joomla. MediaWiki ist noch ein weiteres. Diese sind also beliebt und man muss damit rechnen, dass sie unter anderem auf Plattformen mit nur minimalen Sicherheitsansprüchen laufen. Bei denen ist das Prinzip, nicht direkt auszuliefernde Daten außerhalb des DocumentRoots zu lagen, nicht anwendbar. Ganz zu schweigen von Konfigurationen über die .htaccess. In solchen Fällen ist es sicherer, die Konfigurationsdaten in PHP-Dateien abzulegen, die (wenigstens das sollte man voraussetzen können, sonst läuft ja gleich gar nichts von der Anwendung) nur geparst ausgeliefert werden, also wenn der Programmierer es nicht ganz verhauen hat, schlimmstenfalls keine verwertbare Ausgabe liefern.

1. Hoster, bei denen PHP-Dateien ausgeführt werden, alles andere an den Client ausgeliefert wird. Keine Möglichkeit, das Verhalten mit .htaccess zu beeinflussen. Alles liegt im doc root.

Sich nun hinzustellen, dass man unter solchen Bedingungen nicht arbeiten will, kann man als hochnäsig ansehen. Natürlich kann man im direkten Kundenkontakt versuchen, bessere Bedingungen auszuhandeln, beziehungsweise den Kunden von den Vorteilen einer besseren Umgebung zu überzeugen versuchen. Doch mit Projekten wie den oben genannten geht das eben nicht. Die Anwender werden das auf den schlimmsten Möhren installieren, derer sie habhaft werden können. Die Publicity, dass reihenweise solche Installationen erfolgreich gehackt worden sind, tut dem Projekt auch dann nicht gut, wenn man Prinzipien verwendet hat, die anderswo als State of the Art gewürdigt werden.

2. Hoster wie Nummer 1, bei denen man das Verhalten einzelner Dateien mit .htaccess beeinflussen kann

Für diese Fälle kann man eine vorbereitete .htaccess mitliefern, die den Zugriff auf wichtige Bereich gleich auf der Ebene sperrt. Da man aber immer noch 1. bedienen muss, kann man schwerlich auf solche Dinge wie leere index.html oder Configs in PHP-Dateien verzichten.

3. Hoster, bei denen man Dateien ausserhalb des doc root ablegen kann

Und dann wird es schon reichlich komplex, wenn man Installationsroutinen schreiben muss, für solche Fälle, bei denen man nicht genau weiß, wie das System aussieht. Der Anwender hat vielleicht auch nicht _die_ Ahnung, welche Pfadnamen anzugeben sind. Macht man die Angelegenheit zu komplex, leidet die Popularität. Zuzuschauen, wie ein sicherheitstechnisch perfektes System bei den Anwendern nicht ankommt, weil sie es nicht zu installieren in der Lage sind, ist auch nicht gerade erbauend.

4. Hoster, bei denen ein spezielles Verzeichnis für Skripte gedacht ist und alle anderen Dateien darin weder ausgeführt noch an den Client geliefert werden
5. Hoster mit Virtual Servern, auf denen man Root-Rechte hat
6. Managed Server
7. Firmen, die Root-Server mieten, um ihre Projekte darauf laufen zu lassen
8. Firmen, die Server in einem Serverraum in ihrem Bürogebäude stehen haben
9. Firmen, die mehrere Rechenzentren - geographisch verteilt - betreiben

Das braucht mindestens Fortgeschrittene bis Profis im echten Sinne, um Software in solchen Umgebungen zu installieren. Schön, wer das ist oder auf solches Personal zugreifen kann. Nützt aber für die obigen Fälle wenig.

Meine Arbeitsstellen erstreckten sich in der Vergangenheit über die Bereiche 7-9

Man könnte nun annehmen, dass du da ein wenig betriebsblind geworden bist und andere Anwendungsfälle aus den Augen verloren hast. Aber ich möchte dir da nichts unterstellen.

Ich weiss nicht, wieviele Hoster es da draussen gibt, bei denen das spezielle Problem mit der Config-Datei auftreten könnte (Nummer 1).

Genügend.

(Gibt es tatsächlich auch Hoster, die Geld nehmen und trotzdem kein .htaccess anbieten?)

Ob da Geld hinzulegen oder Werbeeinblendungen zu ertragen sind, spielt nicht die Rolle, wenn man frei verfügbare Software erstellen will. Man muss das einfach mit einkalkulieren.

Wenn ich eine Plattform für unsicher halte und ich mich anpasse, dann bin ich gut?

Wenn du es schaffst, Software zu entwerfen, die auch auf unsicheren Plattformen eine einigermaßen sichere Figur macht (wenn das überhaupt möglich ist und kein Widerspruch in sich ist), dann bist du gut. Wenn du es nur schaffen würdest, nach Prinzipien zu arbeiten, ohne ihre Nachteile auf bestimmten potentiellen Einsatzorten zu erkennen, dann wärest du nicht gut.

Vielleicht bin ich altmodisch, aber ich bin der Meinung, Software sollte auf möglichst
vielen Serverkonfigurationen ohne Änderungen lauffähig sein.
D.h. deine Software soll auch auf dem fraglichen Server mit dem Config-Problem sicher laufen. Ergo darfst du keine configs benutzen.

In dem Fall ist es jedenfalls nicht sonderlich ratsam, kritische Konfigurationen in anderer Form als PHP-Dateien abzulegen.

Die besten Prinzipien taugen nichts, wenn man sie ungeachtet der Bedingungen der realen Welt anwendet.
Und damit möchte ich die Diskussion dann auch eigentlich abschließen, die Argumente wiederholen sich jetzt schon mehr, als dass neue Erkenntnisse hinzukommen.

dedlfix.

[tinita]

Aber ich möchte dir da nichts unterstellen.

Auf gar keinen Fall =)

[M.]

Und nicht nur das. Es gibt auch Projekte ohne Auftraggeber und ohne dass man die Bedingungen kennt oder festlegen kann, unter denen dann diese Anwendungen laufen sollen.

Ich hab ein paar Projekte, die genau darunter fallen. Z.B. ein Sendeplan für Webradios, der recht populär ist. Und genau bei vielen winzigen bis kleinen Webradios ist kostenloser Webspace angesagt.
Und genau bei solchen OpenSource-Projekte liegt der Knackpunkt. Da installieren ansolute Laien auf Servern, die nix kosten dürfen. Und diese Kombination fordert einen Programmierer IMO erst richtig.

Da programmiert man ohne Pflichtenheft (ausser dem eigenen) für "Kunden" die man nicht kennt und die meistens keine Ahnung haben (und keine README lesen (wollen/können)).

Ich bin der Meinung, grad bei OpenSource-Projekten zeigt sich die Qualität eines Programmierers. Software auf einer einzigen Plattform entwickeln, die noch seinen Vorgaben entspricht, ist keine Kunst, das schafft jeder mittelmässige Programmierer, mehrere hundert bis tausend Installationen auf verschiedenen Plattformen unter unbekannten Vorraussetzungen bei Anwendern von Dau bis Nerd, ist IMO die Königsklasse der Softwareentwicklung.

[tinita]

Ich bin der Meinung, grad bei OpenSource-Projekten zeigt sich die Qualität eines Programmierers. Software auf einer einzigen Plattform entwickeln, die noch seinen Vorgaben entspricht, ist keine Kunst, das schafft jeder mittelmässige Programmierer, mehrere hundert bis tausend Installationen auf verschiedenen Plattformen unter unbekannten Vorraussetzungen bei Anwendern von Dau bis Nerd, ist IMO die Königsklasse der Softwareentwicklung.

Das sagt jetzt doch sehr viel über dich aus.

Es mag durchaus eine Herausforderung sein, sich noch so schlechten Bedingungen anzupassen. Selbst wenn man seine eigenen Server hat, muss man sich mit manchen Gegebenheiten arrangieren, das gehört zum Programmieren dazu.

Wenn du es als die Königsklasse siehst, dann werfe ich wie dedlfix aber auch mal die Betriebsblindheit in den Raum.

Vielleicht schafft es jeder mittelmässige Programmierer, irgendeinen zu diesem Zeitpunkt funktionsfähigen Code zu produzieren.

Ein engagierter Programmierer eines nicht ganz kleinen Projektes legt Wert auf:

• Wartbarkeit (modular, sauber, lesbar) - denn der Code wird öfter gewartet und gepflegt werden als man sich das am Anfang vorstellt; sehr oft dann auch von anderen Personen
• Effizienz (Performance) - Mehr Hardware draufwerfen geht nicht bis in die Unendlichkeit, und wenn man in den Bereich kommt, mehrere Server einsetzen zu müssen, und auch nicht unbedingt die günstigeren Einsteiger-Root-Server, dann macht es schon einen Unterschied, ob ich 2 Stück oder 4 Stück miete. Und es kann auch einen entscheidenden Unterschied machen, wie lange ein Request oder ein cronjob läuft. Es gilt also ggfs., Algorithmen zu ersinnen und diese ggfs. mittels Benchmarks und Profiling an realen Daten zu überprüfen
• Speicher sparen - auch 32GB sind irgendwann mal alle. Speicher sparen und Effizienz muss man austarieren, da sie oft im Konflikt stehen. Da muss man versuchen, den Anwendungsfall realistisch einzuschätzen und danach entscheiden
• Skalierbarkeit - Was anderes als Effizienz. Geht dann auch oft in die Architektur hinein. (Ist natürlich für die Webseite des Taubenzüchtervereins von Hintertupfingen kein Thema.)

Und dass das nicht jeder mittelmässige Programmierer kann, durfte ich bei den Projekten, die ich übernommen habe, immer mal wieder erleben.
Auch bezüglich dieser Themen muss man sich ab und an mal mit den nicht idealen Gegebenheiten zufriedengeben. Magere oder praktisch ganz fehlende Pflichtenhefte sind auch in diesen Bereichen nichts Unbekanntes.

Solange wir jetzt keine - wie sagt man so schön - belastbaren Zahlen haben, mag nun jeder für sich entscheiden, was wichtiger ist. Ist es die schiere Masse der kleinen Websites, die auf ungünstig konfigurierten Servern laufen oder sind es die grossen Projekte. Vielleicht muss es ja auch keinen "Sieger" geben. (Du bist derjenige, der das Wort "König" reingebracht hat)

Plattformunabhängigkeit ist eine gute Sache. Das Wissen, wie man mit ungünstig konfigurierten Servern umgeht und Workarounds schafft, ist sicher auch nicht zu verachten.
Wenn du dieses aber als Königsklasse siehst, ist dir offenbar leider nicht bewusst, was programmieren noch so alles bedeuten kann.

Dass du das Wort Königsklasse benutzt, zeigt für mich auch noch was anderes.
Du hättest sagen können, dieser Bereich - der Umgang mit den ungünstig konfigurierten Servern - ist auch eine Kunst.
Aber "Königsklasse"? Alles andere ist ein Klacks?

[M.]

Aber "Königsklasse"? Alles andere ist ein Klacks?

Ich arbeite in Clusterumgebungen mit mehreren 100 Rechnern genauso (dann aber eher selten in PHP), wie auf nem kleinen Webspace (eben als Hobby meine OS-Projekte)

Und ja, die Konzeptionierung ist in definierten Umgebungen wesentlich einfacher (natürlich braucht die, je nach Arbeitsumfang, mehr Zeit, aber mehr Zeit heisst ja nicht, dass es komplizierter ist).

Du hast mir in diesem Thread geschrieben (ich könnte da sogar nen Vorwurf rauslesen), ich sehe nur schwarz und weiss und jetzt ist alles, was nicht die "Königsklasse" ist, ein Klacks?

Zwischen "nix dabei" und "scheisse kompliziert" gibt es für dich also nix? DAS ist schwarz/weiss-Denken. Ich hab schon Projekte umgesetzt, die hart an der Grenze zur Königsklasse schrammen, ich habe aber nicht, wie von dir behauptet, schwarz/weiss-Denken, sondern  kann ziemlich gut abstufen, welches Projekt wieviel Wissen vorraussetzt.

Was das über mich aussagt? IMO, dass ich in der Lage bin, ein kleines Projekt mit ein paar hundert Codezeilen, ebenso wie ein Grossprojekt mit mehreren hundert Programmierern (eines der grösstes kommerziellen Projekte, das ich geleitet habe, hatte ca. 200 Programmierer im Team) umsetzen kann und auf die jeweiligen Anforderungen eingehen kann.

Bei dir habe ich immer mehr den Eindruck, dass du auf eine bestimmte Art von Projekten festgefahren bist und daher Probleme hast, andere Lösungsansätze zuzulassen. Alleine schon die Aussage von dir, die ich in der ersten Zeile zitiert hab, zeigt das IMO recht deutlich.

[tinita]

Passworte, Credentials u. dgl. gehören in Konfigurationsdateien, z.B. eine ini.

Und wenn der Server die Datei nicht parst sondern als Plain ausgibt?
Dann baut dir dein "Gesetz" ein Sicherheitsloch, indem er das Passwort im Klartext anzeigt.

Solche Pauschalaussagen, ohne die Servervorrausetzungen zu kennen, sind echt gefährlich.

ich möchte hier nochmal ansetzen.

Passwörte gehören in Config-Dateien, sagt hotti.

Du sagst (so verstehe ich es), solche Pauschalaussagen sind gefährlich, weil es ja sein kann, dass das ganze auf einem Server gehostet wird, bei dem alles im doc root liegt *und* man nicht mal die Möglichkeit hat, per .htaccess zu verhindern, dass bestimmte Dateien heruntergeladen werden können. (Nochmal: mein Beileid, wenn man mit so einem Server arbeiten muss, um am Ende des Monats was zu Essen zu haben, ganz ehrlich gemeint).

Ich finde das einfach wahnsinnig albern.

Nehmen wir mal folgende Unterhaltung an:
A: Spring niemals aus dem 3. Stock eines Hauses.
B: Und wenn die Wohnung in Flammen steht, soll man sich einfach brutzeln lassen? Ich finde solche Pauschalaussagen echt gefährlich.

Ich hoffe, dass verständlich ist, was ich damit sagen will.

Das heisst: Wenn ein Ratschlag lautet, dass Passwörter in Config-Dateien gehören, und man davon ausgeht, dass das gefährlich ist, weil Leute, die keine Ahnung haben, das auf Server packen könnten, die den Download der Config erlauben, dann wäre die Konsequenz, am besten allen vom Programmieren abzuraten. Man darf doch davon ausgehen, dass man mit Leuten mit einer gewissen Intelligenz redet, die zu der Aussage "Das gehört so", wenn es die Umstände erfordern, eine Ausnahme machen.

Es ist durchaus legitim, darauf hinzuweisen, dass je nach Konfiguration die Möglichkeit besteht, dass ungewollt Dateien heruntergeladen werden können. Aber hottis Rat als gefährliche Pauschalaussage zu bezeichnen, ist wirklich albern.

Das war der Punkt, auf den ich mich bezog. Was du daraus gemacht hast und mir in den Mund gelegt hast, ist leider nur lächerlich.

[dedlfix]

Tach!

Nehmen wir mal folgende Unterhaltung an:
A: Spring niemals aus dem 3. Stock eines Hauses.
B: Und wenn die Wohnung in Flammen steht, soll man sich einfach brutzeln lassen? Ich finde solche Pauschalaussagen echt gefährlich.

Genau das ist das Prinzip an Prinzipien. Man hat eine einfache Handlungsanweisung. Und die funktioniert im Brandfall nicht mehr. Hier setzt hoffentlich der gesunde Menschenverstand ein und die Betroffenen springen trotzdem in das ausgebreitete Sprungtuch/-kissen der Feuerwehr und nicht bereits vorher auf den nackten Beton. Ob der Verstand auch mitbekommt, wenn sich beim Programmieren die Bedingungen ändern, ist nicht so leicht beantwortbar. Man hat sich ja die Prinzipien erarbeitet, um eben nicht nachdenken zu müssen. Beides widerspricht sich irgendwie. Zumindest wenn man es so extrem betrachtet, wie gern argumentiert wird. Es ist eben sehr einfach, nur einen Aspekt zu betrachten, als ständig die komplexe Welt im Hinterkopf zu behalten.

Das heisst: Wenn ein Ratschlag lautet, dass Passwörter in Config-Dateien gehören, und man davon ausgeht, dass das gefährlich ist, weil Leute, die keine Ahnung haben, das auf Server packen könnten, die den Download der Config erlauben, dann wäre die Konsequenz, am besten allen vom Programmieren abzuraten.

Nein. Der Ratschlag sollte lauten, dass man über die Möglichkeit nachdenken sollte, die Konfigurationsdaten getrennt zu notieren. Und dann sollten Eigenschaften der verschiedenen Lösungsmuster aufgezählt, sowie beleuchtet werden, in welchen Situationen sie Vorteil und wann Nachteil sind. Das ist natürlich aufwendiger als einen einfach klingenden Merksatz aufzusagen. Der Ratschlag sollte jedenfalls nicht lauten, dass es stets das beste wäre, eine Trennung vorzunehmen.

Man darf doch davon ausgehen, dass man mit Leuten mit einer gewissen Intelligenz redet, die zu der Aussage "Das gehört so", wenn es die Umstände erfordern, eine Ausnahme machen.

Das sehe ich nicht so, sonst würden manche nicht so verbissen ihre Prinzipien verteidigen.

dedlfix.

[tinita]

Wenn ich alle möglichen Dinge bedenken und aufschreiben müsste, die aufgrund einer Aussage von mir passieren könnten, würde ich gar nicht mehr auf Fragen in Foren antworten.
Es gibt da gewisse Grenzen, und desweiteren spielt das Publikum eine Rolle. (Es ging hier um einen Thread unter regelmässigen Lesern des Forums.)

Nehmen wir mal an, dass Passwort steht im PHP-Skript.
Nun wird der Server aufgrund eines Updates fälschlicherweise so konfiguriert, dass PHP-Dateien nicht mehr ausgeführt werden, sondern der Quelltext dargestellt wird. (Jaja, wir bedenken jetzt jede Möglichkeit, die Billig-Hoster habe nicht ich ins Spiel gebracht).
Blöd, jetzt ist das Passwort von jedem lesbar, bis der Hoster das gefixt hat.
Also sind Passwörter in PHP-Skripts total gefährlich.
Was nun? Nach dem, was du gesagt hast, muss man diese Möglichkeit jedem Fragesteller darlegen

Nein, also ich denke, gefährliche Pauschalaussage ist weiterhin albern, und die Argumente, mit denen du das versuchst zu verteidigen auch.
Hast du bei jeder Antwort hier im Forum immer jede Möglichkeit bedacht? Und wenn nicht, fändest du es besser, es würde dich (und den OP) höflich jemand auf eine unbedachte Möglichkeit hinweisen, oder würde es dich erfreuen, wenn du gleich eine "gefährliche Pauschalaussage" vorgeworfen bekämst?

Das ist natürlich aufwendiger als einen einfach klingenden Merksatz aufzusagen.

Jetzt ist es also sogar noch Faulheit. Also wer nicht gleich einen ganzen Roman schreibt und jede erdenkliche Möglickheit in Betracht zieht und verständlich aufschreibt, ist faul und sollte lieber gar nicht antworten.

Schreibt das am besten in die Nutzungsbedingungen vom Forum, ich möchte nicht irgendwann mal verklagt werden, weil ich jemandem zu Config-Dateien geraten habe.

[dedlfix]

Tach!

Wenn ich alle möglichen Dinge bedenken und aufschreiben müsste, die aufgrund einer Aussage von mir passieren könnten, würde ich gar nicht mehr auf Fragen in Foren antworten.
Es gibt da gewisse Grenzen, und desweiteren spielt das Publikum eine Rolle. (Es ging hier um einen Thread unter regelmässigen Lesern des Forums.)

Nicht (immer) alle Möglichkeiten aufzuzählen ist durchaus legitim. Man vergisst manche Dinge, man hat nicht immer Lust ein Riesen-Pamphlet zu schreiben, $grund3, $grund4. Aber deshalb die Aussage auf ein "So macht man das" zu reduzieren, ist auch nicht richtig. Es sollte wenigstens erwähnt oder zumindest nicht ausgeschlossen werden, dass unter anderen Umständen andere Lösungen durchaus auch ihre Berechtigung haben.

Nehmen wir mal an, dass Passwort steht im PHP-Skript.
Nun wird der Server aufgrund eines Updates fälschlicherweise so konfiguriert, dass PHP-Dateien nicht mehr ausgeführt werden, sondern der Quelltext dargestellt wird. (Jaja, wir bedenken jetzt jede Möglichkeit, die Billig-Hoster habe nicht ich ins Spiel gebracht).
Blöd, jetzt ist das Passwort von jedem lesbar, bis der Hoster das gefixt hat.
Also sind Passwörter in PHP-Skripts total gefährlich.
Was nun? Nach dem, was du gesagt hast, muss man diese Möglichkeit jedem Fragesteller darlegen

Ja, das ist eine schöne Begründung, warum man sich die Mühe machen sollte, nach einen Platz außerhalb des DocumentRoot Ausschau zu halten. Dieser Fall ist aber vermutlich selten. Deutlich öfter wird es vorkommen, dass .ini und andere Dateien nicht vom direkten Ausliefern ausgeschlossen sind. Und das sieht man nicht mal auf Anhieb, wie bei dem Konfigurationsfehler, weil man zu testen vergessen hat, ob die Datei aufrufbar ist. Dann doch lieber die config.php-Variante, wenn man nicht voraussetzen kann, dass der Server ordentlich konfiguriert ist.

Nein, also ich denke, gefährliche Pauschalaussage ist weiterhin albern, und die Argumente, mit denen du das versuchst zu verteidigen auch.

Ich sagte nur, dass die Pauschalaussage so nicht richtig ist. Ob sie gefährlich ist, habe ich nicht bewertet.

Hast du bei jeder Antwort hier im Forum immer jede Möglichkeit bedacht?

Ich versuche das zu tun. Nicht immer gelingt es mir, manchmal vergesse ich auch Dinge (zu erwähnen).

Und wenn nicht, fändest du es besser, es würde dich (und den OP) höflich jemand auf eine unbedachte Möglichkeit hinweisen, oder würde es dich erfreuen, wenn du gleich eine "gefährliche Pauschalaussage" vorgeworfen bekämst?

Ersteres. (War ich unhöflich zu hotti?) M. ist aber leider dafür bekannt, aus einfachen Aussagen recht schnell persönliche Anklagen herzuleiten. Das finde ich auch nicht gut. Besser wäre, nur die Aussage als solche zu diskutieren und das Persönlichwerden zu vermeiden. Aber ändern wird er sich vermutlich diesbezüglich nicht mehr.

Das ist natürlich aufwendiger als einen einfach klingenden Merksatz aufzusagen.
Jetzt ist es also sogar noch Faulheit. Also wer nicht gleich einen ganzen Roman schreibt und jede erdenkliche Möglickheit in Betracht zieht und verständlich aufschreibt, ist faul und sollte lieber gar nicht antworten.

Es ist leider sehr verbereitet, bei Diskussionen mit gegensätzlichen Standpunkten die Extreme hervorzuheben. Es gibt auch noch Wege zwischen ganz kurz und ganz lang.

dedlfix.

[suit]

Ersteres. (War ich unhöflich zu hotti?)

Du warst sicher nicht unhöflich zu hotti, so eine kleine Kritik muss das Boot abkönnen.

[misterunknown]

Moin,

Passwörte gehören in Config-Dateien, sagt hotti.

Also korrigiert mich, wenn ich falsch liege, aber 95% der PHP-Anwendungen, die ich benutze, benutzen PHP-Dateien als Konfiguration. Prominente Beispiele dafür sind Roundcube, Postfixadmin, MyWebSQL, Wiki-Systeme usw. Damit umgeht man ja das Problem nicht.
Und ein Passwort in eine einfache Textdatei zu schreiben, vielleicht im INI-File-Format ist doch Schwachsinn.

Grüße Marco

[dedlfix]

Tach!

Also korrigiert mich, wenn ich falsch liege, aber 95% der PHP-Anwendungen, die ich benutze, benutzen PHP-Dateien als Konfiguration. Prominente Beispiele dafür sind Roundcube, Postfixadmin, MyWebSQL, Wiki-Systeme usw.

Wie schon erwähnt, solche mehr oder weniger prominenten und öffentlichen Programme müssen auf den schlechtestmöglichen Plattformen einigermaßen sicher laufen. Das Minimum ist da, dass .php-Dateien durch den Parser und alles andere direkt ausgeliefert wird.

Und ein Passwort in eine einfache Textdatei zu schreiben, vielleicht im INI-File-Format ist doch Schwachsinn.

Für oben genannte Projektarten ist es nicht ratsam bis bedenklich, was anderes als .php zu verwenden. Aber .ini zu bearbeiten ist weniger fehleranfällig, weil das Format einfacher als die PHP-Syntax ist. Wenn man sicherstellen kann, dass man Dateien außerhalb des DocumentRoot ablegen kann oder anderweitig den Zugriff wenigstens verbieten kann, dann sind .ini oder andere Konfigurationsdateiformate ebenfalls eine Option. Abzuwägen wäre neben der Editierbarkeit durch den Administrator hier der Aufwand zur Laufzeit beim Parsens des Fremdformates gegenüber dem Parsen als PHP-Code. Vermutlich geht in den meisten Fällen beim Parsen der Unterschied im Grundrauschen unter.

dedlfix.

[Steel]

I hear ya!

[Gunnar Bittersmann]

@@suit:

nuqneH

btw: das Syntaxhighlighting ist bewusst aus.

Das war’s bei dem Entwickler^W Frickler sicher auch.

Qapla'

[hotti]

hi,

define("DB_PASS", "1$xgz7BD");

Treppenwitz: Definiere ein variables Passwort als Konstante.

Horst Witzig

[dedlfix]

Tach!

define("DB_PASS", "1$xgz7BD");
Treppenwitz: Definiere ein variables Passwort als Konstante.

Möglichkeit a) Du bist - mal wieder - auf dem falschen Damper.
Möglichkeit b) Du hast dich - mal wieder - unverständlich ausgedrückt.

Das Passwort und der Rest der Zugangsdaten sind jedenfalls innerhalb des Scripts konstante Werte.

dedlfix.

[hotti]

Packn'mers wieda ;)

Das Passwort und der Rest der Zugangsdaten sind jedenfalls innerhalb des Scripts konstante Werte.

Ok. Wenn es 'zig mal mit dem gleichen Wert abgefragt werden muss, dann lohnt es sich schon,  über den Einsatz einer Konstante nachzudenken...

Horst Konstantz

[dedlfix]

Tach!

Das Passwort und der Rest der Zugangsdaten sind jedenfalls innerhalb des Scripts konstante Werte.
Ok. Wenn es 'zig mal mit dem gleichen Wert abgefragt werden muss, dann lohnt es sich schon,  über den Einsatz einer Konstante nachzudenken...

Die Häufigkeit des Gebrauchs hat nichts mit der Entscheidung, ob eine Konstante oder eine Variable eingesetzt wird, zu tun. Wenn du so argumentierst, hätte selbst eine Variable oder ein anderswo gesetzter Konfigurationswert nur wenig Daseinsberechtigung, denn dann kann man die Zugangskennung ja gleich als Stringliteral in der Connect-Funktion einsetzen - die oftmals nur einmal vorhanden ist. Variablen oder Konstanten oder Konfigurationswerte zu definieren, selbst wenn sie nur einmal gebraucht werden, dient oft nur dem Komfort. Es ist völlig in Ordnung, eine Konstante zu verwenden.

dedlfix.

[Lispler]

Hoch!

Die Häufigkeit des Gebrauchs hat nichts mit der Entscheidung, ob eine Konstante oder eine Variable eingesetzt wird, zu tun. Wenn du so argumentierst, hätte selbst eine Variable oder ein anderswo gesetzter Konfigurationswert nur wenig Daseinsberechtigung, denn dann kann man die Zugangskennung ja gleich als Stringliteral in der Connect-Funktion einsetzen - die oftmals nur einmal vorhanden ist. Variablen oder Konstanten oder Konfigurationswerte zu definieren, selbst wenn sie nur einmal gebraucht werden, dient oft nur dem Komfort. Es ist völlig in Ordnung, eine Konstante zu verwenden.

Ich finde Konstanten generell schlecht. Gerade im Unit-Testing stören Konstanten oft nur. Besser alles per dependency injections regeln und Werte weiterreichen. Nicht umsonst verzichtet zum Beispiel Python völlig auf Konstanten.

[dedlfix]

Tach!

Ich finde Konstanten generell schlecht. Gerade im Unit-Testing stören Konstanten oft nur.

Nicht alle Projekte sind es wert, mit Unittests ausgestattet zu werden. Für die großen mag das zutreffen, da braucht man andere Kaliber, um der Komplexität Herr zu werden. Für den "Hausgebrauch" jedoch muss man sich um automatisierbare Testbarkeit kaum weniger Gedanken machen. Der Einsatz von Konstanten stört da nicht.

dedlfix.

[tinita]

define("DB_PASS", "1$xgz7BD");

Anm.: das Passwort hier ist nicht das tatsächliche, folgt aber demselben Schema. Wer findet den Fehler? btw: das Syntaxhighlighting ist bewusst aus.

Einmal mit Profis arbeiten sag' ich euch :(

Mit perl (und warnings) wär das nicht passiert ;-)

use constant DB_PASS => "1$xgz7BD";
Use of uninitialized value $xgz7BD in concatenation (.) or string at -e line 2
Name "main::xgz7BD" used only once: possible typo at -e line 2.

mit "use strict" wärs dann auch ein fehler zur compile time:
Global symbol "$xgz7BD" requires explicit package name at -e line 2

weiss nicht, wie das mit solchen schutzmechanismen in PHP ist...

[hotti]

Mit perl (und warnings) wär das nicht passiert ;-)

use constant DB_PASS => "1$xgz7BD";
Use of uninitialized value $xgz7BD in concatenation (.) or string at -e line 2
Name "main::xgz7BD" used only once: possible typo at -e line 2.

mit "use strict" wärs dann auch ein fehler zur compile time:
Global symbol "$xgz7BD" requires explicit package name at -e line 2

Passworte haben in einem Perlscript nichts zu suchen. In Dateien, wo Passworte notiert sind, gibt es weder strict noch warnings.

--Rosti

[tinita]

Passworte haben in einem Perlscript nichts zu suchen.

ach rosti, du brauchst dich in dem thread nicht zu wiederholen und mir auch nichts über passworte in skripten zu erzählen.
ich habe lediglich darauf hingewiesen, dass man immer strict und warnings benutzen sollte (oder in PHP das entsprechende).

In Dateien, wo Passworte notiert sind, gibt es weder strict noch warnings.

ach nein? dann fehlen dir noch ein paar järchen erfahrung. hab ich oft genug erlebt und das gehört wirklich zu den harmloseren dingen.

[M.]

weiss nicht, wie das mit solchen schutzmechanismen in PHP ist...

So wie es bereits weiter unten geschrieben wurde,einfach das error_reporting einschalten.

[simon]

Moin,

define("DB_PASS", "1$xgz7BD");

ist dieses Verhalten, für das automatische Ersetzen bzw. das Auflösen von Variablen innerhalb von Zeichenketten, in PHP nicht generell potentiell gefährlich? Kann man diese Funktionsweise per Konfiguration deaktivieren?

Gruß
PHP-Noob

[tinita]

define("DB_PASS", "1$xgz7BD");

ist dieses Verhalten, für das automatische Ersetzen bzw. das Auflösen von Variablen innerhalb von Zeichenketten, in PHP nicht generell potentiell gefährlich?

das kommt darauf an, wie du 'gefährlich' definierst, würde ich sagen.
an was für einen fall denkst du zum beispiel?

Kann man diese Funktionsweise per Konfiguration deaktivieren?

fände ich sehr unpraktisch, das global zu deaktivieren.
einfache anführungszeichen statt doppelte reichen ja, wie auch im thread schon gesagt wurde.

[suit]

das kommt darauf an, wie du 'gefährlich' definierst, würde ich sagen.
an was für einen fall denkst du zum beispiel?

https://forum.selfhtml.org/?t=215430&m=1475325

Hier lässt sich auch problemlos ein beliebiges Script einschleusen, welches z.B. die komplette Verzeichnisstruktur des Servers in ein Archiv verpackt und zum Download bereitsstellt oder irgend eine Shell installiert (r57 / c99 z.B.)

einfache anführungszeichen statt doppelte reichen ja, wie auch im thread schon gesagt wurde.

nein, das reicht auch nicht - wenn ein einzelnes Anführungszeichen vorkommt muss man das maskieren ;)

[tinita]

das kommt darauf an, wie du 'gefährlich' definierst, würde ich sagen.
an was für einen fall denkst du zum beispiel?

https://forum.selfhtml.org/?t=215430&m=1475325

Hier lässt sich auch problemlos ein beliebiges Script einschleusen, welches z.B. die komplette Verzeichnisstruktur des Servers in ein Archiv verpackt und zum Download bereitsstellt oder irgend eine Shell installiert (r57 / c99 z.B.)

einfache anführungszeichen statt doppelte reichen ja, wie auch im thread schon gesagt wurde.

nein, das reicht auch nicht - wenn ein einzelnes Anführungszeichen vorkommt muss man das maskieren ;)

es geht um das interpolieren von variablen innerhalb von double quotes.

du hast eine variable $x und erstellst eine variable $y, die $x enthält.

interpolation:
$y = "foo $x bar";
keine interpolation:
$y = 'foo $x bar';

ich kann da jetzt keinerlei gefahr entdecken, die von diesem code ausgeht. und ich sehe hier auch nicht, wo ich irgendwas maskieren müsste.
die reine interpolation von strings wird bei der ausführung nicht dafür sorgen, dass dir die festplatte gelöscht wird oder irgendwas.

ich zitiere nochmal:

ist dieses Verhalten, für das automatische Ersetzen bzw. das Auflösen von Variablen innerhalb von Zeichenketten, in PHP nicht generell potentiell gefährlich?

1. ich sehe keine gefahr, daher habe ich nach einem beispiel gefragt. dein beispiel zeigt nicht, inwiefern die interpolation gefährlich wäre.
2. das interpolieren verhindert man, indem man single quotes benutzt. die frage von simon war, wie man das interpolieren deaktivieren kann.

das, was du beschreibst, ist, einen beliebigen string ungeprüft (in dem fall muss man schon blind sein) in ein skript hineinzuschreiben. das ist was ganz anderes und hat nichts mit interpolation zu tun.

vielleicht sollte simon doch lieber selbst ein beispiel liefern.

[simon]

Hallo tinita,

vielleicht bin ich einfach nur zu blöd (Bitte mit den Kommentaren dazu sparsam umgehen ^^).

interpolation:
$y = "foo $x bar";

Was genau erwartest Du, das die Variable $y enthält? Ich kenne keine Programmiersprache (vielleicht ausser PHP?), die hier eine Ausnahme zur Laufzeit auslösen würde, sofern $x nicht deklariert wurde. Für einen PHP-Anfänger wie mich ist das schwer zu Verstehen, dass Zeichenketten überhaupt auf einmal anfangen Variablen aufzulösen.

Gruß simon

[tinita]

interpolation:
$y = "foo $x bar";

Was genau erwartest Du, das die Variable $y enthält?

vielleicht reden wir ja aneinander vorbei.

$x = "boo";
$y = "foo $x bar";

dann enthält $y "foo boo bar"

(wenn $x nicht deklariert/definiert wäre, nehme ich an, dass PHP wie perl einfach durch einen leerstring ersetzt und bei angeschalteten warnungen eben eine warnung ausgibt)

die frage von simon war nun, ob das nicht potentiell gefährlich ist. aber ich sehe keine gefahr, es ist nur die praktischere variante von
$y = "foo " . $x . " bar";

[dedlfix]

Tach!

define("DB_PASS", "1$xgz7BD");
ist dieses Verhalten, für das automatische Ersetzen bzw. das Auflösen von Variablen innerhalb von Zeichenketten, in PHP nicht generell potentiell gefährlich?

Nein, generell nicht. Potentiell gefährlich ist Programmieren an sich auch. Dennoch sollte und kann man es nicht meiden.

Wer PHP programmieren will und diese wesentliche Eigenschaft von PHP (Perl hat das auch) nicht kennt, hat nicht genügend Grundlagen gelernt. Jedes Anfängertutorial beschreibt diese Eigenart.

Und selbst wer programmieren kann, das aber in anderen Sprachen, und sich dann so überschätzt, die Eigenarten einer anderen Sprache nicht lernen zu müssen, ist auch nicht gerade ein Held.

Kann man diese Funktionsweise per Konfiguration deaktivieren?

Nein, das wäre auch nicht sonderlich hilfreich beim Einsatz von nicht selbst geschriebenem PHP-Code. Aber man kann die Strings in einfache Anführungszeichen setzen, wenn man die Variablenauflösung nicht braucht - hat dann aber auch keine Sequenzen wie \n.

dedlfix.