[php] achja, die Sicherheit ...

[Sebastian Mendel]

Yannik Hampe schrieb:
> 
> Sebastian Mendel wrote:
>> Yannik Hampe schrieb:
>>> Sebastian Mendel wrote:
>>>> schon gelesen?
>>>>
>>>> http://www.hardened-php.net/hphp/zend_hash_del_key_or_index_vulnerability.html
>>>>
>>>> so auf die schnelle würde mir einfallen einfach alle Anfragen mit einer
>>>> Zahl als Namen abzulehnen, oder?
>>>
>>> *les*
>>> Interessanter Bug...
>>> Also ja... Meines Erachtens müsste sowas schützen:
>>> if (preg_match('/[?&][-]{0,1}\d+=/',$_SERVER['REQUEST_URI'])) 
>>> exit('Irgendeine Fehlermeldung');
>>> (Code by Yannik Hampe, with 14-days-money-back guarantee... Use at your 
>>> own risk...)
>> und was ist mit ; anstelle von ?
>> und mit POST und COOKIE?
> Tjo, stimmt... Also vielleicht doch besser:
> foreach(get_defined_vars() as $key =>$v) if (is_numeric($key)) exit('nö');

Zu welchem Zweck muss ich denn z. B. $_ENV und $_SESSION durchlaufen?


>> script.php?var=1;123=fake
>>
>> Wie es ja schon seit Jahren vom W3C empfohlen wird und auch verwendet wird.
> Das ist mir aber neu. Und mein Apache nimmt auch nur &.

DIR neu, DEIN Apache ... interessiert Bösewichte relativ wenig, außerdem
können Paramater in URLs noch ganz anders aussehen. Und externen
Variablen kommen nunmal nicht nur aus der URL.


> Im Zweifelssfall wäre mein regex aber schnell umgeschrieben und die 
> foreach-Schleife sollte es in jedem Fall bringen :-).
>> ein is_numeric über die $_REQUEST keys wäre wohl am praktischsten ...
> Meine Version mit get_defined_vars gefällt mir aber noch besser. Denn 
> wenn Register Globals aus sind, dann sollte es schneller gehen.
> Wobei man natürlich mit einem ini_get auch einfach prüfen kann, ob 
> register_globals an sind und die Prüfung ggf. wegfallen lassen kann.
> 
> 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?

> array_walk_recursive($_REQUEST,create_function('$a,$b','if 
> (is_numeric($a)) exit("nö");'));
>>> 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.


> 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.


-- 
Sebastian