Unbehandelte Exceptions und Sicherheit

Hallo,

gestern ist mir durch Zufall etwas aufgefallen: Durch eine Überlastung
des Servers auf dem mein Script läuft konnte keine Datenbankverbindung
aufgebaut werden und die Klasse warf eine Exception. Leider hatte ich
vergessen diese abzufangen und so bekam ich eine dieser PHP
Standard-Fehlermeldungen bei Exceptions ausgegeben.

Nun zum Problem: Da die Verbindung im Constructor fehlschlug, der als
Parameter die Verbindungsdaten (inkl. Passwort) bekommt wurden diese
Daten direkt ausgegeben - was mir so bisher nicht klar war.
Da ich bisher keinen Exception-Handler definiert hatte dürfte das das
Standardverhalten sein (wenn ich nichts übersehen habe).

Zumindest mir war nicht bewusst, dass so viele Informationen
standardmäßig ausgegeben werden. Ist das grob fahrlässig oder übersehe
ich da irgendwas? Es kann doch viel zu schnell vorkommen, dass man mal
eine Stelle übersieht an der man ein try/catch einbauen sollte die dann
auch im Test niemals fehlschlägt, weil man beim Testen auf bestimmte
Situationen einfach nicht kommt.

Grundsätzlich sollte man zwar am Ende die Fehleranzeige ausschalten,
aber wer macht da schon im nicht-professionellen Umfeld?

Gibt es eine generelle Möglichkeit (eventuell in der php.ini) die
Ausgabe von uncaught Exceptions zu konfigurieren und die Ausgabe des
Trace generell zu unterbinden ohne in jeden Script neu einen
Exceptionhandler zu definieren?

regards,
Jens

PS: Für meinen Fall ist es mit set_exception_handler gegessen, aber ich
war schockiert, dass nirgendwo vor einer solchen Stolperfalle gewarnt wird.

Re: Unbehandelte Exceptions und Sicherheit

Jens Himmelrath wrote:

> gestern ist mir durch Zufall etwas aufgefallen: Durch eine Überlastung
> des Servers auf dem mein Script läuft konnte keine Datenbankverbindung
> aufgebaut werden und die Klasse warf eine Exception. Leider hatte ich
> vergessen diese abzufangen und so bekam ich eine dieser PHP
> Standard-Fehlermeldungen bei Exceptions ausgegeben.
>
> Nun zum Problem: Da die Verbindung im Constructor fehlschlug, der als
> Parameter die Verbindungsdaten (inkl. Passwort) bekommt wurden diese
> Daten direkt ausgegeben - was mir so bisher nicht klar war.

Aber logisch isses! Wenn kein try...catch-Mechanismus drumrum ist wird
die Exception ausgegeben. Wie willste denn sonst wissen was, bzw. ob das
was falsch läuft.

> Da ich bisher keinen Exception-Handler definiert hatte dürfte das das
> Standardverhalten sein (wenn ich nichts übersehen habe).

Ja

> Zumindest mir war nicht bewusst, dass so viele Informationen
> standardmäßig ausgegeben werden. Ist das grob fahrlässig oder übersehe
> ich da irgendwas?

Was soll grob fahrlässig sein?
Das Verhalten von PHP? Nein
Dein Code? Ja :-)

Implementiere ein vernünftiges Errorhandling! Also z.B. erst prüfen ob
die Verbindung aufgebaut wurde, Ausnahme abfangen, Nutzer nur wissen
lassen das was nicht geht + Script beenden und richtige Fehlermeldung
ins Errorlog schreiben.

> eine Stelle übersieht an der man ein try/catch einbauen sollte die dann

Sowas kommt im normalfall nicht vor. Wenn das bei Dir der Fall ist
solltest Du dringend einen vernünftigen Entwicklungsrahmen schaffen und
fleissig TestUnits schreiben. (ist meist meeehr aufwand als der Code
selbst aber notwendig) Weiterhin immer gut Dokumentieren.
@exception ... ist hier der passende Inline Dokumentationsparameter um
in Methoden anzugeben welche Ausnahme(n) ausgelöst werden.

Meine IDE (ZDE) bietet hier bereits nach Erstellung des
Dokumentationsblocks dieses Kontextbezogen als Hilfetext an, was das
Ganze noch vereinfacht.

> auch im Test niemals fehlschlägt, weil man beim Testen auf bestimmte
> Situationen einfach nicht kommt.

Wie meinst Du das? Du must doch wissen was es alles an dem von *Dir*
geschriebenen Code zu testen gibt! Wenn Du nichtmal das weist, dann ich
auch nicht helfen. Aus den Augen aus den Sinn oder wie? ;-)

> PS: Für meinen Fall ist es mit set_exception_handler gegessen, aber ich
> war schockiert, dass nirgendwo vor einer solchen Stolperfalle gewarnt wird.

Warum auch? Das Verhalten sehe ich als selbstverständlich an. Aufregen
würde es mich, wenn es nicht so wär!

Es macht doch keinen Sinn seine Fehler nur zu Verstecken! Bekämpfe die
Ursache. (Also Deine Vergesslichkeit)

MfG, Ulf

Re: Unbehandelte Exceptions und Sicherheit

Ulf Kadner schrieb:
> Jens Himmelrath wrote:
>
> [snip "Muss so sein, ist halt so."]
>
> Es macht doch keinen Sinn seine Fehler nur zu Verstecken! Bekämpfe die
> Ursache. (Also Deine Vergesslichkeit)

Was ich meinte:
- Wenn ich die Exception abfange und verarbeite, dann will ich alle
Informationen und dann müssen alle Informationen her.
- Wenn die Exception nicht abgefangen wird (was bei mir nun auch
glücklicherweise nicht mehr der Fall ist) - was sicherlich passieren
kann wenn man kein "Uberprogrammer" ist wie Leute die niemals Fehler
machen, dann wird eine Exception an die Standardbehandlung von PHP
übergeben. Nach deiner These, mit der ich übereinstimme, sollte das nie
passieren. Man kann also davon ausgehen, dass etwas schief gelaufen ist
wenn es passiert - und dann sollte man imho nicht möglichst alle Daten
rausballern, zumindest nicht in Richtung Enduser.

Verstehe mich nicht falsch, ich bin hier und lese hier mit, damit mir
eben solche Klöpse nicht mehr passieren, aber PHP ist nunmal so
verbreitet, dass es IMHO unvermeidlich ist darüber nachzudenken wie man
den User (hier Entwickler) vor Fehlern schützen kann.

Gibt es denn wirklich keine Möglichkeit (aus administrativer Sicht) PHP
dazu zu bringen eben nicht alles 'auszuplappern'?

regards,
Jens

Re: Unbehandelte Exceptions und Sicherheit

Jens Himmelrath schrieb:
> Ulf Kadner schrieb:

>> Es macht doch keinen Sinn seine Fehler nur zu Verstecken! Bekämpfe die
>> Ursache. (Also Deine Vergesslichkeit)

> - Wenn die Exception nicht abgefangen wird (was bei mir nun auch
> glücklicherweise nicht mehr der Fall ist) - was sicherlich passieren
> kann wenn man kein "Uberprogrammer" ist wie Leute die niemals Fehler
> machen, dann wird eine Exception an die Standardbehandlung von PHP
> übergeben. Nach deiner These, mit der ich übereinstimme, sollte das nie
> passieren. Man kann also davon ausgehen, dass etwas schief gelaufen ist
> wenn es passiert - und dann sollte man imho nicht möglichst alle Daten
> rausballern, zumindest nicht in Richtung Enduser.

Jede Funktion oder Methode, die eine Exception werfen kann, gehört in
einen try-catch-Block, dann hast du das Problem erst gar nicht. Der
Java-Compiler z.B. meckert, wenn du eine eventuelle Exception nicht
fängst, bei PHP musst du halt selber drauf achten oder einen
Exception-Handler definieren.

Nicht umsonst ist eine nicht gefangene Exception ein Fatal-Error.

> Gibt es denn wirklich keine Möglichkeit (aus administrativer Sicht) PHP
> dazu zu bringen eben nicht alles 'auszuplappern'?

Ja, du kannst die Ausgabe in einer .htaccess oder in der php.ini
deaktivieren (display_errors 0), was beim produktiven Einsatz sowieso
ratsam ist.

Alternativ kannst du auch einen Exception-Handler in einer auto_prepend
Datei definieren, den du dann ggf. in den Scripten überschreiben kannst.



MfG,
Thomas

Re: Unbehandelte Exceptions und Sicherheit

Ulf Kadner schrieb:

[Exception verrät Passwörter]

>> Zumindest mir war nicht bewusst, dass so viele Informationen
>> standardmäßig ausgegeben werden. Ist das grob fahrlässig oder übersehe
>> ich da irgendwas?
>
> Was soll grob fahrlässig sein?
> Das Verhalten von PHP? Nein
> Dein Code? Ja :-)

Also darüber habe ich mich auch schon geärgert. Keine Fehlermeldung der
Welt sollte Passwörter ausgeben. Soetwas betrachte ich als Bug - das
PHP-Team leider nicht.

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:

> Also darüber habe ich mich auch schon geärgert. Keine Fehlermeldung der
> Welt sollte Passwörter ausgeben. Soetwas betrachte ich als Bug - das
> PHP-Team leider nicht.

Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
Passwörter handelt?

Wenn Du unfähig bist, sensible Daten so zu schützen, dass kein
Unbefugter sie jemals zu Gesicht bekommt, ist das Dein Problem und kann
auch nur von Dir gelöst werden. Das PHP-Team ist dafür in keiner Weise
verantwortlich.

Gruß. Claus

Re: Unbehandelte Exceptions und Sicherheit

Claus Reibenstein schrieb:

>>Also darüber habe ich mich auch schon geärgert. Keine Fehlermeldung der
>>Welt sollte Passwörter ausgeben. Soetwas betrachte ich als Bug - das
>>PHP-Team leider nicht.
>
> Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
> Passwörter handelt?

Ist das eine rhetorische Frage? Wenn PHP ein Passwort als Parameter
erwartet, darf man gerne davon ausgehen, dass der Parameter das Passwort
ist.
Das war ja leicht :P

> Wenn Du unfähig bist, sensible Daten so zu schützen, dass kein
> Unbefugter sie jemals zu Gesicht bekommt, ist das Dein Problem und kann
> auch nur von Dir gelöst werden.

In dieser Absolutheit ist das sowieso nicht möglich.

> Das PHP-Team ist dafür in keiner Weise
> verantwortlich.

Wie ich bereits erwähnte: Da kann man geteilter Ansicht sein. MySQL kann
soetwas z.b. Da gibt es nur die Fehlermeldung der Art "Login für
Nutzername X nicht erfolgreich - Passwort verwendet". Da steht nicht
"Login für Nutzername X und Passwort geheim nicht erfolgreich".

Wo war jetzt gleich noch das Problem? Welche der beiden Entwicklerteams
geht verantwortlicher mit den Daten um?

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:

> Claus Reibenstein schrieb:
>
>> Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
>> Passwörter handelt?
>
> Ist das eine rhetorische Frage?

Nein.

> Wenn PHP ein Passwort als Parameter erwartet

Davon steht im Ursprungsposting nichts. Dort steht nur, dass der
Constructor ein Passwort erwartet. Also weiß zunächst nur der Constuctor
von dem Passwort, dass es eins ist. PHP weiß das damit aber noch lange
nicht.

Gruß. Claus

Re: Unbehandelte Exceptions und Sicherheit

Claus Reibenstein schrieb:

>>>Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
>>>Passwörter handelt?
>>
>>Ist das eine rhetorische Frage?
>
> Nein.

Schade :P

>>Wenn PHP ein Passwort als Parameter erwartet
>
> Davon steht im Ursprungsposting nichts. Dort steht nur, dass der
> Constructor ein Passwort erwartet. Also weiß zunächst nur der Constuctor
> von dem Passwort, dass es eins ist. PHP weiß das damit aber noch lange
> nicht.

Neben Constructor wird auch "Datenbankverbindung" erwähnt. Desweiteren
wird von "standardmäßigen Informationen" geredet und das deutet (für
mich) alles auf die Verwendung von PDO hin.
Denn genau dort tritt ein solches Problem auf. DB-Connections-Daten
werden im Constructor definiert und sobald das fehlschlägt, verrät PHP
alles.
Deswegen habe ich auch schon mal einen Bugreport bei PHP abgegeben,
welcher aber abgelehnt wurde. Ansonsten würde mir jetzt keine - außer
eine selbstgebaute und grob fahrlässige -
Datenbankverbindungsfunktionalität einfallen, die sich genauso verhält.

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:

> Claus Reibenstein schrieb:
>
>>>> Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
>>>> Passwörter handelt?
>>>
>>> Ist das eine rhetorische Frage?
>>
>> Nein.
>
> Schade :P

Es wäre nett, wenn Du die Namen der Zitierten stehen lassen würdest,
damit man nachvollziehen kann, wer was gesagt hat.

>>> Wenn PHP ein Passwort als Parameter erwartet
>>
>> Davon steht im Ursprungsposting nichts. Dort steht nur, dass der
>> Constructor ein Passwort erwartet. [...]

> Neben Constructor wird auch "Datenbankverbindung" erwähnt. Desweiteren
> wird von "standardmäßigen Informationen" geredet und das deutet (für
> mich) alles auf die Verwendung von PDO hin.

Hier muss ich mich jetzt ausklinken. Ich benutze keine PDO (ich musste
erst mal nachschauen, was das überhaupt ist), sondern die klassischen
mysql-Funktionen wie mysql_connect(). Da tritt dieses Problem übrigens
nicht auf, wie ich eben mal getestet habe.

Gruß. Claus

Re: Unbehandelte Exceptions und Sicherheit

Claus Reibenstein schrieb:

>>>>>Und woher bitte schön soll PHP wissen, dass es sich bei den Daten um
>>>>>Passwörter handelt?
>>>>
>>>>Ist das eine rhetorische Frage?
>>>
>>>Nein.
>>
>>Schade :P
>
> Es wäre nett, wenn Du die Namen der Zitierten stehen lassen würdest,
> damit man nachvollziehen kann, wer was gesagt hat.

Ich lasse immer den Namen des von mir Zitierten stehen. Eine weitere
Verschachtelung fand nicht statt. Also was sollte ich noch weiter
optimieren? Dein Anliegen kann ich gerade nicht ganz nachvollziehen.

>>>>Wenn PHP ein Passwort als Parameter erwartet
>>>
>>>Davon steht im Ursprungsposting nichts. Dort steht nur, dass der
>>>Constructor ein Passwort erwartet. [...]
>
>>Neben Constructor wird auch "Datenbankverbindung" erwähnt. Desweiteren
>>wird von "standardmäßigen Informationen" geredet und das deutet (für
>>mich) alles auf die Verwendung von PDO hin.
>
> Hier muss ich mich jetzt ausklinken. Ich benutze keine PDO (ich musste
> erst mal nachschauen, was das überhaupt ist), sondern die klassischen
> mysql-Funktionen wie mysql_connect(). Da tritt dieses Problem übrigens
> nicht auf, wie ich eben mal getestet habe.

Das ist richtig. Daher war ich auch der Überzeugung, dass die
Beschreibung zwar nicht ausreichend konkret, doch irgendwie ausreichend ist.
Desweiteren würde ich dir nahelegen, dich ein wenig mit PDO zu
beschäftigen und auf die mysql-* Funktionen verzichten. Das ist ein
gewisser Fortschritt, auf dem die PHP-Anwender lange warten mußten.

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Thomas 'DaFox' Hamacher schrieb:
> Jens Himmelrath schrieb:
>> Ulf Kadner schrieb:
>
>>> Es macht doch keinen Sinn seine Fehler nur zu Verstecken! Bekämpfe
>>> die Ursache. (Also Deine Vergesslichkeit)
>
>> - Wenn die Exception nicht abgefangen wird (was bei mir nun auch
>> glücklicherweise nicht mehr der Fall ist) - was sicherlich passieren
>> kann wenn man kein "Uberprogrammer" ist wie Leute die niemals Fehler
>> machen, dann wird eine Exception an die Standardbehandlung von PHP
>> übergeben. Nach deiner These, mit der ich übereinstimme, sollte das
>> nie passieren. Man kann also davon ausgehen, dass etwas schief
>> gelaufen ist wenn es passiert - und dann sollte man imho nicht
>> möglichst alle Daten rausballern, zumindest nicht in Richtung Enduser.
>
> Jede Funktion oder Methode, die eine Exception werfen kann, gehört in
> einen try-catch-Block, dann hast du das Problem erst gar nicht. Der
> Java-Compiler z.B. meckert, wenn du eine eventuelle Exception nicht
> fängst, bei PHP musst du halt selber drauf achten oder einen
> Exception-Handler definieren.
>
> Nicht umsonst ist eine nicht gefangene Exception ein Fatal-Error.

Das es _technisch_ ok ist will ich gar nicht bestreiten.
Aber ich habe immer (auch aufgrund meiner eigenen teilweisen
Unfähigkeit) den Fall im Kopf, dass man mal was übersieht. Eine Notice
nach Java-Manier wäre schon eine schöne Sache und die 'Lösung' mit dem
Exception-Handler habe ich jetzt auch, musste aber erst durch die
Ausgabe meines Passwortes darauf kommen...

Da ich immer wieder nach Monaten oder Jahren dumme Fehler oder auch nur
ungeschickte Code-Teile in meinen Programmen finde, gehe ich
mittlerweile grundsätzlich davon aus, dass mein Code voller Fehler
steckt - zwar werden die Abstände in denen ich Fehler finde immer größer
und die schwere der Fehler durchschnittlich geringer, aber ich stoße wie
hier immer wieder auf Situationen in denen ein solcher Fehler im
geschäftlichen Betrieb fatal sein könnte.
Außerdem gehe ich arroganter Weise davon aus, dass jeder Mensch so
ähnlich funktioniert wie ich und es deshalb keinen Fehlerfreien Code
gibt - deshalb auch meine Frage wie und ob man da nicht grundsätzlich
was ändern kann.
Quasi das '-v' bei der Exception-Ausgabe abschalten. ;)

>
>> Gibt es denn wirklich keine Möglichkeit (aus administrativer Sicht)
>> PHP dazu zu bringen eben nicht alles 'auszuplappern'?
>
> Ja, du kannst die Ausgabe in einer .htaccess oder in der php.ini
> deaktivieren (display_errors 0), was beim produktiven Einsatz sowieso
> ratsam ist.

Das ist schon klar, eventuell auch keine schlechte Idee dann jedem
Entwickler einzuhämmern, dass er das dann zum testen explizit anschalten
muss.
Wie wäre das in der .htaccess? "php_admin_value display_errors X"? Und
dazu etwas OT: Muss ich dafür allow override all geben - das würde ich
ungern tun.

> Alternativ kannst du auch einen Exception-Handler in einer auto_prepend
> Datei definieren, den du dann ggf. in den Scripten überschreiben kannst.

Das hört sich für mich nach der bisher besten Lösung für meinen Fall an.
Dass ich da nicht selbst drauf gekommen bin - habe dieses Feature bisher
noch nie benutzt.
Danke

regards,
Jens

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff wrote:

> Ulf Kadner schrieb:
>
> [Exception verrät Passwörter]

Nein das schrieb ich nicht! (Nicht explizit)

> Also darüber habe ich mich auch schon geärgert. Keine Fehlermeldung der
> Welt sollte Passwörter ausgeben.

Das obliegt einzig und allein dem Programmierer. Wer seinen Code so
gestalltet, das derartiges passiert, muss natürlich mit den Konsequenzen
auch leben können. Das Prinzip der Ausnahmen beruht nunmal auf korrekter
Programmierung! Das ist nicht nur in PHP so. Wer da extra noch Passworte
in Ausnahmen bzw. deren Meldungen einbaut und sich dann nicht um deren
korrekte Behandlung kümmert, dem ist nicht zu helfen!

> Soetwas betrachte ich als Bug - das
> PHP-Team leider nicht.

Ich schliesse mich dem PHP-Team an.

Unsauber Programmierung erfordert Strafmaßnahmen. :-)

MfG, Ulf

Re: Unbehandelte Exceptions und Sicherheit

Ulf Kadner schrieb:

>> Also darüber habe ich mich auch schon geärgert. Keine Fehlermeldung der
>> Welt sollte Passwörter ausgeben.
>
> Das obliegt einzig und allein dem Programmierer. Wer seinen Code so
> gestalltet, das derartiges passiert, muss natürlich mit den Konsequenzen
> auch leben können. Das Prinzip der Ausnahmen beruht nunmal auf korrekter
> Programmierung! Das ist nicht nur in PHP so. Wer da extra noch Passworte
> in Ausnahmen bzw. deren Meldungen einbaut und sich dann nicht um deren
> korrekte Behandlung kümmert, dem ist nicht zu helfen!

Hast du auch den Zweig des Gesprächen zwischen mir und Claus gelesen?
Alles deutet darauf an, dass die Passwörter durch PDO verraten werden.

Es ist nicht gerade trivial oder gar weit verbreitet, dass standardmäßig
eingebaute Fehlerbehandlungen solche sensiblen Daten ausgeben. Oder
anders gesagt: Das PHP-Team hat extra die Ausgabe von Passwörtern in
Ausnahmen eingebaut und sich nicht um deren korrekte Behandlung gekümmert.

>> Soetwas betrachte ich als Bug - das
>> PHP-Team leider nicht.
>
> Ich schliesse mich dem PHP-Team an.
>
> Unsauber Programmierung erfordert Strafmaßnahmen. :-)

Darf ich das PHP-Team den jetzt für unsaubere Programmierung schlagen?

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff wrote:

> Hast du auch den Zweig des Gesprächen zwischen mir und Claus gelesen?
> Alles deutet darauf an, dass die Passwörter durch PDO verraten werden.

Hallo!

Ja hab ich. Ich nutz auch PDO. Was hindert dich daran alle notwendigen
Ausnahmen abzufangen und ins Log zu schreiben? Ist doch kein Problem!

Ich finds zwar auch unmöglich das Passwörter in Fehlermeldungen
auftauchen aber Problem ist das keins.

> Es ist nicht gerade trivial oder gar weit verbreitet, dass standardmäßig
> eingebaute Fehlerbehandlungen solche sensiblen Daten ausgeben.

Nein das siehst Du falsch! Ausgegeben werden die nur, weil Du es
ermöglichst. Auf produktiven Systemen haben generell keine
Fehlermeldungen dieser Art was beim Nutzer zu suchen. Administratoren
bekommen explizite Möglichkeiten an die Hand um "Debugmeldungen zu
sehen. Implementiere eine ordentlich Fehlerbehandlung und das "Problem"
ist gelöst.

Ich verstehe nicht was daran nicht OK sein soll.

> Oder
> anders gesagt: Das PHP-Team hat extra die Ausgabe von Passwörtern in
> Ausnahmen eingebaut und sich nicht um deren korrekte Behandlung gekümmert.

Nein deren Behandlung obliegt immernoch dem Programmierer.

>>Unsauber Programmierung erfordert Strafmaßnahmen. :-)
>
> Darf ich das PHP-Team den jetzt für unsaubere Programmierung schlagen?

Wohl eher Du Dich! ;-)

MfG, Ulf

Re: Unbehandelte Exceptions und Sicherheit

Ulf Kadner schrieb:

>> Hast du auch den Zweig des Gesprächen zwischen mir und Claus gelesen?
>> Alles deutet darauf an, dass die Passwörter durch PDO verraten werden.
>
> Ja hab ich. Ich nutz auch PDO. Was hindert dich daran alle notwendigen
> Ausnahmen abzufangen und ins Log zu schreiben? Ist doch kein Problem!

Zwei Dinge:
1. Einen ständig reproduzierbaren Bug, der dafür sorgt, dass ich
Exceptions, die ich in aufgerufen Methoden werfe, nicht catchen kann,
ohne dass sich PHP über einen Fehler im Stack-Frame in Zeile 0 bei Datei
beschwert. Was dummerweise niemanden interessiert.
2. (Hier mag ich mich irren) Es ist nirgends dokumentiert und schon gar
nicht zu erwarten, dass PDO ausgerechnet so etwas macht :P

> Ich finds zwar auch unmöglich das Passwörter in Fehlermeldungen
> auftauchen aber Problem ist das keins.

Ich betrachte das als Design-Fehler von PDO. Das verraten von Passwörter
ist kein Standard und ist auch nicht vorrauszusehen. Hat man diese
Erfahrung nicht gemacht, weiß man das nicht und wird diesen Fehler
nahezu zwangsläufig begehen.

>> Es ist nicht gerade trivial oder gar weit verbreitet, dass standardmäßig
>> eingebaute Fehlerbehandlungen solche sensiblen Daten ausgeben.
>
> Nein das siehst Du falsch! Ausgegeben werden die nur, weil Du es
> ermöglichst. Auf produktiven Systemen haben generell keine
> Fehlermeldungen dieser Art was beim Nutzer zu suchen. Administratoren
> bekommen explizite Möglichkeiten an die Hand um "Debugmeldungen zu
> sehen. Implementiere eine ordentlich Fehlerbehandlung und das "Problem"
> ist gelöst.

Das ist mir auch klar. Aber ich möchte noch mal unterstreichen, dass
dieses Verhalten weder vernüftig, noch vorhersehbar ist. Außerdem muß
man auch bedenken, dass man nicht immer alle Möglichkeiten zur Verfügung
hat und man daher z.b. nicht mal ebend die Fehlermeldungen nicht anzeigt.

> Ich verstehe nicht was daran nicht OK sein soll.

Das Anzeigen von Passwörter ist niemals OK. Egal wer es macht. Ob nun
ich soetwas einprogrammiere oder das PHP-Team. In diesem Fall kommt
erschwerend hinzu, dass dieses "Feature" unerwartet ist. Vergleiche es
von mir aus mit einer ABG - da darf man auch nicht unerwartete,
überraschende Klauseln vereinbaren. So sollte es bei Fehlerbehandlungen
auch sein. Status quo sagt: Zeige keine Passwörter. Warum ausgerechnet
PDO sich daran nicht hält, ist mir ein Rätsel.

>> Oder
>> anders gesagt: Das PHP-Team hat extra die Ausgabe von Passwörtern in
>> Ausnahmen eingebaut und sich nicht um deren korrekte Behandlung
>> gekümmert.
>
> Nein deren Behandlung obliegt immernoch dem Programmierer.

PDO kommt vom PHP-Team. Die Fehlerbehandlung des PDOs auch. Ich müßte
mir in dem Fall die Mühe machen, deren Fehlerbehandlung abzufangen und
durch meine eigene zu ersetzen. Ich mache also eine Fehlerbehandlung der
Fehlerbehandlung. Du möchtest mir jetzt erklären, was daran logisch ist ;)

>>> Unsauber Programmierung erfordert Strafmaßnahmen. :-)
>>
>> Darf ich das PHP-Team den jetzt für unsaubere Programmierung schlagen?
>
> Wohl eher Du Dich! ;-)

Das werden wir ja sehen :P

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Jens Himmelrath schrieb:
> Thomas 'DaFox' Hamacher schrieb:
>> Jens Himmelrath schrieb:

>>> - Wenn die Exception nicht abgefangen wird (was bei mir nun auch
>>> glücklicherweise nicht mehr der Fall ist) - was sicherlich passieren
>>> kann wenn man kein "Uberprogrammer" ist wie Leute die niemals Fehler
>>> machen, dann wird eine Exception an die Standardbehandlung von PHP
>>> übergeben.

>> Jede Funktion oder Methode, die eine Exception werfen kann, gehört in
>> einen try-catch-Block, dann hast du das Problem erst gar nicht. Der
>> Java-Compiler z.B. meckert, wenn du eine eventuelle Exception nicht
>> fängst, bei PHP musst du halt selber drauf achten oder einen
>> Exception-Handler definieren.

> Das es _technisch_ ok ist will ich gar nicht bestreiten.

Es ist in jeglicher Hinsicht ok.

> Aber ich habe immer (auch aufgrund meiner eigenen teilweisen
> Unfähigkeit) den Fall im Kopf, dass man mal was übersieht. Eine Notice
> nach Java-Manier wäre schon eine schöne Sache und die 'Lösung' mit dem
> Exception-Handler habe ich jetzt auch, musste aber erst durch die
> Ausgabe meines Passwortes darauf kommen...

Ich finde es auch bedauerlich, dass man so etwas erst merkt, wenn es zu
spät ist, aber da wirst du noch auf unendlich viele Situationen treffen,
bei denen du erst hinterher schlauer bist. Nicht nur bei PHP.

> Da ich immer wieder nach Monaten oder Jahren dumme Fehler oder auch nur
> ungeschickte Code-Teile in meinen Programmen finde, gehe ich
> mittlerweile grundsätzlich davon aus, dass mein Code voller Fehler
> steckt - zwar werden die Abstände in denen ich Fehler finde immer größer
> und die schwere der Fehler durchschnittlich geringer, aber ich stoße wie
> hier immer wieder auf Situationen in denen ein solcher Fehler im
> geschäftlichen Betrieb fatal sein könnte.

Im geschäftlichen Betrieb gehört display_errors deaktiviert und alle
Fehler mittels error_log geloggt. Dann fällt eine nicht gefangene
Ausnahme auf, ohne das sie schaden anrichten kann.

> Außerdem gehe ich arroganter Weise davon aus, dass jeder Mensch so
> ähnlich funktioniert wie ich und es deshalb keinen Fehlerfreien Code
> gibt - deshalb auch meine Frage wie und ob man da nicht grundsätzlich
> was ändern kann.

Gibt es auch nicht, vgl.

> Quasi das '-v' bei der Exception-Ausgabe abschalten. ;)

display_errors 0

>>> Gibt es denn wirklich keine Möglichkeit (aus administrativer Sicht)
>>> PHP dazu zu bringen eben nicht alles 'auszuplappern'?

>> Ja, du kannst die Ausgabe in einer .htaccess oder in der php.ini
>> deaktivieren (display_errors 0), was beim produktiven Einsatz sowieso
>> ratsam ist.

> Das ist schon klar, eventuell auch keine schlechte Idee dann jedem
> Entwickler einzuhämmern, dass er das dann zum testen explizit anschalten
> muss.

Im professionellen Umfeld wird der Entwickler sicherlich nicht auf einer
produktiven Maschine entwickeln, also sollte es kein Problem darstellen.

> Wie wäre das in der .htaccess? "php_admin_value display_errors X"?

Wenn du "php_admin_value" nutzt, dann kann die Option nicht mehr (durch
ini_set() oder in einer weiteren Konfigurationsdatei) überschrieben
werden. Zumindest ist das die Theorie.

-
-

> dazu etwas OT: Muss ich dafür allow override all geben - das würde ich
> ungern tun.

Nein, AllowOverride Options reicht.

> Danke

Nicht dafür :).


MfG,
Thomas

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:
> Claus Reibenstein schrieb:

>> Davon steht im Ursprungsposting nichts. Dort steht nur, dass der
>> Constructor ein Passwort erwartet. Also weiß zunächst nur der Constuctor
>> von dem Passwort, dass es eins ist. PHP weiß das damit aber noch lange
>> nicht.

[PDO]

> Denn genau dort tritt ein solches Problem auf. DB-Connections-Daten
> werden im Constructor definiert und sobald das fehlschlägt, verrät PHP
> alles.

Im Manual steht nicht ohne Grund, dass der PDO-Konstruktor eine Ausnahme
werfen kann, die man zu fangen hat. Und da die Ausnahme den Stacktrace
mit den Argumenten enthält...

> Deswegen habe ich auch schon mal einen Bugreport bei PHP abgegeben,
> welcher aber abgelehnt wurde.

Es ist vielleicht ungünstig, dass die Exception, wenn sie nicht gefangen
wird, automatisch im Browser dargestellt wird, aber dem kann ich mit
entsprechenden Konfigurationen entgegenwirken.

Dass die Exception allerdings, wie jede andere auch, einen vollständigen
Stacktrace besitzt und in diesem selbstverständlich auch alle Argumente
vorhanden sind, ist völlig logisch. Alles andere wäre IMHO ein Bug.

> Ansonsten würde mir jetzt keine - außer eine selbstgebaute und grob
> fahrlässige - Datenbankverbindungsfunktionalität einfallen, die sich
> genauso verhält.

JDBC verhält sich genauso. Wenn beim Aufruf der connect()-Methode des
Treibers ein Fehler auftritt, wird eine SQLException geworfen, die wie
jede andere Exception einen Stacktrace hat.

Der Unterschied ist hier halt, dass sich das Programm gar nicht erst
übersetzen lässt, wenn ich die eventuelle Exception nicht fange.


MfG,
Thomas

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:
> Claus Reibenstein schrieb:

>>> Neben Constructor wird auch "Datenbankverbindung" erwähnt. Desweiteren
>>> wird von "standardmäßigen Informationen" geredet und das deutet (für
>>> mich) alles auf die Verwendung von PDO hin.

>> Hier muss ich mich jetzt ausklinken. Ich benutze keine PDO (ich musste
>> erst mal nachschauen, was das überhaupt ist), sondern die klassischen
>> mysql-Funktionen wie mysql_connect(). Da tritt dieses Problem übrigens
>> nicht auf, wie ich eben mal getestet habe.

> Desweiteren würde ich dir nahelegen, dich ein wenig mit PDO zu
> beschäftigen und auf die mysql-* Funktionen verzichten. Das ist ein
> gewisser Fortschritt, auf dem die PHP-Anwender lange warten mußten.

Das stimmt wohl. Leider kann man nicht bei jedem Anwendungsfall PDO
nutzen und muss wieder auf die "nativen" Funktionen zurückgreifen. Aber
PDO ist echt eine Alternative zu PEAR::DB oder PEAR::MDB und die API ist
sehr überschaubar.


MfG,
Thomas

Re: Unbehandelte Exceptions und Sicherheit

Thomas 'DaFox' Hamacher schrieb:
[..]
>> Deswegen habe ich auch schon mal einen Bugreport bei PHP abgegeben,
>> welcher aber abgelehnt wurde.
>
> Es ist vielleicht ungünstig, dass die Exception, wenn sie nicht gefangen
> wird, automatisch im Browser dargestellt wird, aber dem kann ich mit
> entsprechenden Konfigurationen entgegenwirken.
>
> Dass die Exception allerdings, wie jede andere auch, einen vollständigen
> Stacktrace besitzt und in diesem selbstverständlich auch alle Argumente
> vorhanden sind, ist völlig logisch. Alles andere wäre IMHO ein Bug.

"Ungünstig" ist eine nette Umschreibung für das Wort "fatal".
Das Passwort wird klar und deutlich als Argument verlangt und ist daher
auch als solches zu erkennen. Es sollte daher selbst bei einem
Stack-Trace nichts zu suchen haben. Natürlich ist eine Exception im
Applikationsfluß zu erkennen, aber das hat nichts mit der Ausgabe von
Passwörtern zu tun.

>> Ansonsten würde mir jetzt keine - außer eine selbstgebaute und grob
>> fahrlässige - Datenbankverbindungsfunktionalität einfallen, die sich
>> genauso verhält.
>
> JDBC verhält sich genauso. Wenn beim Aufruf der connect()-Methode des
> Treibers ein Fehler auftritt, wird eine SQLException geworfen, die wie
> jede andere Exception einen Stacktrace hat.

Solche Vergleiche sind nicht allzu nützlich. Ich finde sicherlich auch
Exceptions, wo man darauf verzichtet, das Passwort auszugeben ;)

> Der Unterschied ist hier halt, dass sich das Programm gar nicht erst
> übersetzen lässt, wenn ich die eventuelle Exception nicht fange.

Das ist auch etwas völlig anderes. Bei PDO kann das mitten im Betrieb
passieren: Wenn die Datenbank nicht mehr da ist. Soetwas kann beim
compilieren nicht auffallen. Das ist daher ein Äpfel-Birnen-Vergleich.
Stelle dir vor, du könntest es ohne Exception-Catch übersetzen - würdest
du es dann immernoch gut heißen? ;)

Gruß,
Torsten

Re: Unbehandelte Exceptions und Sicherheit

Torsten Zühlsdorff schrieb:

>> Der Unterschied ist hier halt, dass sich das Programm gar nicht erst
>> übersetzen lässt, wenn ich die eventuelle Exception nicht fange.
>
> Das ist auch etwas völlig anderes.

Das ist gar nix anderes. In Java gehört ein 'throws CheckedException'
zur Methodensignatur. Diese muss abgefangen (oder auch explizit
weitergeworfen) werden, sonst gehts nicht zu kompilieren. In PHP ist das
nicht so. In C# übrigens auch nicht. In diesen Sprachen muss man halt
selbst wissen, welche Methoden, die man aufruft, welche Exceptions
werfen, und diese entsprechend behandeln.

> Bei PDO kann das mitten im Betrieb
> passieren: Wenn die Datenbank nicht mehr da ist.

Das kann auch bei Java oder C# passieren. Es ist in allen angeführten
Sprachen deine Sache, die möglicherweise geworfenen Exception zu
behandeln. Der einzige Unterschied ist, dass es in Java sog. checked
Exceptions gibt, die, wie bereits erwähnt, in der Methodensignatur
auftauchen und ein "Übersehen" unmöglich machen.

> Stelle dir vor, du könntest es ohne Exception-Catch übersetzen - würdest
> du es dann immernoch gut heißen? ;)

Kann man. Wenn die Java-Exception eine unchecked Exception ist. Aber von
deren Verwendung wird bei eigenen Exceptions abgeraten.

gruss, heli