Wenn du das im Browser eingibst kommt das nicht auf dem Server an. Du machst irgendetwas merkwürdiges, deine Beobachtungen können so nicht stimmen.

Wenn du dagegen das Zeichen URL-kodiert hast (%23) dann ist es kein besonders Zeichen und muss auch nicht besonders behandelt werden, es sei denn du übergibst es an eine Anwendung, die damit irgendetwas spezielles macht. Aber einen 404'er Fehler sollte das auf keinen Fall hervorrufen.

Die URL an sich, macht das in keinem Fall. Das kommt von deiner Anwendung, diese enthält Fehler aber die Anzeige der Fehlermeldmungen ist deaktiviert. Das im IIS HTML Code ankommt, kann mit einer internen Konfiguration zusammenhängen, dass der Server auf jeden Fall Code schickt auch wenn deine Anwendung abschmiert, wie in diesem Fall.

Ich würde zum einen mal testen ob wirklikch Fehler angezeigt werden, das hatte ich dir aber schon zweimal gesagt. Daneben kannst du natürlich auch einen Blick in die Fehlerlogs werfen, dort sollten auch mehr Infos stehen.

Ich melde mich am CMS an, die URL ist dann "/rev37/admin/main.php" und ich bleibe dort.
Dann kopiere ich aus meinem Texteditor die vorgefertigten URLs mit Nullbytes, sinnlosen Texten und nicht erreichbare Panels. Der Browser lädt die vorgefertigte URL (zum Beispiel das Papierkorb Management Seite), geht sowas bei dir nicht?

Nebenbei, ich habe auch einige PHP-Scripte, die das für mich tun. Zum Beispiel ein unvollständiger Aufruf des Papierkorbs im Admin Interface:
Wenn man in der URL ein Nullbyte hat wird alles ab der Stelle wo das Nullbtye eingegeben ignoriert. Also hat man keine vollständige URL mehr. Wieso dann kein 404er?

Welcher IIS? Windows Server 2012 R2 und Apache 2.4. Auf dem Testserver ist IIS nicht installiert.

An den Windows Servern kann ich das, bei den Providern ist mir das leider untersagt.

Und error_reporting(E_ALL) funktioniert, getestet auf den Servern von Windows und Providern.

__________________
Personal stuff

Du sprichst höchstwahrscheinlich von URL-Kodierte Strings. Denn wenn du #00 eintippst, wird das von keinem Browser übertragen.

Dann läuft in deiner Anwendung etwas falsch. PHP konvertiert den Code ohne Probleme, die Stelle mit einer kodierten Null (also %00) wird nicht ignoriert sondern brav in den String eingetragen und auch alle darauf folgenden Zeichen.


Ich bitte dich noch mal, baue ein kleines Skript und teste ob Fehler angezeigt werden. Diese Einstellung allein reicht oft nicht aus.

Was gibt diese Skript aus?

Ach so, wir reden von URL Parametern, oder?
Wenn du eine ungültigen URL eingibst, dann ist ein 404'er Fehler natürlich richtig, aber das ist nicht unbedingt Aufgabe der Anwendung und es spielt keine Rolle, was für ein Art von Zeichen das sind.

Ich meine so was. Da kommt alles nach dem %00 ohne Probleme im Skript an.

Als .html gespeichert nichts
Als .php gespeichert = Fatal error: Call to undefined function bla() in ../rev37/admin/test.php on line 11

__________________
Personal stuff

Das tut's bei mir z.b. nicht. Ich muss zuerst das einfügen: ini_set("display_errors", 1);

und was passiert jetzt:

als .html gespeichert nichts
als .php gespeichert = Parse error: syntax error, unexpected '1' (T_LNUMBER), expecting variable (T_VARIABLE) or '$' in ../rev37/admin/test1.php on line 2

Ich studiere gerade: http://projects.webappsec.org/w/page...te%20Injection
und das hier: http://www.exploit-db.com/papers/15108/
und das hier: http://stackoverflow.com/questions/1...ding-using-php

__________________
Personal stuff

OK. Dann kann die weisse Seite nur aus deiner Anwendung kommen, d.h. du brichst das Skript ab ohne das irgendeine Ausgabe erfolgt.

Das ist eine sehr spezielle Lücke und noch nicht mal sonderlich spektakulär.
Darüber hinaus ist es nur eine Lücke, wenn du einen Dateinamen dynamisch aus dem Userinput zusammenbaust, der dann noch zufällig Bestandteil einer wichtigen Systemdatei ist. Kommt das bei dir vor?

Wobei das Nulbyte in den Beispielen noch nicht mal das Problem ist, das Problem ist das die beschrieben Szenarien der absolute Horror sind, da sie dem User erlauben Dateien aus irgendwelchen Pfaden einzubinden. Wer so was programmiert, hat kein Problem mit einem Nullbyte, der sollte die Finger an sich von der Webprogrammierung lassen. Wie z.b. der stackoverflow Fragesteller

Da das error_reporting(E_ALL) jetzt gelöst ist, habe ich beschlossen mein CMS in "Der Fehler liegt in der Anwendung" umzutaufen

Vorher schreibe ich aber ein Debugscript und werde diverse Browser darauf loslassen um eine mögliche Fehlerquelle zu ermitteln. Ab jetzt mache ich wieder die "try, catch and error" Methode. Müsste doch zu lösen sein.

Das CMS schaut in einem Index nach ob die vom Browser angeforderte Inhaltsseite dort enthalten ist. Wenn nein, dann Pech...

Eigentlich könntest du ja eine Anleitung schreiben wie man diese Lücke stopft. Die Null Byte Geschichte in PHP 5.3.x sollte gefixed sein (laut Bugzilla), im IE war das zweimal und auch gefixed. Ob es in PHP 5.6 diese wieder in einer anderen Form gibt, Fragezeichen?

__________________
Personal stuff

Fehler gefunden, wieder ein Filter weniger. Aber etwas anderes ist sehr interessant:

Debug-Script:
Die Anfrage URL lautete:
http:/.../rev37/admin/debug.php?page=debug%00nullbyte.txt&action=irgendw as&lang=keineAhnung

Das Ergebnis:
Anfrage = page=debug%00nullbyte.txt&action=irgendwas&lang=ke ineAhnung
Get Page = debugnullbyte.txt

Ohne irgendein Filter eingesetzt zu haben, nur die Browser.

__________________
Personal stuff