Bekijk Volledige Versie : Register globals aan of uit?
patrickwww
10/04/08, 11:57
Hallo,
Draai op Linux CentOS met Plesk
Veelal krijg ik het verzoek binnen of de "Register globals" aan gezet kan worden....
Wat is jullie reactie hierop qua beveiliging?
Veelal....
Hoe vaak procentueel???
Uit, en de enkeling gewoon aanpassing in .htacces laten maken.
GlobalServe
10/04/08, 12:02
Wij vragen gewoon aan de mensen dit te doen via een .htaccess file.
Veel veiliger :)
patrickwww
10/04/08, 12:02
Hoe vaak procentueel???
Uit, en de enkeling gewoon aanpassing in .htacces laten maken.
Kan je dat toelichen hoe je die aanpassing maakt in .htaccess? En waar vind ik dat bestand? Weet niet hoe Plesk hiermee werkt... Plesk is nieuw voor ons...
GlobalServe
10/04/08, 12:06
Een beetje googelen levert direkt dit op:
Just a quick tip regarding PHP. If you need to override the Register Globals settings in PHP and you don't have access to php.ini then you can typically add a single line to your .htaccess file (or create a .htaccess file and place it in your root web directory)
If you need to turn register_globals on use:
php_flag register_globals 1
If you need to turn register_globals off use:
php_flag register_globals 0
patrickwww
10/04/08, 12:07
Een beetje googelen levert direkt dit op:
Just a quick tip regarding PHP. If you need to override the Register Globals settings in PHP and you don't have access to php.ini then you can typically add a single line to your .htaccess file (or create a .htaccess file and place it in your root web directory)
If you need to turn register_globals on use:
php_flag register_globals 1
If you need to turn register_globals off use:
php_flag register_globals 0
Dus:
php_flag register_globals 1
in een bastand zetten en opslaan als .htaccess dat is alles??
vrij simpel dus
crazycoder
10/04/08, 12:08
Wij vragen gewoon aan de mensen dit te doen via een .htaccess file.
Veel veiliger :)
Veel veiliger is dat ze het brakke stuk script waar dit kennelijk nooit in aan is gepast fixen.
Het is al zeker iets van 4 of 5 jaar bekend dat het standaard op off gaat. Als de scripters die moeite niet nemen moet je jezelf ernstig afvragen wat ze nog meer na hebben gelaten.
Dus:
php_flag register_globals 1
in een bastand zetten en opslaan als .htaccess dat is alles??
vrij simpel dus
// staat dus los van Plesk, is een php setting
// kan goed gaan, oscommerce vraagt nog om een patch b.v.
patrickwww
10/04/08, 12:12
Veel veiliger is dat ze het brakke stuk script waar dit kennelijk nooit in aan is gepast fixen.
Het is al zeker iets van 4 of 5 jaar bekend dat het standaard op off gaat. Als de scripters die moeite niet nemen moet je jezelf ernstig afvragen wat ze nog meer na hebben gelaten.
Ben ik ook helemaal met je eens....
Maar goed.... Ieder zn eigen verantwoording op deze manier...
Daar ging het me om....
En als het nou om een subdomein gaat...
blabla.blablabla.nl
Is dan alleen voor dat subdomein de register globals aan als ik het .htaccess bestand in de root van het sub domein zet? Of staat het dan ook van het hoofddomein aan?
crazycoder
10/04/08, 12:24
Ben ik ook helemaal met je eens....
Maar goed.... Ieder zn eigen verantwoording op deze manier...
Daar ging het me om....
En als het nou om een subdomein gaat...
blabla.blablabla.nl
Is dan alleen voor dat subdomein de register globals aan als ik het .htaccess bestand in de root van het sub domein zet? Of staat het dan ook van het hoofddomein aan?
Leer mij gebruikers kennen. Als de site compromised wordt dan ben jij een slechte provider omdat je jouw zaakjes niet goed voor elkaar zou heb terwijl ze zelf voor een brak script hebben gekozen.
patrickwww
10/04/08, 12:29
Leer mij gebruikers kennen. Als de site compromised wordt dan ben jij een slechte provider omdat je jouw zaakjes niet goed voor elkaar zou heb terwijl ze zelf voor een brak script hebben gekozen.
Ja maar dat is altijd zo... We horen nooit wat we goed doen.... :cool:
topic kan gesloten worden
Als je de register globals aanzet, zorg dan in elk geval dat de exec functies uitstaan. Dus exec, shell_exec, popen, etc. En vooral ook allow_url_fopen uitzetten. Als zo'n site dan insecure is dan kunnen de crackers er nog niet zoveel mee omdat die vaak toch dit soort functies nodig hebben om scripts in het account van je gebruiker te krijgen en uit te voer.
Cyberdevil
10/04/08, 17:18
Voor zover ik weet heeft globals niks te maken met functies als exec enz.
Globals wilt gewoon zeggen dat je variabelen juist moet aanspreken, dus session variabelen met $_SESSION, post met $_POST enz enz.
Voor de veiligheid van php in het algemeen is dit een van de belangrijkste instellingen.
crazycoder
10/04/08, 17:34
Alstu:
http://nl3.php.net/register_globals
Het dwingt om in ieder geval iets netter te schrijven. Ieder beetje deugdelijk in elkaar gezet script zou zo om te bouwen moeten zijn.
Wordt leuk trouwens.. In PHP6 verdwijnt de hele functie! Denk dat we over een goed 1,5 tot 2 jaar wel over zijn op PHP6..
Wat is jullie reactie hierop qua beveiliging?
Dat ze een nieuwere versie van het script moeten nemen en/of een script met dezelfde functionaliteit dat het niet nodig heeft. Kom nou zeg,.. allow_url_fopen en register_globals staan bij mij standaard dicht.
Voor zover ik weet heeft globals niks te maken met functies als exec enz.
Globals wilt gewoon zeggen dat je variabelen juist moet aanspreken, dus session variabelen met $_SESSION, post met $_POST enz enz.
Voor de veiligheid van php in het algemeen is dit een van de belangrijkste instellingen.
Het heeft er toch wel echt mee te maken. Register globals op 'On' opent de deur voor crackers maar dat soort functies geeft ze pas echt power om wat te doen. Een cracker kan bijvoorbeeld variabelen zo aanpassen dat er een remote page geinclude wordt ipv een lokale pagina. Daarom zou ik allow_url_fopen uitzetten. Stap twee is dat die remote page weer code ophaalt en op de server opslaat. Meestal zijn dat een soort toolkits waarmee de cracker direct unix commando's kan uitvoeren en bestanden kan uploaden naar de server om die vervolgens met exec e.d. uit te voeren.
Ik ben het niet eens met de stelling dat het een van de belangrijkste instellingen is voor de veiligheid. Het geeft een schijngevoel van veiligheid. Slechte code is nog steeds op deze manier te misbruiken en helaas schrijft het merendeel van je klanten slechte code. Dat is ook de reden dat dit in PHP6 verdwijnt. Het is een hele "foute" feature geweest die er sowieso niet in zou moeten zitten ;)
Maar vandaar dus dat ik al deze functies uitzet. Alleen over allow_url_fopen hoor ik wel eens wat, maar dan kun je de klant laten zien hoe de curl library werkt, hetgeen een stuk veiliger is.