[php] achja, die Sicherheit ...

[Yannik Hampe]

Sebastian Mendel wrote:
> 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.
Ich bin mir zwar nicht sicher, ob ich dich richtig verstehe, aber mir 
geht es um sowas:
?var[1234]=wert
Wenn der Hash für 1234 jetzt dem Hash für etwas alphanumerisches ist und 
jemand vesucht diesen key des Arrays zu unseten, dann *peng* hängst du 
wieder an der gleichen Sicherheitslücke... =>rekuriv checken

> 
> 
>>>>>> 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.
> 
Also wäre es doch eine gute Idee den Code beisammen zu halten und nicht 
über die ganze Script länge verteilen.
> 
>>>> 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.
Das hätten wir ja jetzt geklärt. Einfach diese Zeile am Anfang jedes 
Scriptes einfügen und fertig:
array_walk_recursive($_REQUEST,create_function('$a,$b','if 
(is_numeric($a)) exit("nö");'));
Also geht es mittlerweile darum, wie man etwas machen sollte.
> 
> Aber ich weiß - du hättest/hast schon vor Jahren alles richtig gemacht
> und kommende Bugs in PHP berücksichtigt - ;-)
Stimmt... :-).
Naja, es ist wohl klar, dass das etwas schwierig ist. Aber alles, was 
ich soweit an php geschrieben habe ist, soweit ich weiss, nicht für den 
genannten Bug in php anfällig.
Und der Code, der für sowas anfällig ist, ist aus meiner Sicht aus 
anderen Gründen noch ein "schlechter Stil".

Und zu letzt würde ich Norbert's Mail von vorhin nur noch mit einem 
"dito" ("Du sagst es") kommentieren.
  :-).