Onderwerp: schade door veranderen opties

Sinds enige tijd lek het mij goedkoper om meerdere sites van mij en mijn klanten over te zetten naar 1 hostingprovider. Ik kwam hierbij terecht bij Ithology. Een kleiner bedrijf wat goede prijzen aan bood voor hun services...

Toen ik erbij kwam waren ze net bezig met het veranderen van de servers om gebruik te maken met plesk, geen probleem, maar daardoor wel en lange wachttijd.

Alles was uiteindelijk over gezet en toen kregen hun het idee om wegens veiligheidsoverwegingen de "register globals" maar uit te zetten, waardoor er geen gebruik meer gemaakt kon worden van variabelen in forms.. niet echt fijn dus...want mijn applicaties zijn daar wel op gebouwd.

Met het binnenkrijgen van lege aanvragen kwam ik er achter dat er iets fout zat (IThology nam niet even de moeite om zelf aan te geven dat er opties zijn veranderd) Mijn scripts werken bij ELKE hosting provider, maar bij hen moest het anders en ze beweren dat het zo veiliger is, en dat veiligheid boven alles staat.

ik heb ondertussen veel verlies geleden, ten eerste veel tijd, en klanten die wegbleven door het uitblijven van reactie.

Kan ik IThology hiervoor aansprakelijk stellen? of mag elke provider dit zomaar doen?

gr, mauzz

In princiepe mogen ze het wel zomaar doen, maar het is niet netjes.

Het is inderdaad veiliger, maar het probleem beperkt zich tot de user account zelf (er vanuit gaant dat de server enigzins beveiligd is).
Het is dus het risico van de gebruiker zelf om veilig zijn websites in elkaar te zetten.
Het veranderen van scripts is relatief eenvoudig, maar kan veel tijd kosten.

Ik denk niet dat je de host aansprakelijk kan stellen.

Ik raad je zowiezo om je code zo te maken dat het niet uitmaakt of reg globals aan of uit staat.
Is meteen ook overzichtelijker

Het klopt dat het gebruik van register_globals ietwat onveiliger kan zijn, dat hoeft niet.
Je kan het zelf aanzetten, als je op een linux server (met apache zit) dmv een .htaccess file.
Daarin zet je dan:

php_flag register_globals 1

php_flag register_globals 1 werkt niet altijd. Kán gedisabled worden in Apache, ook uit veiligheidsoverwegingen. Als dat zo is kun je natuurlijk je provider vragen of ze het gewoon weer even aan willen zetten op jouw virtualaccount.

Danny

op het moment dat het niet in de algemene voorwaarden staat en niet duidelijk op papier en het is niet gecommuniceerd staan beide partijen naar mijn idee zwak. welke het zou winnen ligt eraan of duidelijk was of je benadeeld zou worden en of het niet was gebeurd als je het had geweten.

Wij hebben bijvoorbeeld in onze AV staan

9.5 PCextreme is met het oog gericht op behoud en/of verbeteringen van kwaliteit en/of de veiligheid van de dienst gerechtigd haar materiaal en haar dienstverlening aan te passen. Hieronder vallen openingstijden en de software samenstelling van de servers van PCextreme.

Wij denken er zelf ook over om registar_globals uit te gaan zetten in PHP4 aangezien je soms je klanten tegen zichzelf moet beschermen.

zelf zet ik in .htaccess

php_flag register_globals on

werkt prima

auto uit en een optie via htaccess het aan te zetten lijkt me het vriendelijkst

Wellicht een domme vraag, maar wat voor soort schade kan je toebrengen als je dat aan hebt staan? Ik heb het namelijk wel aanstaan.

Bij mij staat het op alle servers uit en ik heb er nog nooit klachten over gehad. Denk dat het vooral aan je scripting ligt of je ergens last van hebt...

<edit>overigens mogen ze dat volgens mij zomaar doen... </edit> :-)

Op het moment staat het bij ons aan, maar bij de nieuwe server zetten wij het wel uit. Maar wij zorgen er i.i.g. wel voor dat alle klanten goed ingelicht worden d.m.v. een duidelijke brief welke eventueel weer doorgegeven kan worden aan de webmaster.

Op het moment dat je aangeeft dat alle variabelen die verstuurd worden veranderd moeten worden:

$variabele => $_POST['variabele']
$variabele => $_GET['variabele']

en je geeft je klanten de tijd om het aan te passen, is er niets aan de hand lijkt mij. Zeker als je je klanten duidelijk maakt dat het belangrijk is i.v.m. de veiligheid.

Origineel geplaatst door mauzz
Alles was uiteindelijk over gezet en toen kregen hun het idee om wegens veiligheidsoverwegingen de "register globals" maar uit te zetten, waardoor er geen gebruik meer gemaakt kon worden van variabelen in forms.. niet echt fijn dus...want mijn applicaties zijn daar wel op gebouwd.

Met het binnenkrijgen van lege aanvragen kwam ik er achter dat er iets fout zat (IThology nam niet even de moeite om zelf aan te geven dat er opties zijn veranderd) Mijn scripts werken bij ELKE hosting provider, maar bij hen moest het anders en ze beweren dat het zo veiliger is, en dat veiligheid boven alles staat.

Als ik jou was zou ik eerst eens je scripts goed gaan bijwerken want blijkbaar doe je totaal niets aan input checking. En verder is het al een hele tijd zo dat het aan wordt geraden om met $_GET/$_POST/etc te werken, kom nou niet aanzetten met dar jouw scripts daar niet op gebouwd zijn want dat had ondertussen al lang zo kunnen zijn.

Dat wil trouwens niet zeggen dat ze het wel even hadden mogen laten weten, al was het maar even een klein berichtje voordat het verandert werd.

Origineel geplaatst door Glenn
Wellicht een domme vraag, maar wat voor soort schade kan je toebrengen als je dat aan hebt staan? Ik heb het namelijk wel aanstaan.

register globals zorgt ervoor dat alle argumenten in de URL als global worden doorgegeven. Als jij dus een variabele $betaald gebruikt om de betaling te checken, en ik gooi in de url ?betaald=ja dan kan ik die check dus omzeilen (tenzij de variabele daarna nog geset wordt natuurlijk)

vooral bij opensource scripts zijn hier veel exploits geweest.

Het is erg irritant. Bij ons staat het aan om maar geen gezeik te krijgen, wat niet zo netjes is. Maar overstap is voor sommige klanten wel een grote klus.

Voor de nieuwe klanten staat het overigens wel uit.

bij ons staat dit ook uit de nieuwe server, klanten kunnen wel een eigen php.ini bestand plaatsen met daar hun php values, offcourse laten wij niet alles toe en houden wij een oogje in het zeil, maar voor bepaalde opensource pakketten zijn er nog geen updates die werken zonder register globals (zoals cubecart).

Eigen code zou ik toch ook zo schrijven dat men dit niet nodig heeft.