Forum gehackt über KB?

Projekte der phpBB.de-Community und Feedback zu phpBB.de.
felixx
Mitglied
Beiträge: 815
Registriert: 30.10.2004 10:09

Beitrag von felixx »

Hi,

ist es so einfach wie h-o schreibt?
Einfach die .htaccess-Datei kopieren?
Grüße
Felix
Benutzeravatar
Gumfuzi
Ehemaliges Teammitglied
Beiträge: 2454
Registriert: 26.03.2004 22:25
Wohnort: Linz, AT
Kontaktdaten:

Beitrag von Gumfuzi »

jep, probiere es aus und rufe dann eine Datei direkt auf.
IPB_Flüchtling
Mitglied
Beiträge: 1862
Registriert: 23.12.2004 22:46

Beitrag von IPB_Flüchtling »

Wüsste sehr gerne, was ein Sicherheitsexperte wie cback dazu sagt. Schaden kann die .htaccess natürlich auf keinen Fall. Ob der Schutz aber wirklich gleichwertig ist wie der von cback vorgestellte?

Mit neugierigem Gruß
IPB_Flüchtling
Benutzeravatar
cback
Mitglied
Beiträge: 386
Registriert: 18.04.2004 21:35
Wohnort: Saarland
Kontaktdaten:

Beitrag von cback »

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
  • 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
IPB_Flüchtling
Mitglied
Beiträge: 1862
Registriert: 23.12.2004 22:46

Beitrag von IPB_Flüchtling »

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
Benutzeravatar
Gumfuzi
Ehemaliges Teammitglied
Beiträge: 2454
Registriert: 26.03.2004 22:25
Wohnort: Linz, AT
Kontaktdaten:

Beitrag von Gumfuzi »

jo, habe auch doppelt gemoppelt.

Aber wie ist das bei reinen Funktionsdateien a'la functions_****.php?
Benutzeravatar
cback
Mitglied
Beiträge: 386
Registriert: 18.04.2004 21:35
Wohnort: Saarland
Kontaktdaten:

Beitrag von cback »

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.
CBACK Software
professionelles Webdesign - PHP Programmierung - Entwicklung von Modifikationen - Forensysteme
Benutzeravatar
Gumfuzi
Ehemaliges Teammitglied
Beiträge: 2454
Registriert: 26.03.2004 22:25
Wohnort: Linz, AT
Kontaktdaten:

Beitrag von Gumfuzi »

ok, danke!
fanrpg
Mitglied
Beiträge: 2909
Registriert: 13.12.2004 22:41

Beitrag von fanrpg »

An sich kann man auch register_globals entgegenwirken wenn man jede Variable vorher mit nix definiert.
also z.B

Code: Alles auswählen

$module_root_path = '';
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.
ZiMD
Mitglied
Beiträge: 5
Registriert: 07.05.2005 18:01

Beitrag von ZiMD »

Antworten

Zurück zu „Community Talk“