Ungekürzte Fehlerausgabe trotz Einstellung "Privat"

    Hallo,


    stellt man die Fehlerausgabe im ACP auf "Privat" sollte ja allein der kryptische Fehlerzahlencode ausgegeben werden. Das scheint auch in den meisten Fällen zu klappen, z.B. bei einem vergessenen Semikolon im Code.


    Folgender Fehler wird trotz der Einstellung jedoch vollständig ausgegeben, inkl. PHP-Version, WSC-Version und Stack Trace:


    • Error Type:

      PDOException

    • Error Message:

      SQLSTATE[HY000] [1203] User DB already has more than 'max_user_connections' active connections

    • Error Code:

      1203

    • File:

      */lib/system/database/MySQLDatabase.class.php (45)

    • Stack Trace:

      • #0 */lib/system/database/MySQLDatabase.class.php (45):
      • PDO->__construct('[redacted]', '[redacted]', '[redacted]', '[redacted]')
      • #1 */lib/system/database/Database.class.php (119):
      • wcf\system\database\MySQLDatabase->connect()
      • #2 */lib/system/WCF.class.php (359):
      • wcf\system\database\Database->__construct('[redacted]', '[redacted]', '[redacted]', '[redacted]', '[redacted]')
      • #3 */lib/system/WCF.class.php (164):
      • wcf\system\WCF->initDB()
      • #4 */global.php (13):
      • wcf\system\WCF->__construct()
      • #5 */index.php (8):
      • require_once('*/global.php')


    Anscheinend läuft diese Meldung irgendwie an der Einstellung vorbei.


    Beste Grüße,


    Less

    Auch als Gast ? Ich bin mir nicht sicher, aber ich meine dass man als Admin im eingeloggten Zustand trotzdem die komplette F-Meldung sieht.

    Quote from scy

    Auch als Gast ?

    Ja, ich habe mich zur Rekonstruktion des Ganzen extra ausgeloggt. Und wie gesagt, bei anderen Fehlern erscheint ja die private Fehlermeldung, sprich allein der Zahlencode.


    Ich vermute, der Fehler wird ungekürzt geschmissen, weil die Einstellung wegen der überlasteten MySQL-Verbindung garnicht abgefragt werden kann. Dann wäre es jedoch sinnvoll, in solchen Fällen auf die minimalste, sprich private Ausgabe zurückzufallen. Das ist die sicherste Variane und für den Admin entsteht ja kein Nachteil, weil er die Meldung im Log einsehen kann.

    Edited 6 times, last by less ().

    Das ist eine Zwickmühle. Bevor die Optionen geladen werden, wird die DB Verbindung aufgebaut (um für neuere Optionen zu suchen). Deswegen weiß die Suite wahrscheinlich wohl nicht, dass sie sowas nicht ausspucken soll.

    Der Argumentation kann ich nicht folgen... der letzte gültige Wert steht in der options.inc.php in Form der Variable EXCEPTION_PRIVACY. Folglich könnte das WSC auch, falls es direkt bei der Initialisierung zu einem DB-Error kommt, wissen können in welchem Umfang der Fehler ausgegeben werden soll. Der einzige Ausnahmefall wäre, wenn es zum Zeitpunkt der Initialisierung keine options.inc.php im Filesystem gibt; in diesem Fall müsste man die default Werte annehmen, bis man mittels der Datenbank eine neue options.inc.php bauen könnte - was in Fall oben nicht ginge, dann wäre die Art der Fehlermeldung "erklärbar".

    Tja, dann wäre es in meinem Augen ggf. mal eine Option darüber nachzudenken, die Optionen zu laden bevor man die DB-Initialisiert...

    Barungar Stimmt, die Variable steht als EXCEPTION_PRIVACY in der options.inc.php und das korrekt als "private". Meine Vermutung, dass sie erst aus der DB geholt werden muss, stimmt also nicht. Es war auch nur eine Idee.

    Die Ursache, warum dieser konkrete Fehler trotzdem ungekürzt ausgegeben wird, muss also woanders liegen.


    Edit: Mein Beitrag hat sich mit dem Beitrag von jens1o überschnitten.

    Quote from Barungar

    Tja, dann wäre es in meinem Augen ggf. mal eine Option darüber nachzudenken, die Optionen zu laden bevor man die DB-Initialisiert...

    Das wäre vielleicht eine Variante. Die andere wäre, die private Ausgabe von vornherein als Fallback zu nutzen.

    Quote from less

    Stimmt, die Variable steht als EXCEPTION_PRIVACY in der options.inc.php und das korrekt als "private". Meine Vermutung, dass sie erst aus der DB geholt werden muss, stimmt also nicht. Es war auch nur eine Idee.

    Du hast mich missverstanden (bzw. nicht weiter gedacht): Dadurch, dass zuerst die Datenbankverbindung aufgebaut wird und erst danach die Optionen eingelesen werden und der Fehler bei der MySQL-Verbindung auftritt, wo deine Optionen (mit deiner Einstellung) noch nicht geladen worden sind funktioniert das ganze nicht.

    Quote from Barungar

    Tja, dann wäre es in meinem Augen ggf. mal eine Option darüber nachzudenken, die Optionen zu laden bevor man die DB-Initialisiert...

    Was aber auch nicht sinnvoll ist, da man so die option.inc.php, sofern sie nicht vorhanden ist, nicht neu generieren kann da noch keine DB-Verbindung besteht. Die Fehlerausgabe beim initialisieren der DB-Verbindung explizit mit der Einstellung "Privat" auszugeben wäre da wohl am Besten.

    Muss man halt nur splitten... also erst loadOptions(), dann initDB() und anschließend reBuildOptions() ... so wird die options.inc.php auch im Zweifel aktualisiert. Im Moment ist es "works as designed", was bedeutet das DB-Error zur Initialisierung immer "full" geworfen werden.

  • Marcel Werk

    Set the Label from Future fix to Won’t fix

    Diese Entscheidung halte ich für äußerst bedenklich!


    Es geht ja nicht allein um eine Ausgabe bei einem Fehler, sondern auch bei zuvielen Zugriffen / einer Überlastung, werden sensible Daten wie die PHP-Version, die WCF-Version, Datenbankname, etc. für jeden gespoilert! Z.B. werden bei einem DOS-Angriff (der zur Überlastung führt) dem Angreifer dann noch diese Daten auf dem Silbertablett serviert.


    Hacker welcome!


    Für alle, die neu auf diesen Thread stoßen zusammengefasst: Bei einer Datenbank-Überlastung wird trotz anderslautender Einstellung im ACP eine ungekürzte, vollständige Fehlermeldung ausgegeben - auch Gästen.



    Edited 3 times, last by less ().

    Like 1

    ...oder als Standard die eingeschränkte Variante ausliefern können (welche man bei Bedarf im ACP dann für alle anderen Fälle ausführlicher einstellen kann).

    Edited once, last by less ().

    Quote from less

    Diese Entscheidung halte ich für äußerst bedenklich!


    Es geht ja nicht allein um eine Ausgabe bei einem Fehler, sondern auch bei zuvielen Zugriffen / einer Überlastung, werden sensible Daten wie die PHP-Version, die WCF-Version, Datenbankname, etc. für jeden gespoilert! Z.B. werden bei einem DOS-Angriff (der zur Überlastung führt) dem Angreifer dann noch diese Daten auf dem Silbertablett serviert.


    Hacker welcome!

    Und was bringt das dem Angreifer? Mit dem Wissen von Versionen kann der nicht viel anfangen. Vor allem wenn du immer die aktuellsten Versionen nutzt.

    Hanashi Wieso lässt du dann die Versions-Nummer nicht im Footer deiner Seite anzeigen? Optik, hmm?... :rolleyes: Den meisten wird es genau um diese Sicherheit gehen, nicht alles zu verraten. Und genau diese Sicherheit hebelt die ungekürzte Fehlermeldung aus, weil sie in einem kritischen Fall erscheint, ganz gleich, was man im ACP eingestellt hat.


    Edit: Ich habe die Ausgabe mal als Screenshot an meinem obigen Beitrag angehängt.

    Edited 2 times, last by less ().