Contenido gegen URL-Injection im Shared Hosting schützen
Hallo,
ich hätte eine Frage zu folgendem "Patch":
Vielen Dank im Voraus und viele Grüße
Walter[/code]
ich hätte eine Frage zu folgendem "Patch":
Warum trägt man das if ( $_REQUEST['cfg'] ) { exit; } nicht generell in alle Dateien ein oder an einer globalen Stelle die in alle Dateien includet wird? Oder blockiert mir dies auch gewollte Variablenübergaben? Anderseits wann übergibt man die Varibale cfg mal per GET oder POST?Habe die Lücken (hoffentlich) manuell in 4.4.5 geschlossen und in die Files:
contenido/classes/class.inuse.php
contenido/classes/class.htmlelements.php
conlib/local.php
contenido/external/frontend/news.php
contenido/includes/include.con_subnav.php (auch in 4.6.4!)
contenido/includes/include.grouprights_subnav.php (auch in 4.6.4)
contenido/includes/include.logs.php
contenido/includes/include.newsletter_edit.php
contenido/includes/include.recipients_edit.php
contenido/includes/include.right_top_blank.php (auch in 4.6.4)
contenido/includes/include.rights_subnav.php (auch in 4.6.4)
contenido/includes/include.subnav.php (auch in 4.6.4)
contenido/includes/include.tpl_subnav.php (auch in 4.6.4)
contenido/includes/pseudo-cron.inc.php (indirekt über crontab.txt?, auch in 4.6.4)
mit dem einfachen Eintrag in den jeweils ersten Zeilen:
Code:
if ( $_REQUEST['cfg'] ) { exit; } // workaround remote hacking exploit
Vielen Dank im Voraus und viele Grüße
Walter[/code]
-
- Beiträge: 967
- Registriert: Do 15. Apr 2004, 17:12
- Wohnort: Eschborn-Niederhöchstadt
- Kontaktdaten:
Grundsätzlich: Es gibt einige Dateien, die als so genannte "Einsteigsseiten" fungieren, d. h. wenn man sie manuell aufruft, kann man manipulierte Variablen übergeben. Diese Dateien werden zukünftig auch über eine Standard-Methode überprüft.
"Wann übergibt man die Variable cfg mal per GET oder POST?"
Sicherheit ist keine Frage der Praxis, sondern der Theorie. Fakt ist: Man kann die Variable "cfg" über GET übergeben - und deshalb muss sie überprüft werden.
"Wann übergibt man die Variable cfg mal per GET oder POST?"
Sicherheit ist keine Frage der Praxis, sondern der Theorie. Fakt ist: Man kann die Variable "cfg" über GET übergeben - und deshalb muss sie überprüft werden.
Erst mal danke für die schnelle Antwort.
Hier haben wir uns mißverstanden:
Also nicht nur in den aufgelisteten Dateien sondern in jeder?
Konkretes Beispiel:
Patch in die besagten Dateien eingespielt -> eine andere Datei gehackt.
Danke und viele Grüße
Walter
Hier haben wir uns mißverstanden:
Dies ist mir klar. Nur könnte ich nicht generell mit if ( $_REQUEST['cfg'] ) { exit; } überprüfen ob per GET, POST usw. eine Variable "cfg" in einer beliebigen Datei eingeschleust wird?"Wann übergibt man die Variable cfg mal per GET oder POST?"
Sicherheit ist keine Frage der Praxis, sondern der Theorie. Fakt ist: Man kann die Variable "cfg" über GET übergeben - und deshalb muss sie überprüft werden.
Also nicht nur in den aufgelisteten Dateien sondern in jeder?
Konkretes Beispiel:
Patch in die besagten Dateien eingespielt -> eine andere Datei gehackt.
Danke und viele Grüße
Walter
-
- Beiträge: 967
- Registriert: Do 15. Apr 2004, 17:12
- Wohnort: Eschborn-Niederhöchstadt
- Kontaktdaten:
Mit $_REQUEST hast du alle Typen eingeschlossen, also: GET, POST, FILES... Prinzipiell schließt du damit nur Manipulationen in der jwg. Datei aus, da du, wenn du eine includierte Datei manuell aufrust, ja den Aufruf nicht implementiert hast. Da gebe ich dir Recht. Das Problem tritt also eigentlich in jeder Datei auf, dazu ist jedoch zu bemerken:
- Besteht eine Datei lediglich aus einer Klasse, also es findet kein normaler Aufruf statt, ist sie bei einem manuellen Aufruf ungefährlich
- Kommt gleich am Anfang etwas á la cInclude(), plugin_include() oder ein sonst nicht standardmäßig von PHP implementierter Aufruf vor, bricht das Skript bei einem manuellen Aufruf ab, eine Manipulation ist ergo nicht möglich
-
- Beiträge: 967
- Registriert: Do 15. Apr 2004, 17:12
- Wohnort: Eschborn-Niederhöchstadt
- Kontaktdaten:
Zunächst vielen Dank an woldini. Hat mir sehr viel gebracht.
Ergänzung zu Punkt 1 - Test, ob Seite sicher:
Meine Seite wurde über contenido/includes/include.newsletter_jobs_subnav.php gehackt. Der Provider Profihost hat sofort den account gesperrt. Im Verzeichnis contenido/includes wurde aber bereits vom Angreifer eine Datei installiert. Über Virenprogramm gefunden.
Nun zur eigentlichen Ergänzung:
Hier die Aussage des Providers: "Wenn Sie einen eigenen Angriff auf Ihre Webseite durchführen, erkennt unser System diesen automatisch und teilt uns per Email mit."
Dann wird mir die Seite also sofort wieder gesperrt.
Profihost (sehr guter service, fast immer sofortige Antwort auf Anfragen) bietet mir allerdings an, trotzdem testen zu können. Vorgang will ich allerdings hier nicht posten aus Sicherheitsgründen.
Über die php.ini kann ich übrigens bei Profihost folgende Einstellungen vornehmen:
Wichtig:
Alle Einstellungsoptionen, die Ausführungzeiten und Memorylimits betreffen, lassen sich nicht abändern. Um die Sicherheit auf dem Account zu verbessern, sollten folgende Einstellungen gesetzt werden (falls eingesetzte Skripte nicht explizit eine andere Einstellung brauchen):
register_globals = Off
allow_url_fopen = Off
display_errors = Off
Da habe ich offensichtlich einen sehr guten Provider gefunden (hat mir vor einigen Jahren mal Halchteranerin vorgeschlagen. Danke)
Gruß
Mc
Ergänzung zu Punkt 1 - Test, ob Seite sicher:
Meine Seite wurde über contenido/includes/include.newsletter_jobs_subnav.php gehackt. Der Provider Profihost hat sofort den account gesperrt. Im Verzeichnis contenido/includes wurde aber bereits vom Angreifer eine Datei installiert. Über Virenprogramm gefunden.
Nun zur eigentlichen Ergänzung:
Hier die Aussage des Providers: "Wenn Sie einen eigenen Angriff auf Ihre Webseite durchführen, erkennt unser System diesen automatisch und teilt uns per Email mit."
Dann wird mir die Seite also sofort wieder gesperrt.
Profihost (sehr guter service, fast immer sofortige Antwort auf Anfragen) bietet mir allerdings an, trotzdem testen zu können. Vorgang will ich allerdings hier nicht posten aus Sicherheitsgründen.
Über die php.ini kann ich übrigens bei Profihost folgende Einstellungen vornehmen:
Wichtig:
Alle Einstellungsoptionen, die Ausführungzeiten und Memorylimits betreffen, lassen sich nicht abändern. Um die Sicherheit auf dem Account zu verbessern, sollten folgende Einstellungen gesetzt werden (falls eingesetzte Skripte nicht explizit eine andere Einstellung brauchen):
register_globals = Off
allow_url_fopen = Off
display_errors = Off
Da habe ich offensichtlich einen sehr guten Provider gefunden (hat mir vor einigen Jahren mal Halchteranerin vorgeschlagen. Danke)
Gruß
Mc
Noch zwei Fragen an woldini:
1.
2.
3. Bringt dies zusätzlichen Schutz, wenn beim Provider allow_url_fopen = Off eingestellt ist?
Danke
Gruß
Mc
1.
Wie kann ich das überprüfen?Macht dies aber erst nachdem ihr sicher gestellt habt, dass eure Datenbank nicht vom Angriff betroffen war.
2.
Bringt die Fleißarbeit etwas?zu a):
Als erste Maßnahme bittet euren Provider in der VirtualHost-Konfiguration eurer Domain die PHP-Direktive: php_admin_value allow_url_fopen auf "off" zu setzen. Wenn er das machen kann, dann sind die nachfolgenden Schritte unter b.) in gewissem Umfang Fleißarbeit.
1. habe ich gemacht auf 4.8.6; ModRewrite fehlt noch1. Ihr fahrt ein Update auf eine neuere Version (4.6.) inkl. ModRewrite - Bundle,
2. Ihr seid gute Entwickler und schreibt ein PHP-Script, das fremde URLs nicht zuläßt und baut es in Contenido an die entsprechenden Stellen ein.
3. Ihr schützt den Webspace und Contenido mit Hilfe von .htaccess-Datei(en).
3. Bringt dies zusätzlichen Schutz, wenn beim Provider allow_url_fopen = Off eingestellt ist?
Danke
Gruß
Mc