---

Hej alle!

Hvis man vil kunne "sende" variabler fra side til side ved hjælp af links,
f.eks.

http://index.php?variabel=test - er man så nødt til at sætte register
globals = on ?

Giver mit spørgsmål mon mening?

KH
John

---

John Kjoller skrev:

> Hvis man vil kunne "sende" variabler fra side til side ved hjælp af links,
> f.eks.

> http://index.php?variabel=test - er man så nødt til at sætte register
> globals = on ?

Nej, man er aldrig nødt til at sætte det on.

Variablen skal 'modtages' med:

   $variabel = $_POST['variabel'];

men kan i øvrigt kaldes alt muligt andet end $variabel hvis man
vil. Jeg bruger dog altid samme navn.

Med register globals = on vil den viste linje være udført
automatisk - men det betyder jo at man i adresselinjen kan give
en vilkårlig variabel en vilkårlig værdi. Eksempel:

   http://index.php?filename=logfile.dat&action=delete

Nu er det jo ikke sikkert at man lige har brugt netop de to
variable til noget, og så er det harmløst, men hvis hackeren
gætter en variabel rigtigt, kan han lave ballade.

Med register globals = off vil kun de variable som man selv
henter med $_POST[] kunne påvirke forløbet.

Udskift POST med GET hvis det er den metode du vil bruge.

> Giver mit spørgsmål mon mening?

Ja.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:

> Udskift POST med GET hvis det er den metode du vil bruge.

Eller alternativt: brug $_REQUEST for at dække alle
G(et)/P(ost)/C(ookie) variable.

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

On Sun, 16 Jul 2006 13:20:19 +0200, Bertel Lund Hansen
<nospamfilius@lundhansen.dk> wrote:

>> http://index.php?variabel=test - er man så nødt til at sætte register
>> globals = on ?
>
>Nej, man er aldrig nødt til at sætte det on.
>
>Variablen skal 'modtages' med:
>
>    $variabel = $_POST['variabel'];

I tilfældet med ?variabel=test , så er det dog $_GET['variabel'] der
er sat og ikke $_POST['variabel']

>Nu er det jo ikke sikkert at man lige har brugt netop de to
>variable til noget, og så er det harmløst, men hvis hackeren
>gætter en variabel rigtigt, kan han lave ballade.

(forudsat at man i koden uden videre bruger variable, der risikerer
ikke at være sat af scriptet selv)

register_globals dør dog i PHP6, så der er ingen grund til at kode til
andet formål.
--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med valgfri tekst: www.findvej.dk/Nybrogade2,1203?text=Kulturministeriet

---

Peter Brodersen skrev:
> register_globals dør dog i PHP6, så der er ingen grund til at kode til
> andet formål.
Ja, men vi når vil PHP7 eller PHP8 inden webhotelsudbyderne for
opdateret til PHP6. ;)

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

On Sun, 16 Jul 2006 22:33:24 +0200, Dan Storm
<shadyz@_REMOVETHIS_err0r.dk> wrote:

>> register_globals dør dog i PHP6, så der er ingen grund til at kode til
>> andet formål.
>Ja, men vi når vil PHP7 eller PHP8 inden webhotelsudbyderne for
>opdateret til PHP6. ;)

Optimist!

--
- Peter Brodersen
Ugens^WMånedens^WSommerens værktøj - Find vej: www.findvej.dk
Nu med valgfri tekst: www.findvej.dk/Nybrogade2,1203?text=Kulturministeriet

---

Bertel Lund Hansen skrev:
> Variablen skal 'modtages' med:
>
>    $variabel = $_POST['variabel'];
Det er ikke nødvendigt at oprette endnu en variabel med samme indhold.
$_POST['variabel'] kan sagtens bruges igen og igen, og jeg ser ikke
nogen grund til at 'lære' folk at smide mere kode i et script end højst
nødvendigt.
Det er en smagssag om man vil have:
$name = $_POST['name']
$email = $_POST['email']
$website = $_POST['website']
$someinfo = $_POST['someinfo']
$showmethemoney = $_POST['showmethemoney']
$color = $_POST['color']

eller om man bare vil bruge de prædefinerede variabler som i forvejen er
sat.

> Nu er det jo ikke sikkert at man lige har brugt netop de to
> variable til noget, og så er det harmløst, men hvis hackeren
> gætter en variabel rigtigt, kan han lave ballade.
Har man kontrol over sin kode, er det ligegyldigt om man benytter sig af
register_globals eller ej.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

>> $variabel = $_POST['variabel'];
> Det er en smagssag om man vil have:
> $name = $_POST['name']

> eller om man bare vil bruge de prædefinerede variabler som i forvejen er
> sat.

> Har man kontrol over sin kode, er det ligegyldigt om man benytter sig af
> register_globals eller ej.

Altså synes faktisk ikke de to argumenter hænger helt sammen - hvis du
benytter $_POST['variabel'] som reference direkte rundt i din kode har
du vel netop ingen kontrol med dit input?

Jeg synes faktisk man kan argumentere for at det netop _ikke er
ligegyldigt_ om man bruger den ene eller anden metode. I det øjeblik du
aktivt vælger at hente en udefra kommende variabel ind i dit kode-scope
bør du jo netop samtidig lave alle de checks der er nødvendig for at
sikre at indholdet lever op til det forventede.

Og jeg ser det faktisk som både god metodik men også teknik at vænne sig
til (normalt) aldrig direkte i koden at bruge værdier der kommer fra
PHPs SUPERGLOBALS ($_REQUEST, $_GET, $_POST, $_COOKIE - og begrebet kan
udviddes i visse tilfælde til både $_SERVER og $_SESSION globalene også
- specielt den sidste hvis man kører kode afviklet på usikker shared
hosting) - men at man tager sig tid til 1) overveje hvilke variable man
har brug for at overføre gennem hvilke kanaler og 2) hvilket indhold
disse forventes at medbringe.

Der er det generelt smartere (og ofte mere overskueligt) - at bruge:

$variabel = $_POST['variabel']

metoden - da den nemt og sikkert kan extendes med alle dine nødvendige
checks - een gang for alle i din kode.

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

Geert Lund skrev:
> Altså synes faktisk ikke de to argumenter hænger helt sammen - hvis du
> benytter $_POST['variabel'] som reference direkte rundt i din kode har
> du vel netop ingen kontrol med dit input?
Det er vel som man ser på det.

> Jeg synes faktisk man kan argumentere for at det netop _ikke er
> ligegyldigt_ om man bruger den ene eller anden metode. I det øjeblik du
> aktivt vælger at hente en udefra kommende variabel ind i dit kode-scope
> bør du jo netop samtidig lave alle de checks der er nødvendig for at
> sikre at indholdet lever op til det forventede.
Jeg kan sagtens se fordelen i at gøre sådan:

$variabel = mysql_real_escape_string($_POST['variabel']);

istedet for at bruge funktionerne 12 gange i samme samme script. Men jeg
ser stadig intet formål i:

$name = $_POST['name']
$email = $_POST['email']
$website = $_POST['website']
$someinfo = $_POST['someinfo']
$showmethemoney = $_POST['showmethemoney']
$color = $_POST['color']

> Og jeg ser det faktisk som både god metodik men også teknik at vænne sig
> til (normalt) aldrig direkte i koden at bruge værdier der kommer fra
> PHPs SUPERGLOBALS ($_REQUEST, $_GET, $_POST, $_COOKIE - og begrebet kan
> udviddes i visse tilfælde til både $_SERVER og $_SESSION globalene også
> - specielt den sidste hvis man kører kode afviklet på usikker shared
> hosting) - men at man tager sig tid til 1) overveje hvilke variable man
> har brug for at overføre gennem hvilke kanaler og 2) hvilket indhold
> disse forventes at medbringe.
Det handler, efter min mening, stadig kun om at have kontrol over sin kode.

> Der er det generelt smartere (og ofte mere overskueligt) - at bruge:
>
> $variabel = $_POST['variabel']
>
> metoden - da den nemt og sikkert kan extendes med alle dine nødvendige
> checks - een gang for alle i din kode.

Det er da helt okay, hvis du finder det mere overskueligt.
Min kode bliver ikke mindre overskuelig af jeg ikke gør det.

Eksempel:

$input = mysql_real_escape_string(strip_tags($_POST['input']));

if(($_POST['tal']/$_POST['tal']) == 1)
{
   mysql_query("UPDATE table SET description='".$input."' WHERE
no='".$_POST['tal']."'");

}
else
{
   mysql_query("INSERT INTO table (no, description) VALUES ('0',
'".$input."')");
}

ovenstående (hurtig slamkode) finder jeg ikke uoverskueligt på nogen som
helst måde og mener jeg har den kontrol med mine globals som jeg vil have.

Men igen, det er en smagssag.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
> Geert Lund skrev:
>> Der er det generelt smartere (og ofte mere overskueligt) - at bruge:
>>
>> $variabel = $_POST['variabel']
>>
>> metoden - da den nemt og sikkert kan extendes med alle dine nødvendige
>> checks - een gang for alle i din kode.
>
> Det er da helt okay, hvis du finder det mere overskueligt.
> Min kode bliver ikke mindre overskuelig af jeg ikke gør det.
>
> Eksempel:
>
> $input = mysql_real_escape_string(strip_tags($_POST['input']));
>
> if(($_POST['tal']/$_POST['tal']) == 1)
> {
> mysql_query("UPDATE table SET description='".$input."' WHERE
> no='".$_POST['tal']."'");
>
> }
> else
> {
> mysql_query("INSERT INTO table (no, description) VALUES ('0',
> '".$input."')");
> }

Æhov. Ovenstående er jo gabende sikkerhedshuller. Hvordan kan det
nogensinde bruges som et godt eksempel?

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler skrev:
> Æhov. Ovenstående er jo gabende sikkerhedshuller. Hvordan kan det
> nogensinde bruges som et godt eksempel?
Sagde ikke det var et godt _brugbart_ eksempel.
Pointen var egentlig at pointere at jeg ikke ser noget formål med at
smide $_POST['tal'] ind i en fuldstændig identisk variabel.

Igen, eksemplet kan ikke bruges til noget konkret ud over at forklare
det jeg mener.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:
> Michael Zedeler skrev:
>
>> Æhov. Ovenstående er jo gabende sikkerhedshuller. Hvordan kan det
>> nogensinde bruges som et godt eksempel?
>
> Sagde ikke det var et godt _brugbart_ eksempel.
> Pointen var egentlig at pointere at jeg ikke ser noget formål med at
> smide $_POST['tal'] ind i en fuldstændig identisk variabel.
>
> Igen, eksemplet kan ikke bruges til noget konkret ud over at forklare
> det jeg mener.

Klart nok, men hvis du skulle tage højde for injection-angreb, ville det
også være mere oplagt at lave den tildeling, som du måske ikke er så
meget for i starten, blot hvor man altså har checket for grimme ting.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Dan Storm skrev:

> Eksempel:
>
> $input = mysql_real_escape_string(strip_tags($_POST['input']));
>
> if(($_POST['tal']/$_POST['tal']) == 1) {
>    mysql_query("UPDATE table SET description='".$input."' WHERE no='".$_POST['tal']."'");
> }
> else
> {
>    mysql_query("INSERT INTO table (no, description) VALUES ('0', '".$input."')");
> }

> ovenstående (hurtig slamkode) finder jeg ikke uoverskueligt på nogen som
> helst måde

Der er flere anførselstegn at holde styr på end med simple
variable. Det gør den mere uoverskuelig.

Hermed ikke være sagt at du (og 'man') ikke kan finde ud af den.

Jeg ville skrive:

$input = mysql_real_escape_string(strip_tags($_POST['input']));
$tal=$_POST['tal'];

if ($tal/$tal == 1)
   mysql_query("UPDATE table SET description='$input' WHERE no='$tal'");
else
   mysql_query("INSERT INTO table (no, description) VALUES ('0', '$input')");

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen skrev:
> Der er flere anførselstegn at holde styr på end med simple
> variable. Det gør den mere uoverskuelig.
Det er jeg ked af at det er for dig, men for mig finder jeg det mere
overskueligt og sikkert på den måde.

> Hermed ikke være sagt at du (og 'man') ikke kan finde ud af den.
Point taken.

> Jeg ville skrive:
>
> $input = mysql_real_escape_string(strip_tags($_POST['input']));
> $tal=$_POST['tal'];
>
> if ($tal/$tal == 1)
>    mysql_query("UPDATE table SET description='$input' WHERE no='$tal'");
> else
>    mysql_query("INSERT INTO table (no, description) VALUES ('0', '$input')");
>

Det ved jeg godt du ville. Jeg synes bare ikke der er noget formål med
$tal = $_POST['tal'] men for dig er det jo mere overskueligt og andet er
der ikke i det.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Bertel Lund Hansen wrote:
> Dan Storm skrev:
>
>
>>Eksempel:
>>
>>$input = mysql_real_escape_string(strip_tags($_POST['input']));
>>
>>if(($_POST['tal']/$_POST['tal']) == 1) {
>>   mysql_query("UPDATE table SET description='".$input."' WHERE no='".$_POST['tal']."'");
>>}
>>else
>>{
>>   mysql_query("INSERT INTO table (no, description) VALUES ('0', '".$input."')");
>>}
>
>
>>ovenstående (hurtig slamkode) finder jeg ikke uoverskueligt på nogen som
>>helst måde
>
>
> Der er flere anførselstegn at holde styr på end med simple
> variable. Det gør den mere uoverskuelig.
>
> Hermed ikke være sagt at du (og 'man') ikke kan finde ud af den.
>
> Jeg ville skrive:
>
> $input = mysql_real_escape_string(strip_tags($_POST['input']));
> $tal=$_POST['tal'];
>
> if ($tal/$tal == 1)

Argh. Der har vi den igen. Det er altså noget værre snask.

Jeg skrev oprindeligt en posting, hvor jeg havde overset $tal/$tal.

For det første er der en grund til at der er lavet funktioner som
checker om noget er et tal.

For det andet mener jeg at man skal lade være med at blande
valideringslogik og forretningslogik. Et hvert pænt script bør være
struktureret sådan at man i starten roder alle indkomne parametre
igennem for at checke at de indeholder gyldige værdier. Hvis det ikke er
tilfældet, er jeg tilhænger af at man blot ikke gør noget, frem for at
prøve at rette op på situationen. Der er sjældent nogen tvivl om at det
skyldes at nogen fifler med scriptet, så hvorfor overhovedet prøve at
imødekomme sådan nogle forespørgsler? Det er klart enklere at checke om
data opfylder nogle relativt strenge krav og blot afvise forespørgslen,
hvis det ikke er tilfældet, frem for at prøve at vaske de indkomne
parametre, så man måske kan udføre et eller andet alligevel.

Dernæst - når alt er chekcet og klart, kan man så begynde at udføre
foretningslogik, så som at hælde ting i en database. Hvis scriptet er så
omfattende at det ikke kan struktureres sådan, er det som regel tid til
at dele scriptet i flere, mindre selvstændige scripts.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler skrev:

> Argh. Der har vi den igen. Det er altså noget værre snask.

Ja, men koden er ligegyldig i det her eksempel.

> Jeg skrev oprindeligt en posting, hvor jeg havde overset $tal/$tal.

Det illustrerer ganske smukt min pointe.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Michael Zedeler skrev:
>
>>Argh. Der har vi den igen. Det er altså noget værre snask.
>
> Ja, men koden er ligegyldig i det her eksempel.
>
>>Jeg skrev oprindeligt en posting, hvor jeg havde overset $tal/$tal.
>
> Det illustrerer ganske smukt min pointe.

Og min

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
I am less likely to answer usenet postings by anonymous authors.
Visit my home page at http://michael.zedeler.dk/

---

Michael Zedeler wrote:

> Argh. Der har vi den igen. Det er altså noget værre snask.

> For det første er der en grund til at der er lavet funktioner som
> checker om noget er et tal.

[...en del klippet væk...]

> Dernæst - når alt er chekcet og klart, kan man så begynde at udføre
> foretningslogik, så som at hælde ting i en database. Hvis scriptet er så
> omfattende at det ikke kan struktureres sådan, er det som regel tid til
> at dele scriptet i flere, mindre selvstændige scripts.

Jeg er faktisk meget enig!

Og specielt fordi den slags kode:

if ($tal/$tal == 1)
if(($_POST['tal']/$_POST['tal']) == 1)

Ofte har det med at virke efter hensigten når man selv tester - men ofte
netop ikke tager hensyn til input der ikke følger intentionen og
pluselig risikerer man at have kode der opfører sig uhensigtsmæssigt,
uforklareligt eller ser ud til at have en bug.

Det holder ganske simpelt ikke at lave den slags "security through
obscurity" kode. (Begrebet er nok ikke 100% dækkende - men kunne ikke
lige komme i tanke om andet begreb der var mere dækkende - jo, det
skulle så lige være slamkode eller kodesjusk).

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

Dan Storm wrote:

> Eksempel:
>
> $input = mysql_real_escape_string(strip_tags($_POST['input']));
>
> if(($_POST['tal']/$_POST['tal']) == 1)
> {
> mysql_query("UPDATE table SET description='".$input."' WHERE
> no='".$_POST['tal']."'");
>
> }
> else
> {
> mysql_query("INSERT INTO table (no, description) VALUES ('0',
> '".$input."')");
> }
>
> ovenstående (hurtig slamkode) finder jeg ikke uoverskueligt på nogen som
> helst måde og mener jeg har den kontrol med mine globals som jeg vil have.

Ja, det er rimelig hurtig slamkode - og understreger netop bl.a. hvorfor
det er vigtigt at have styr på sit input...

Hvis vi nu extender din kode med nogle få ekstra ting der bliver kørt i
else løkken vil jeg fx allerede nu kunne tvinge din kode til altid at
køre statement 2 i else-løkken.

Hvis jeg sender variablen tal=hej til din kode - vil den 1) fejle med en
division by zero fejl (da der internt ikke kan konverteres til integer)
og 2) jeg tvinger dermed din kode til altid at levere en false som ikke
er lig med 1 - og dermed vil din kode altid køre 2. statement.

Og så er det jo ellers bare om at extende input og andre variable som
ellers måtte blive brugt i det statement.

Hvor imod - du jo burde være brudt ud af din kode allerede inden vi
nåede så langt da du burde have opdaget at $_POST['tal'] ikke har det
forventede indhold (nemlig i dette tilfælde et integer).

Med andre ord - din kode bør slet ikke nå til det punkt hvor der fx
bliver lavet sådanne databasekald i det øjeblik et input ikke har det
forventede indhold.

Det er at have kontrol over sin kode - og input!

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

Geert Lund skrev:
> Ja, det er rimelig hurtig slamkode - og understreger netop bl.a. hvorfor
> det er vigtigt at have styr på sit input...
>
> Hvis vi nu extender din kode med nogle få ekstra ting der bliver kørt i
> else løkken vil jeg fx allerede nu kunne tvinge din kode til altid at
> køre statement 2 i else-løkken.
Det var også formålet? Så længe tallet ikke er 1 (uanset input), så
skulle statement 2 køres.

> Hvis jeg sender variablen tal=hej til din kode - vil den 1) fejle med en
> division by zero fejl (da der internt ikke kan konverteres til integer)
> og 2) jeg tvinger dermed din kode til altid at levere en false som ikke
> er lig med 1 - og dermed vil din kode altid køre 2. statement.
Samme som før.
>
> Og så er det jo ellers bare om at extende input og andre variable som
> ellers måtte blive brugt i det statement.
>
> Hvor imod - du jo burde være brudt ud af din kode allerede inden vi
> nåede så langt da du burde have opdaget at $_POST['tal'] ikke har det
> forventede indhold (nemlig i dette tilfælde et integer).
Samme som før.
>
> Med andre ord - din kode bør slet ikke nå til det punkt hvor der fx
> bliver lavet sådanne databasekald i det øjeblik et input ikke har det
> forventede indhold.
Statement 1 skulle køres hvis $_POST['tal'] var et heltal
Statement 2 skulle køres ved alle andre tilfælde.

Eksemplet kan ikke bruges til noget brugbart. Det var udelukkende for at
fortælle at jeg ikke kan se formålet i at lave to identiske variabler
hvadenten det er en global eller ej.

> Det er at have kontrol over sin kode - og input!
>


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm wrote:

> Det var også formålet? Så længe tallet ikke er 1 (uanset input), så
> skulle statement 2 køres.

Hvorfor så ikke lave et kode check der underbygger dette? Det gør det
nememre for dig senere og evt. andre der skal læse din kode at
gennemskue at det er det du er interesseret i?

$tal = (int) $_POST['tal'];

eller fx:

if ( ctype_digit( (string) $_POST['tal'] ) )
$tal = $_POST['tal'];
else
{ din fejlkode her eller en die() eller $tal = 0 etc. }

Herefter ved du i resten af din kode at du ikke behøver bekymre dig om
indholdet af $tal er korrekt.

Det gør det nemmere at overskue, nemmere for andre at overskue og som
jeg skrev før - gør det nemmere at extende i det øjeblik der kommer
yderligere valideringsregler til hvad $_POST['tal'] må indeholde.

--
Med venlig hilsen
Geert Lund,
www.GLD.dk

---

Geert Lund skrev:
>
> Hvorfor så ikke lave et kode check der underbygger dette? Det gør det
> nememre for dig senere og evt. andre der skal læse din kode at
> gennemskue at det er det du er interesseret i?
Det er korrekt.
> if ( ctype_digit( (string) $_POST['tal'] ) )
> $tal = $_POST['tal'];
> else
> { din fejlkode her eller en die() eller $tal = 0 etc. }
Også en udmærket måde at løse det på.

> Det gør det nemmere at overskue, nemmere for andre at overskue og som
> jeg skrev før - gør det nemmere at extende i det øjeblik der kommer
> yderligere valideringsregler til hvad $_POST['tal'] må indeholde.
Det er selvfølgelig rigtigt - opgaven afhængigt, vil jeg sige.

Ikke desto mindre tror jeg at det er et spørgsmål om holdning og vane,
hvordan man vil løse de enkelte opgaver.



--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!