[php] achja, die Sicherheit ...

[Yannik Hampe]

Sebastian Mendel wrote:
> 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?
Stimmt... Das ist unötig. Also doch über REQUEST iterieren.
> 
> 
>>> 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.
Es sollte die Bösewichte aber interessieren, dass diese Methode mit 
meinem Apache nicht funktioniert und die sich dadran blöde probieren 
können ;-).
Ansonsten muss man eben wissen, welche Trenner sein Webserver eben noch 
akzeptiert.
Aber wie du schon richtig bemerkt hast ist der regex sowieso Zwecklos, 
da er post und cookie-vas nicht betrifft.
> 
> 
>> 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?
so:
bla.php?var[index]=wert
> 
>> 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.
...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...
> 
> 
>> 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?
> 
>