Forum

sorry ich verstehe nicht jetzt mal unabhänig von der URL Codierung was soll mr dein Beispiel sagen bzw. Wieso verhält er sich da deiner Meinung nach falsch.

Du willst da fremden Code einschleusen? Nach mal. Ich verstehe nicht was da die Lücke sein soll. Bis jetzt hast du das Modul nur auf gerufen und sollst was schreiben. Ich vermute du willst die Variable op angreifen. Versuch es. Versuch irgendwas zu übergeben was auch immer.

Hallo Stefan,

Wenn du dann auch noch die URL Codierung an hast werden die Variablen auch noch mit einem Code Verschlüsselt. Dieser Code kann auch je Stufe noch mal Zufallskomponenten enthalten. Dann hast du noch schlechtere Karten da was auszurichten.

Wenn das so wäre mit der Verschlüsselung?! Dann bringt Sie leider nicht viel. Warum kann ich anhand eines simplen Beispiel geben. Achte bitte darauf, dass du die Verschlüsselung aktiviert hast. Ruf doch mal ein installiertes Modul z.B. das "Mein Gästebuch" (myguestbook) per direkt Link auf. z.B. auf http://www.openphpnuke.info/modules/myguestbook/index.php?op=addguest

Evtl. kann der Angreifer auch so das Gästebuch manipulieren bzw. jedes andere unsichere Modul.

Es wird noch nicht mal in der "mainfile.php" überprüft, ob die Verschlüsselung aktiviert ist???? Das ist mehr als bedenklich. Daher stufe ich es als ein Sicherheitsrisiko ein.

Ihr müsst da den Kontroll-Code nochmal überarbeiten. Es ist noch nicht sicher genug. OPN muss überprüfen, dass die Variable "OPNPARAMS" nicht leer sein darf. Da wir ja in OPN eingestellt haben, dass die Übergabe-Parameter verschlüsselt werden

Gruß

Sebastian

nein das ist hier etwas anders ich verstehe zwar den

"So wie ich sehe, dürfen alle auf sämtliche Skripte von OPN ausführen"

nicht ganz bzw. kann ich mir denken was du meinst wenn ich weiß das du von Nuke her kommst

In die Sicherheit wird und wurde viel Arbeit gesteckt solltest du wirklich eine Lücke finden viel Spaß beim suchen

Das Konzept ist hier anderes als bei Nuke. Wenn da überhaupt ein Konzept ist.

Vor ab die Sicherheitsstufe ist anpassbar im Admin. Ausgehend davon dass keiner ein FTP Zugang hat und User oder Unsichere Kameraden keine Anypage Seite erstellen dürfen und PHP Side / Centerbox sowie das Modul webdir unzugänglich ist (evt. noch noch bei den Makros die aber noch von anderen dingen abhängen) sollte es Sicher sein.

Zum Konzept

mainfile.php wird immer geholt das läst sich auch so nicht umgehen da dieses das erste ist was getan wird. Bei scripten die erst später bzw. nicht direkt startbar sind wird auch dieses geprüft und sofern nicht die()

die mainfile holt die master.php hier wäre ein Ansatzpunkt du müsstest zusehen ne eigene master.php von woanders zu holen. Praktisch würde das nur über z.b. "REGISTER_GLOBALS" gehen nur dumm wir nutzen keine "REGISTER_GLOBALS" und schecken die Variablen (komm ich noch zu) also eigentlich dürftest du nix eigenes einbinden können (master.php) so die ist jetzt gelesen und testet auch noch mal ne paar Sachen

(bin ich wirklich hier / wo komm ich her usw..)

Gehen wir mal davon aus bis hierhin ist das script durch. Nun kommt der Rest des -Modules- wir wurden Werte übergeben (vom User) POST / GET Variablen

Das ist der Typische Ansatzpunkt für die verschieden –Angriffe-

Bei uns wird jede Variable gesäubert und auf den Wertebereich glatt gebügelt. Also z.b. erwarten wir ein INT dann holt die Funktion GetVar auch nur ein Integer egal was du da übergeben hast und wie. Suchfelder werden noch mal gesondert behandelt.

Wenn du dann auch noch die URL Codierung an hast werden die Variablen auch noch mit einem Code Verschlüsselt. Dieser Code kann auch je Stufe noch mal Zufallskomponenten enthalten. Dann hast du noch schlechtere Karten da was auszurichten.

Aber vielleicht ist mir nicht klar was genau du meinst. Bzw. wie du den schadhaften Code einschleusen willst. Das das ein Modul auch auf den Code von anderen Modulen zugreifen darf, ist ja grundsätzlich nicht gefährlich. Im gegenteil das ist bei einem Plugin Konzept ja nötig da jedes Modul die Fähigkeiten eines anderen Modules nutzen soll.

Wie gesagt wenn jemand ne FTP Zugang hat naja da kann man nix machen.

Hallo OPN-Team,

heute bin ich aber fleißig. Ich habe mir mal den Trunk-Code angeschaut. Es gibt ein potenzielles Sicherheitsleck. Es kann dadurch das gesamte OPN-Portal manipuliert werden.

Daher macht es mich doch etwas stutzig?! So wie ich sehe, dürfen alle auf sämtliche Skripte von OPN ausführen. Die PHP-Einstellung "REGISTER_GLOBALS" spielt hier keine Rolle. Das ist ziemlich gefährlich.


Daher möchte ich folgenden Vorschlag machen:

Ich würde die Ausführbarkeit der eingebundenen Skripte auf die jeweiligen Hauptskripte festlegen. Diesen nachfolgenden Code fügt Ihr in allen PHP-Skripten ein, somit dürfen nur "INDEX.PHP" und "ADMIN.PHP" die nachfolgenden eingebundenen Skripte starten. Bei direkt Zugriff auf die Unterseite wird der "HACKER" oder das Schadprogramm vom Server auf die Startseite umgeleitet. Somit minimiert man deutlich das Risiko, dass das System gehackt werden kann. (Ich weiß, das es bei derzeitigen Code-Umfang sehr viel Arbeit ist.) Nicht desto trotz ist die Sicherheit für den Webmaster das höchste Gebot.

Wenn ihr dabei Hilfe braucht, so lasst es mich wissen. Ich helfe gerne.

Beispiel-Code:

if (!eregi('index.php', $_SERVER['PHP_SELF']) and !eregi('admin.php', $_SERVER['PHP_SELF'])) {
header('Location: http://www.openphpnuke.info/index.php');
exit;
}


Nun, werde ich den Trunk-Code weiter analysieren. Evtl. werde ich noch weitere "Sicherheitslücken" finden.

Gruß

Sebastian

[ Diese Nachricht wurde bearbeitet von: Freespacer am 03.10.2006 18:57 (Originaldatum 03.10.2006 18:3 ]

[ Diese Nachricht wurde bearbeitet von: Freespacer am 03.10.2006 19:00 (Originaldatum 03.10.2006 18:38) ]