Subunternehmer des Kunden aus der Hölle

[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.