Für die config.php würde das bedeuten, dass sie ausserhalb des DocumentRoot liegen müsste, damit man nicht mehr direkt darauf zugreifen kann. Ebenso das /temp Verzeichnis.
Und hierbei geraten wir in teils heftige Schwulitäten..

Die Core-Anpassung wäre prinzipiell eine Kleinigkeit. Das Hauptproblem sind die x hoch n unterschiedlichen Konfigurationen der einzelnen Webspaces.
Bei meinen Servern kein Problem, die sind passend konfiguriert. Bei Hostingpaketen "von der Stange" jedoch ist meist DocumentRoot schlicht die Root des Webspaces und Zugriffe auf darüberliegende Verzeichnisse sind durch den Server unterbunden. Grund: dadurch könnte man bei Shared-Hostings u.U. recht einfach auf die Verzeichnisse eines benachbarten Paketes zugreifen und dessen Daten manipulieren.
Ein sehr vereinfachtes Beispiel von vielen:
Der allgemeine Pfad zur DocumentRoot eines Hosting lautet:
/var/www/meine.domain/httpdocs/zu einem anderen Hosting dann:
/var/www/andere.domain/httpdocs/Ist der Server jetzt ungesichert, kann mit PHP z.B. durch
include WB_PATH.'/../../andere.domain/httpdocs/wb/config.php'; problemlos auf die Einstellungen einer völlig fremden Domain zugegriffen werden. (dieser Code könnte übrigens von jedem der das Code oder Code2 Modul bedienen darf eingegeben werden... oder in die index.php eines Templates einbauen.. oder oder..)
Aus diesem Grund sind fast alle Webspaces so abgesichert, dass keine Cross-Domain-Aufrufe erfolgen können. (was früher mit PHP als Apache-Modul noch sehr häufig passieren konnte)
Gut, selbstverständlich gibt es aber Möglichkeiten, die config.php entsprechend auszulagern. Nur benötigt man da meist auch Root-Zugriff auf den Server um Softlinks in ein übergeordnetes Verzeichnis anzulegen, in dem die config dann abgelegt wird. Apache kann dann zwar darauf zugreifen, jedoch ist kein Deeplink per http:// mehr möglich.
Also optimal? Definitiv nein! Denn damit wird WB auf fast allen Shared-Hostings mangels Zugriffsrechten nicht mehr installierbar.
Die config irgendwo zwischen den anderen Dateien "verstecken"? Das selbe Problem. Ein Lösungsansatz wäre, die Datei nicht mehr als PHP-Datei zu includen, sondern als z.B. ini-Datei einzulesen. Aber sie würde immer noch irgendwo stecken, wo sie direkt aufgerufen werden kann. Wo sie steckt (noch so gut versteckt), ist Minutensache, das herauszufinden. Schließlich ist WB ein OpenSource-Projekt und JEDER kann sich den Code runterladen und einfach mal nachschauen.
Die sicherste Lösung ist immer noch: Den Server gut pflegen und überwachen, damit der Interpreter gleich gar nicht erst ausfällt. Und DIESE Arbeit können wir weder dem Anwender noch dem Hoster abnehmen.
Das fällt eindeutig unter die Rubrik "Eigenverantwortung"Manuela