PHP Quellcode aus website

Wursti schrieb:
Wenn ich Zugriff auf die index.php habe

..dann kann ich alles machen, bis hin zum

print "user :".$dbuser." kennwort :".$dppasswd."<br/>";

selbst das verschlüsseln bringt letztlich wenig, weil eben die Entschlüsselungsmethoden immer auch ne Schnittstelle zu PHP haben und da kann ich immer ansetzen. Ihr diskutiert also letztlich um des Kaisers Bart, denn es gibt zwar mehrere Varianten - jedoch keine die deutlich sicherer wäre als Andere ;)
 
Einfach den Server "honeyp1" nennen und schon traut sich eh keiner mehr auf die Kiste ;)
 
Wursti schrieb:
Wenn ich Zugriff auf die index.php habe, bringt es GARNIX, wenn ich dass Kennwort mit include aus einer anderen Datei hole - denn dann lass ich mir auch die einfach anzeigen...
Diese Methode hat höchstens einen Quellcode-Stil-Charakter, aber sicher nichts mit Sicherheit zu tun

sieshte: wenn der webserver falsch konfiguriert ist, dann nützt all das schöne "was-wäre-wenn-nicht" gar nix ;)

Das problem besteht aber vielfach: die Verbindungsdaten zur (mysql)-Datenbank liegen irgendwo in einer config.php oder ähnlichen datei. Dass dann vielleicht die einzelnen Userpasses in dieser DB als MD5-Hash und piepapo abgespeichert sind, ist nett, aber für jemanden mit db-zugriff uninteressant.

Das Problem bei einem als Verchlüsselungs-string hinterlegten Passwort in einer config-Datei ist aber, dass ich ja nicht mehr vom Hash auf das ursprüngliche Passwort zurückkommen kann. Einmal verschlüsselt, kann ich nur vergleichen, ob das eingegebene, ebenso verschlüsselte Passwort gleich dem hinterlegten Passswortstring ist...

Leider ist mir persönlich keine andere als die bis dato diskutierte Methode des auslagerns un zugriffschützen von solchen Daten bekannt - ich lasse mich aber gerne beleheren...
 
Duselette schrieb:
sieshte: wenn der webserver falsch konfiguriert ist, dann nützt all das schöne "was-wäre-wenn-nicht" gar nix ;)

Das problem besteht aber vielfach: die Verbindungsdaten zur (mysql)-Datenbank liegen irgendwo in einer config.php oder ähnlichen datei. Dass dann vielleicht die einzelnen Userpasses in dieser DB als MD5-Hash und piepapo abgespeichert sind, ist nett, aber für jemanden mit db-zugriff uninteressant.

Das Problem bei einem als Verchlüsselungs-string hinterlegten Passwort in einer config-Datei ist aber, dass ich ja nicht mehr vom Hash auf das ursprüngliche Passwort zurückkommen kann. Einmal verschlüsselt, kann ich nur vergleichen, ob das eingegebene, ebenso verschlüsselte Passwort gleich dem hinterlegten Passswortstring ist...

Leider ist mir persönlich keine andere als die bis dato diskutierte Methode des auslagerns un zugriffschützen von solchen Daten bekannt - ich lasse mich aber gerne beleheren...

Einen solchen Ansatz verfolgte das (unsägliche) PHP-Nuke und speicherte die Kennwörter seiner Administratoren einwegverschlüsselt als MD5-Hash in Datenbanktabellen. Da aber keine weitere Salt-Mechanismen verwendet werden, ist das Ergebnis dieser Einwegverschlüsselung immer gleich -- auf jedem Rechner. Und dafür haben einige Verrückte so genannte »Rainbow Tables« geschaffen, Datenbanktabellen mit allen möglichen Buchstabenkombinationen (»Brute Force«), die die einwegverschlüsselten Ergebnisse enthalten. So ist diese Verschlüsselung nur dann etwas Wert, wenn ein Algorithmus wie crypt () mit Salt eingesetzt wird.
 
hossa schrieb:
Es sei denn die include Datei liegt wie schon gesagt ausserhalb des document root

Das ist schon viel Wert; wichtig auch, dass bei Standardkonfigurationen solche Header-Dateien nicht mit der Endung ".inc" benannt werden, auch wenn dies im normalen Betrieb zu keinen Probleme führt. Aber es ist schon erstaunlich, was herauskommt, wenn man bei der einen oder anderen Ego-Shoort-Clan-Site, einfach mal »/db.inc« hinter die URL setzt... *flöt* Diese purzelt dann im Klartext aus dem Browserfenster. Daher immer ».php« oder ».inc.php« o.ä. benutzen.
 
Oder, man sperrt die Include-Dateien durch einen
Eintrag in der httpd.conf gegen direktes Aufrufen.

Mir würde da sowas vorschweben:
Code:
<FilesMatch "(.*?)\.inc\.php$">
   Order allow,deny
   Deny from all
</FilesMatch>

Damit wären alle PHP-Dateien, die mit ".inc.php"
enden, gesperrt :cool:

@hille: Schön, nochmal was von dir zu lesen.... :)
 
Ja, Wege gibt es Viele! Aber sie enden eben alle mit Mechanismen im Webserver ( welche brach liegen, sobald der nicht wie vorgesehen konfiguriert ist) oder mit Verschlüsselungen, die dann enden sobald das entschlüsselte Paßwort an die DB gesendet werden muß. Da PHP eine Klartext-Datei als Quelle haben will, bleibt die Schwachstelle 2.

Ihr könnt überlegen was ihr wollt, einer der beiden Angriffspunkte wird bleiben ;)
 
moses_78 schrieb:
Oder, man sperrt die Include-Dateien durch einen
Eintrag in der httpd.conf gegen direktes Aufrufen.

Mir würde da sowas vorschweben:
Code:
<FilesMatch "(.*?)\.inc\.php$">
   Order allow,deny
   Deny from all
</FilesMatch>

Damit wären alle PHP-Dateien, die mit ".inc.php"
enden, gesperrt :cool:

@hille: Schön, nochmal was von dir zu lesen.... :)

*knicks* :D

Auch eine schöne Lösung, aber wegus hat leider recht.

Ich habe es nie ausprobiert, aber vielleicht wäre Zend Guard (aka Zend Encoder) eine Lösung.
 
dieser ist aber aber m.E. nach kostenpflichtig und wird deshalb wahrscheinlich bei GNU-( OpenSource) Projekten deshalb aussen vor bleiben. Ausserdem ist nicht überall eine nachträglich installation von den Zend Sachen möglich (gemietete Webserver etc)

Bitte hier wieder um verbesserung, bin gerade aufgestanden und habe noch keinen Kafe ;)
 
Duselette schrieb:
Bitte hier wieder um verbesserung, bin gerade aufgestanden und habe noch keinen Kafe

ts, das sind Ansprüche an die Mods ;) : *Kaffee rüberreich*
 
Noch 'ne schicke Variante: Das Passwort
in der httpd.conf als Umgebungvariable
setzten, und dann im Script per getenv()
drauf zugreifen, also so:
Code:
SetEnv "DB_PASSWD" <Passwort>
Code:
$passwd = getenv('DB_PASSWD');
 
Hilarious schrieb:
Einen solchen Ansatz verfolgte das (unsägliche) PHP-Nuke und speicherte die Kennwörter seiner Administratoren einwegverschlüsselt als MD5-Hash in Datenbanktabellen. Da aber keine weitere Salt-Mechanismen verwendet werden, ist das Ergebnis dieser Einwegverschlüsselung immer gleich -- auf jedem Rechner.
...
Das ist im Grunde keine Verschlüsselung sondern bestenfalls eine Verschleierung und dass es keine "Security by obscurity" gibt ist ja sprichwörtlich.

Wenn man bei seinem Hoster keinen Zugriff auf eine Verzeichnis außerhalb der DokumentRoot bekommt, ist IMHO auch das "cgi-bin" Verzeichnis ein sinnvoller Speicherort für Dateien mit sensiblen Daten.
Auch hier gilt natürlich wegus' Einwand, mir ist aber bisher kein Fall untergekommen, wo das falsch konfiguriert war.
 
Zurück
Oben Unten