Forum gehackt über KB?
-
- Mitglied
- Beiträge: 1862
- Registriert: 23.12.2004 22:46
Die Antwort lautet jein. 
Also ich hole mal etwas weiter aus: Zuerst einmal der Schutz per .htaccess dient dazu, dass von außen kein Zugriff auf diese Dateien mehr erfolgen kann. Damit werden existierende Sicherheitslücken daran gehindert, dass man sie ausnutzen kann. Gleiches passiert, wenn in der php.ini einfach der Wert "Register Globals" auf "off" gesetzt wird. Hier können dann zwar die Dateien weiterhin von Extern angegriffen werden, jedoch werden per URL übergebene Variablen darin nicht verarbeitet, was also bestehende Lücken ebenfalls unbrauchbar für Cracker macht. Der Effekt der Sicherheitsvorkehrungen ist also bei allen 3 Verfahren der selbe.
Aber...
... der Gedanke von weiternutzung von Code oder möglichen Boardumzügen, änderungen an Serversoftware etc. ist natürlich bei einem programmierer weiter im Hinterkopf. Die Schutzmaßnahmen per .htaccess und Register Globals = off sind sozusagen eine Käseglocke, die über die Sicherheitslücke gedeckt wird. Die Lücke selbst bleibt dabei bestehen, man hintert also nur andere daran diese auch wirklich auszunutzen. Das beschriebene Verfahren mit der Konstantenprüfung ist zwar in der Ausführung wesentlich aufwendiger, jedoch werden die Sicherheitslücken damit "an der Wurzel" angepackt und direkt dort beseitigt. So ist man auf jeden Fall auf der sicheren Seite, da man die Software bzw. die Modifikationen an der Software selbst wieder abgesichert hat. Wendet man nun auch die "Käseglocken" Verfahren an, so hat man doppelten Schutz, ist aber trotzdem weiterhin nicht angreifbar, da die Dateien selbst nochmals abgesichert wurden.
Ansonsten bestehen diverse Risiken wie man die ansonsten nur "vertuschte" Lücke wieder ausnutzen kann:
.htaccess
REGISTER GLOBALS = off
Wenn man die Skriptdateien also mit der Konstantenprüfung (if(!defined...) abgesichert hat, so können auch die anderweitig vorgeschlagenen Sicherheitsvorkehrungen getrost "ausfallen" (z.B. durch versehentliches löschen oder Umzüge) ohne das man dann wieder ein angreifbares Board vorliegen hat.
Ich hoffe ich konnte ausführlich auf die Pros und Contras eingehen und diese näher erläutern. Also meine Empfehlung ist auf jeden Fall, auch wenn .htaccess bzw. Reg. Globals = off genutzt wird auch die eigentlichen Dateien abzusichern und bei allen künftigen Modifikationen darauf zu achten, dass diese 4 Zeilen Code wirklich enthalten sind.

Also ich hole mal etwas weiter aus: Zuerst einmal der Schutz per .htaccess dient dazu, dass von außen kein Zugriff auf diese Dateien mehr erfolgen kann. Damit werden existierende Sicherheitslücken daran gehindert, dass man sie ausnutzen kann. Gleiches passiert, wenn in der php.ini einfach der Wert "Register Globals" auf "off" gesetzt wird. Hier können dann zwar die Dateien weiterhin von Extern angegriffen werden, jedoch werden per URL übergebene Variablen darin nicht verarbeitet, was also bestehende Lücken ebenfalls unbrauchbar für Cracker macht. Der Effekt der Sicherheitsvorkehrungen ist also bei allen 3 Verfahren der selbe.
Aber...
... der Gedanke von weiternutzung von Code oder möglichen Boardumzügen, änderungen an Serversoftware etc. ist natürlich bei einem programmierer weiter im Hinterkopf. Die Schutzmaßnahmen per .htaccess und Register Globals = off sind sozusagen eine Käseglocke, die über die Sicherheitslücke gedeckt wird. Die Lücke selbst bleibt dabei bestehen, man hintert also nur andere daran diese auch wirklich auszunutzen. Das beschriebene Verfahren mit der Konstantenprüfung ist zwar in der Ausführung wesentlich aufwendiger, jedoch werden die Sicherheitslücken damit "an der Wurzel" angepackt und direkt dort beseitigt. So ist man auf jeden Fall auf der sicheren Seite, da man die Software bzw. die Modifikationen an der Software selbst wieder abgesichert hat. Wendet man nun auch die "Käseglocken" Verfahren an, so hat man doppelten Schutz, ist aber trotzdem weiterhin nicht angreifbar, da die Dateien selbst nochmals abgesichert wurden.
Ansonsten bestehen diverse Risiken wie man die ansonsten nur "vertuschte" Lücke wieder ausnutzen kann:
.htaccess
- könnte versehentlich gelöscht werden
- bei Hostern die .htaccess nicht zulassen ist die Vorkehrung nicht brauchbar
- bei Serverumzug kann u.U. vergessen werden die .htaccess wieder einzurichten
- Server Configurationssoftware überschreibt die sicherheitsrelevanten dinge der .htaccess (z.B. wenn ErrorDocument Handling per Confixx definiert wird)
REGISTER GLOBALS = off
- Umzug auf einen Server mit Globals ON Konfiguration
- PHP Software wird aktualisiert, Standardkonfiguration wird überschrieben
Wenn man die Skriptdateien also mit der Konstantenprüfung (if(!defined...) abgesichert hat, so können auch die anderweitig vorgeschlagenen Sicherheitsvorkehrungen getrost "ausfallen" (z.B. durch versehentliches löschen oder Umzüge) ohne das man dann wieder ein angreifbares Board vorliegen hat.
Ich hoffe ich konnte ausführlich auf die Pros und Contras eingehen und diese näher erläutern. Also meine Empfehlung ist auf jeden Fall, auch wenn .htaccess bzw. Reg. Globals = off genutzt wird auch die eigentlichen Dateien abzusichern und bei allen künftigen Modifikationen darauf zu achten, dass diese 4 Zeilen Code wirklich enthalten sind.

CBACK Software
professionelles Webdesign - PHP Programmierung - Entwicklung von Modifikationen - Forensysteme
professionelles Webdesign - PHP Programmierung - Entwicklung von Modifikationen - Forensysteme
-
- Mitglied
- Beiträge: 1862
- Registriert: 23.12.2004 22:46
Ahoi cback,
vielen Dank für die Ausführungen!
Ich persönlich verfahre einfach nach dem Prinzip "doppelt gemoppelt hält besser": Die paar Zeilen if(!defined.... hinzuzufügen, sollte ja wirklich nicht die unüberwindbare Hürde darstellen. Zusätzlich noch die oben vorgestellte .htaccess-Lösung, und dann sollte es vorerst wieder passen. Und bei Dateien, die nicht das phpBB-CrackerTracker-Schutzsystem einbinden, includiere ich überdies noch die CT-Standalone-Variante (Link in einem meiner obigen Postings).
Also auf in die nächste Runde!
LG, IPB_Flüchtling
vielen Dank für die Ausführungen!
Ich persönlich verfahre einfach nach dem Prinzip "doppelt gemoppelt hält besser": Die paar Zeilen if(!defined.... hinzuzufügen, sollte ja wirklich nicht die unüberwindbare Hürde darstellen. Zusätzlich noch die oben vorgestellte .htaccess-Lösung, und dann sollte es vorerst wieder passen. Und bei Dateien, die nicht das phpBB-CrackerTracker-Schutzsystem einbinden, includiere ich überdies noch die CT-Standalone-Variante (Link in einem meiner obigen Postings).
Also auf in die nächste Runde!
LG, IPB_Flüchtling
Normal ist es hierbei nicht erforderlich. Die phpBB Group selbst hat diese Dateien nicht mal damit ausgestattet. Aus Sicherheitsgründen ist allerdings bei mir im Orion auch in den Dateien die nur aus functions bestehen diese Prüfung drin. Passiert ja schnell mal, dass ein mod u.U. Code außerhalb von funktionen einfügt, der angreifbar ist. Wenn dann die Prüfung drin ist geht das nicht auf die Performance, aber es ist sozusagen ein Doppelter Boden. 
Habe auch die Dateien wie emailer.php, smtp.php, templates.php,... mit der Prüfung ausgestattet, funktioniert auch ohne Probleme.

Habe auch die Dateien wie emailer.php, smtp.php, templates.php,... mit der Prüfung ausgestattet, funktioniert auch ohne Probleme.
CBACK Software
professionelles Webdesign - PHP Programmierung - Entwicklung von Modifikationen - Forensysteme
professionelles Webdesign - PHP Programmierung - Entwicklung von Modifikationen - Forensysteme
An sich kann man auch register_globals entgegenwirken wenn man jede Variable vorher mit nix definiert.
also z.B
Dann wird das was per register_globals übergeben einfach überschrieben.
Das ist auch eine effektive Möglichkeit bei sensiblen Variabeln sich davor zu schützen.
also z.B
Code: Alles auswählen
$module_root_path = '';
Das ist auch eine effektive Möglichkeit bei sensiblen Variabeln sich davor zu schützen.