[php] achja, die Sicherheit ...

[Sebastian Mendel]

Yannik Hampe schrieb:

>>> Wenn man noch Arrays im Request verwendet, ist vielleicht ein rekursiver 
>>> check auch ganz nützlich:
>> Wozu? Wie sollte man denn da Variablen in $GLOBALS überschrieben können?
> so:
> bla.php?var[index]=wert

Wo liegt da der Sinn?
Wenn er eine Variable setzen will dann kann er das doch ohne den Umweg
über dieses Angriffs-Scenario ... es ging doch nur um automatisch
registrierte Variablen die GLOBALE Variablen überschrieben und dann
mittels der 'hash'-Variablen ein 'löschen' verhindern - wenn ich also
die Variable 'var' nicht in GLOBAL haben will kann ich sie einfach
löschen. Egal ob da noch ein var[index] ist oder nicht.


>>>>> Ansonsten kann man natürlich auch einfach bestimmten Code vermeiden. Zum 
>>>>> Beispiel "deren" Beispielcode:
>>>>>
>>>>> [...]
>>>> Da gibt es auch wesentlich verbreiterten Code wo das zutrifft, der
>>>> gezeigte war wohl nur der kürzeste.
>>> Das heisst ja nicht, dass man solchen Code bei seinen eigenen Projekten 
>>> nicht vermeiden kann.
>>> Ich halte es eh für fraglich, ob es eine gute Idee ist die 
>>> unset-Funktion auf diese Weise zu nutzen.
>> Ja, schön ist die Welt ...
>> Z. B. in 'gewachsenen' OpenSource Projekten mit über 100.000 Zeilen an
>> Code und verschiedensten Contributoren ist es manchmal etwas schwer den
>> Überblick zu halten - und da ist es sicherer im Zweifelsfall einfach
>> alle (potenziell unsicheren) externen Variablen zu löschen.
> ...und sich darauf verlassen, dass sie irgendwo vorher im Code wirklich 
> gelöscht worden sind, wenn der Code möglicherweise von wem ganz anders 
> kommt?
> Es funktioniert zwar, aber wie gesagt... Die Übersichtlichkeit...

nein, aber wenn man 100.000 Zeilen fremden Code plus irgendwelche
Templates durchsucht und überprüft ob sie überall korrekt verwendet wird
kann es schon mal passieren das man eine Stelle übersieht.


>>> Es erhöht nämlich nicht gerade die Lesbarkeit des Codes, wenn irgendwo 
>>> am Anfang einer php-Datei bestimmte Variabeln geunseted werden, auf die 
>>> dann wo ganz anders wieder zugegriffen wird.
>> Doch, wenn es ordentlich dokumentiert ist.
> Super... Warum eine lange Dokumentation schreiben, wenn man den Code 
> auch so schreiben kann, das man ihn ohne versteht?

... es geht hier nicht darum wie man etwas machen könnte oder sollte,
dann bräuchten wir uns nicht mit Fehlern rumzuplagen.


Es gibt auch Leute (auf dieser Mailingliste) die eine Codebasis
verwalten die in Jahren gewachsen ist und ihre Anfänge in PHP 3 haben -
da ist es z. B. wesentlich einfacher einmal am Anfang des Script-Aufrufs
für eine saubere Umgebung zu sorgen.

Aber ich weiß - du hättest/hast schon vor Jahren alles richtig gemacht
und kommende Bugs in PHP berücksichtigt - ;-)


-- 
Sebastian