[PHP] Register globals problemen

[maartenba]

Op het bedrijf waar ik nu terecht ben gekomen, wordt alles in PHP geprogrammeerd. Na een korte audit van de serverconfiguratie, blijkt o.a. dat de register_globals aan staat.

De systeembeheer-afdeling wil die setting nu op "off" gaan zetten, probleem is dat er hier nog x-tig applicaties draaien waarbij geen gebruik gemaakt wordt van de arrays $_GET, $_POST, ...

Nu zijn er een aantal opties om alle scripts te gaan editeren om toch gebruik te maken van die variabelen:

• Alles lekker nalezen en vervangen waar nodig (veel kans op fouten / overslaan van een variabele)
• Register globals op off zetten, en debuggen maar... (tevens veel kans op overslaan van een variabele)
• Een extract() van de $_GET, ... arrays, maar daar hou je het security-gat gewoon open...

Probleem van alle 3: het zijn omslachtige manieren...

Zijn er tools voor die dit kunnen nakijken? Is er in PHP een functie die, zonder postbacks te doen, kan zeggen welke variabelen GET/POST/COOKIES... zijn, en welke gewone? Na een korte zoektocht op GoT en Google niets gevonden dat nog een 4de mogelijkheid kan zijn.

[Janoz]

Ikzelf zou een combinatie van die drie voorstellen. Ten eerste een testopstelling maken met globals off en hierin de verschillende applicaties deployen. Vervolgens kijken welke applicaties nu nog intensief in ontwikkeling zijn en deze langzaam gefaseerd overzetten. Hierin eerst de boel extracten en vervolgens onderdeel voor onderdeel de reverenties terug brengen. Alle nieuwe ontwikkelingen moeten via de verschillende array's gaan.

Dat het extracten een securitygat is is waar, maar dat gat is niet groter dan wat het nu is. Daarnaast geeft je wel de mogelijkheid om nieuwe ontwikkelingen wel veilig te doen.

Tools die automatisch code analyseren op herkomst van variabelen zijn door het loose typing en het niet declareren in PHP zo goed als onmogelijk.

[frickY]

Dat register_globals aan staat, betekend niet dat de superglobals niet bestaan.
Ze bestaan wel, en worden ook gevuld met de waardes welke erin horen. Echter worden al deze waardes ook in de global scrope gegooid.

Je kunt du seen functie maken welke je $GLOBALS doorloopt en van elke var controleerd of deze de superglobal GET, POST, COOKIE, ENV of SERVER staat.

Toen ik vorig jaar bij mijn huidige werkgever kwam werken was het eerste dat opviel ook het niet gebruiken van de superglobals. Ik gooi in de root van elk project waar ik aan bouw een htaccess bestand met

code:

php_flag register_globals off

om zelf in ieder geval geen gezeik te hebben.

Wat echter wel een probleem voor je kan worden met deze methode is het afhandelen van sessies. De session_register() etc functies zouden namelijk ook niet gebruikt moeten worden wanneer je de SESSION-superglobal gebruikt.

[maartenba]

Dat tools quasi onmogelijk zouden zijn vreesde ik al, omwille van de loose typing...

Ik ga een testopstelling voorstellen waarbij we applicatie per applicatie een htaccess bestand in de root gooien dat de setting op "off" zet, en zachtjesaan debuggen.

Wat bedoel je net met die SESSION-sg, session_start() heb je daar toch nog nodig denk ik?
Verder wordt er gelukkig (voor de conversie dan toch) heel weinig gebruik gemaakt van cookies en sessies, waardoor het vooral $_GET en $_POST zal worden die moeten gezocht worden.

[Bosmonster]

Makkelijker dan alle superglobals te gaan extracten (en je applicaties dus aan te moeten passen) is in alle oude applicaties even een htaccess zetten met register_globals op on om de off van de server te overrulen.

Kun je later altijd per app nog eens kijken of het de moeite is ze om te bouwen.

[ Voor 10% gewijzigd door Bosmonster op 05-12-2005 15:10 ]

[maartenba]

De moeite om we om te bouwen gaat het zeker zijn, toch minstens voor de helft van alle applicaties. Hierop moeten vaak aanpassingen worden gemaakt.

Conclusie van het topic: Alles manueel omzetten of gebruik maken van htaccess overruling van de serverconfiguartie bij applicaties waar omzetting niet nodig is, al dan niet voorlopig.

Wat mij betreft mag er een slotje op, ik ben gesteund qua ideeën

[frickY]

maartenba schreef op maandag 05 december 2005 @ 15:01:
Wat bedoel je net met die SESSION-sg, session_start() heb je daar toch nog nodig denk ik?

Jup, die wel. En dat is de enigste.

Zie ook de notes in de PHP manual op oa. http://nl2.php.net/session_register;

If you want your script to work regardless of register_globals, you need to instead use the $_SESSION array as $_SESSION entries are automatically registered. If your script uses session_register(), it will not work in environments where the PHP directive register_globals is disabled.

(heeft dus betrekkin op het gebruik van session_register)

[ Voor 5% gewijzigd door frickY op 05-12-2005 15:35 ]

[t-x-m]

Misschien een stomme vraag, maar waarom zou je geen $_GET's en $_POST's gebruiken??

[Verwijderd]

T-X-M schreef op dinsdag 06 december 2005 @ 08:59:
Misschien een stomme vraag, maar waarom zou je geen $_GET's en $_POST's gebruiken??

Misschien kom je hier achter wanneer je het topic ook daadwerkelijk leest.

[RedHat]

Verwijderd schreef op woensdag 07 december 2005 @ 08:57:
[...]


Misschien kom je hier achter wanneer je het topic ook daadwerkelijk leest.

Ik heb het topic daadwerkelijk gelezen, maar wat is er niet veilig aan $_GET,$_POST,$_COOKIE ?
Ik kan het namelijk niet vinden.

Na wat research, misschien heb je hier wat aan:

PHP:

if (!isset($_SERVER))
{
   $_GET    = &$HTTP_GET_VARS;
   $_POST    = &$HTTP_POST_VARS;
   $_ENV    = &$HTTP_ENV_VARS;
   $_SERVER  = &$HTTP_SERVER_VARS;
   $_COOKIE  = &$HTTP_COOKIE_VARS;
   $_REQUEST = array_merge($_GET, $_POST, $_COOKIE);
}

niet echt netjes, maar wel werkend denk ik (als ik het probleem goed begreep)

[ Voor 39% gewijzigd door RedHat op 07-12-2005 11:45 ]

[Woy]

Het probleem is ook niet dat het niet veilig is maar dat er in de oude applicaties geen gebruik van gemaakt wordt en dat register_globals dus op on staat.

Als je het topic goed had gelezen zocht de ts een oplossing om deze op off te kunnen zetten zonder dat alle applicaties die al draaien meteen kapot gaan.

[LuCarD]

RedHat schreef op woensdag 07 december 2005 @ 11:39:
[...]

Ik heb het topic daadwerkelijk gelezen, maar wat is er niet veilig aan $_GET,$_POST,$_COOKIE ?
Ik kan het namelijk niet vinden.

Na wat research, misschien heb je hier wat aan:

PHP:

if (!isset($_SERVER))
{
   $_GET    = &$HTTP_GET_VARS;
   $_POST    = &$HTTP_POST_VARS;
   $_ENV    = &$HTTP_ENV_VARS;
   $_SERVER  = &$HTTP_SERVER_VARS;
   $_COOKIE  = &$HTTP_COOKIE_VARS;
   $_REQUEST = array_merge($_GET, $_POST, $_COOKIE);
}

niet echt netjes, maar wel werkend denk ik (als ik het probleem goed begreep)

Dat maakt $_* nog steeds geen superglobal!

[Arto]

ik zou deze bovenaan elk script zetten en dan alle 3 de opties nagaan...
er kan zogoed als geen programma voor bestaan, en al zou die bestaan
zou het soms voor fatale fouten kunnen zorgen, net zoals de mens zelf
maar het loodje in eigen hand hebben is toch een stuk veiliger

PHP:

<?
foreach($_GET as $value => $key)
{
    $$value = $key;
}
?>

[T-MOB]

artorozenga schreef op woensdag 07 december 2005 @ 13:43:

PHP:

<?
foreach($_GET as $value => $key)
{
    $$value = $key;
}
?>

Dat is hetzelfde als PHP's extract(), welk al in de TS genoemd was. In de hand houden is er niet echt bij -> het is net zo lek als register globals.

[Bosmonster]

T-MOB schreef op woensdag 07 december 2005 @ 13:46:
[...]

Dat is hetzelfde als PHP's extract(), welk al in de TS genoemd was. In de hand houden is er niet echt bij -> het is net zo lek als register globals.

Belangrijker is dat dit waarschijnlijk gewoon niet gaat werken. Er gebeurt meer met register_globals dan die GPC variabelen...

Neem sessies bijvoorbeeld of server variabelen.

Enige werkbare manier is dus met htaccess de specifieke sites op 'on' laten staan.

[Arto]

T-MOB schreef op woensdag 07 december 2005 @ 13:46:
[...]

Dat is hetzelfde als PHP's extract(), welk al in de TS genoemd was. In de hand houden is er niet echt bij -> het is net zo lek als register globals.

sorry niet opgelet

en nog een ding, zet de extract functie erin en maak en subdir aan met de oude code die je dan helemaal doorspit en debugd

[Wolfboy]

RedHat schreef op woensdag 07 december 2005 @ 11:39:
[...]

Ik heb het topic daadwerkelijk gelezen, maar wat is er niet veilig aan $_GET,$_POST,$_COOKIE ?
Ik kan het namelijk niet vinden.

Na wat research, misschien heb je hier wat aan:
...
niet echt netjes, maar wel werkend denk ik (als ik het probleem goed begreep)

Dat is meer het omgekeerde (als ik de TS goed begrijp)
Ik denk dat de TS meer heeft aan "grep -r HTTP_GET_VARS *" om alle oude globals te vinden.