---

Jeg kom lige til at skrive en lille artikelagtig ting
om et par uhensigtsmæssigheder i PHP, jeg er stødt på
henad vejen.

Den er på engelsk.

http://borderworlds.dk/writings/why_php_is_broken.html

--
Med venlig hilsen
Christian Laursen

---

"Christian Laursen" <xi@borderworlds.dk> skrev:
> Jeg kom lige til at skrive en lille artikelagtig ting
> om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> henad vejen.

det er nok ikke det rette sted at fortælle det - selvom den handler om PHP

Du får alligevel lige en kommentar med på vejen:

Du siger, at PHP er "farligt" fordi uøvede programmører kan lave
sikkerhedshuller (endda gabende) i deres programmer. Der vil jeg så sige, at
hvis de er uøvede, ja så er det nok heller ikke de helt vilde ting de sidder
og gemmer på...


--
|-|$235-|)k - Mickey
http://susie.dk - mickey(at)susie.dk
http://susie.dk/www.tv3.dk.26.05.2001.html

---

"Mickey" <news002@susie.dk> writes:

> "Christian Laursen" <xi@borderworlds.dk> skrev:
> > Jeg kom lige til at skrive en lille artikelagtig ting
> > om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> > henad vejen.
>
> det er nok ikke det rette sted at fortælle det - selvom den handler om PHP

Hvorfor ikke?

De ting jeg skriver har da netop relevans for folk, der programmerer i PHP,
men som måske ikke lige har tænkt over de ting, jeg skriver om.

> Du siger, at PHP er "farligt" fordi uøvede programmører kan lave
> sikkerhedshuller (endda gabende) i deres programmer. Der vil jeg så sige, at
> hvis de er uøvede, ja så er det nok heller ikke de helt vilde ting de sidder
> og gemmer på...

Jeg har set det med mine egne øjne.

--
Med venlig hilsen
Christian Laursen

---

"Christian Laursen" <xi@borderworlds.dk> skrev:


> > det er nok ikke det rette sted at fortælle det - selvom den handler om
PHP
>
> Hvorfor ikke?
>
> De ting jeg skriver har da netop relevans for folk, der programmerer i
PHP,
> men som måske ikke lige har tænkt over de ting, jeg skriver om.

ja - men det er da stadig et opslag ikke ?

> > Du siger, at PHP er "farligt" fordi uøvede programmører kan lave
> > sikkerhedshuller (endda gabende) i deres programmer. Der vil jeg så
sige, at
> > hvis de er uøvede, ja så er det nok heller ikke de helt vilde ting de
sidder
> > og gemmer på...
>
> Jeg har set det med mine egne øjne.

set hvad ? - at det ikke er de vilde ting ?
- eller er det du har set professionelle programmører der bare har klokket
for vildt i det ?


--
|-|$235-|)k - Mickey
http://susie.dk - mickey(at)susie.dk
http://susie.dk/www.tv3.dk.26.05.2001.html

---

"Christian Laursen" <xi@borderworlds.dk> skrev i en meddelelse
news:m3r8wgnfof.fsf@borg.borderworlds.dk...
> "Mickey" <news002@susie.dk> writes:
>
> > "Christian Laursen" <xi@borderworlds.dk> skrev:
> > > Jeg kom lige til at skrive en lille artikelagtig ting
> > > om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> > > henad vejen.
> >
> > det er nok ikke det rette sted at fortælle det - selvom den handler om
PHP
>
> Hvorfor ikke?
>
> De ting jeg skriver har da netop relevans for folk, der programmerer i
PHP,
> men som måske ikke lige har tænkt over de ting, jeg skriver om.

Om de ting du sige er nok så rigtige, er dette sted stadig et forum.
IKKE en plakatsøjle.

>
> > Du siger, at PHP er "farligt" fordi uøvede programmører kan lave
> > sikkerhedshuller (endda gabende) i deres programmer. Der vil jeg så
sige, at
> > hvis de er uøvede, ja så er det nok heller ikke de helt vilde ting de
sidder
> > og gemmer på...

Uanset hvad du laver på nettet er der fare for sikkerhedshuller.
Er man ikke sikker på hvad man laver ( eller gider undersøge det ),
kan man jo betale sig fra webdesign.

>
> Jeg har set det med mine egne øjne.

Det er irrelevant.
Jeg har også set folk justere deres cykelbremse og køre galt.

Stedet her er for PHP-folk der hjælp eller inspiration.

---

Christian Laursen <xi@borderworlds.dk> writes:

> > Du siger, at PHP er "farligt" fordi uøvede programmører kan lave
> > sikkerhedshuller (endda gabende) i deres programmer. Der vil jeg så sige, at
> > hvis de er uøvede, ja så er det nok heller ikke de helt vilde ting de sidder
> > og gemmer på...
>
> Jeg har set det med mine egne øjne.

En uøvet programmør kan lave ged i det i hvilket som helst sprog. Det
argument kan ikke bruges mod PHP specielt.


Jeg er dog enig i at magic_quotes_gpc er ondt og også i at det ville være
rart hvis database interfacet var mere generelt.

--
Finn Nielsen - http://www.zznyyd.dk/

---

On Wed, 20 Jun 2001 02:28:10 +0200, "Christian Laursen"
<xi@borderworlds.dk> wrote:

> Jeg kom lige til at skrive en lille artikelagtig ting om et par
> uhensigtsmæssigheder i PHP, jeg er stødt på henad vejen.

Jeg er enig i det med magic_quotes_gpc. Men ellers så lyder det mest som
et dokument skrevet af en perl-programmør, godt kan lide Perl, og ikke
så godt PHP. Der er i hvertfald ikke nok argumentation til at
benytte et udtryk som "broken".

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> writes:

> On Wed, 20 Jun 2001 02:28:10 +0200, "Christian Laursen"
> <xi@borderworlds.dk> wrote:
>
> > Jeg kom lige til at skrive en lille artikelagtig ting om et par
> > uhensigtsmæssigheder i PHP, jeg er stødt på henad vejen.
>
> Jeg er enig i det med magic_quotes_gpc. Men ellers så lyder det mest som
> et dokument skrevet af en perl-programmør, godt kan lide Perl, og ikke
> så godt PHP.

Det er korrekt, at jeg er glad for Perl, men derudover er PHP da et okay
sprog. Det kunne blot være meget bedre.

> Der er i hvertfald ikke nok argumentation til at
> benytte et udtryk som "broken".

Overskriften blev måske nok lidt barsk, ja.

--
Med venlig hilsen
Christian Laursen

---

"Christian Laursen" <xi@borderworlds.dk> wrote in message
news:m3u21cngf9.fsf@borg.borderworlds.dk...
> http://borderworlds.dk/writings/why_php_is_broken.html

"[all the variables get turned into global variables] has the side effect
that any user can easily pollute your global namespace."

Den forstår jeg ikke... "Any user" - mener du besøgende på sitet, eller
andre udviklere eller hvad? For mig at se skal man have adgang til din
PHP-source for at få adgang til dit globale namespace. Og så synes jeg nu
ikke det er namespaced der er problemet... :)

"However this will not be noticed because the default error reporting level
is by default set too low."

Du er fuldstændig fri til at ændre den. Default er (for mig at se) ganske
fin for begyndere, men for lav til dem der vil lidt mere.

"
1. Disable "register_globals"
2. Enable "track_vars"
3. [set error_reporting to 15]
"

Dette er vældig fint, men også et spørgsmål om personlig smag.

Og så sammenligner du PHP med C og Perl, og ser at det ikke er ens. Er det
noget at brokke sig over? Hvis du vil have det ligesom Perl, og brug Perl i
stedet! Derudover kan jeg godt se at det er lidt træls at den samme ting
fungerer NÆSTEN ens i to sprog. Det kræver lidt ekstra omtanke når man
programmerer i flere sprog. Et simpelt eksempel: Jeg bytter tit rundt på
"<?" (PHP) og "<%" (JSP).

"Then there is the extension mess." Snakker du om PEAR? Anyway, her har du
ret. Databasetingen er en god ide, men i praksis bruger jeg den ikke...

"magic_quotes_gpc", jeg kan godt se din pointe. Jeg synes nu ikke det er så
slemt. Begynderen der ikke gider vide noget om det han laver, får noget der
virker alligevel. At det bliver noget møg-kode er hans problem, slashes er
SLET ikke det eneste. Alle vi andre er frie til at slå det fra.

"Furthermore annoying skilled programmers knowledgable of other languages is
a bad thing." Her synes jeg nu ikke PHP er anderledes end alt andet. Det
minder alt sammen meget om hinanden, men er alligevel ikke helt ens. En
"string" er ikke det samme i alle sprog, ikke engang en "integer" er helt
det samme. Sådan er det bare. Der er forskel på de forskellige sprog. Lyder
faktisk rimeligt logisk, formuleret på den måde...

--
Mvh.

Niels Andersen

---

"Niels Andersen" <niels-usenet@myplace.dk> writes:

> "Christian Laursen" <xi@borderworlds.dk> wrote in message
> news:m3u21cngf9.fsf@borg.borderworlds.dk...
> > http://borderworlds.dk/writings/why_php_is_broken.html
>
> "[all the variables get turned into global variables] has the side effect
> that any user can easily pollute your global namespace."
>
> Den forstår jeg ikke... "Any user" - mener du besøgende på sitet, eller
> andre udviklere eller hvad? For mig at se skal man have adgang til din
> PHP-source for at få adgang til dit globale namespace. Og så synes jeg nu
> ikke det er namespaced der er problemet... :)

Det, jeg mener, er, at enhver besøgende kan lave globale variabler, blot
ved at sende disse med som get-parametre til scriptet.

> "However this will not be noticed because the default error reporting level
> is by default set too low."
>
> Du er fuldstændig fri til at ændre den. Default er (for mig at se) ganske
> fin for begyndere, men for lav til dem der vil lidt mere.

Men er de opmærksomme på det?

> "
> 1. Disable "register_globals"
> 2. Enable "track_vars"
> 3. [set error_reporting to 15]
> "
>
> Dette er vældig fint, men også et spørgsmål om personlig smag.

Det er rigtigt. Jeg synes dog, det burde være default. Så kunne man altid
ændre det, hvis man skulle have lyst.

> "Then there is the extension mess." Snakker du om PEAR? Anyway, her har du
> ret. Databasetingen er en god ide, men i praksis bruger jeg den ikke...

PEAR forsøger at kompensere for noget af det rod, der er bygget ind i PHP,
men hvor mange er i praksis opmærksomme på, at det findes?

Mht. til databaseabstraktionen har jeg valgt at lave min egen, idet den i
PEAR ikke var god nok, sidst jeg kiggede på den.

--
Med venlig hilsen
Christian Laursen

---

> Det, jeg mener, er, at enhver besøgende kan lave globale variabler, blot
> ved at sende disse med som get-parametre til scriptet.

Ser ikke problemet i det, så længe man har styr på de parametre der er med?
Resten ignoreres bare!

> > 1. Disable "register_globals"
> > 2. Enable "track_vars"
> > 3. [set error_reporting to 15]
> > "
> >
> > Dette er vældig fint, men også et spørgsmål om personlig smag.
>
> Det er rigtigt. Jeg synes dog, det burde være default. Så kunne man altid
> ændre det, hvis man skulle have lyst.

Jaaah, der er så meget man kan diskutere. Man kan altså ikke forvente at alt
kommer som man vil have det skal være så snart man installerer det. Man må
også gøre lidt selv. Så ser ikke et problem? Hvorfor kan du ikke lige så
godt lave det om, istedet for muligvis jeg eller Niels Andersen skal lave
det om?!?

mvh

Johan

---

"Johan" <tcr480@ofir.dk> writes:

> > Det, jeg mener, er, at enhver besøgende kan lave globale variabler, blot
> > ved at sende disse med som get-parametre til scriptet.
>
> Ser ikke problemet i det, så længe man har styr på de parametre der er med?
> Resten ignoreres bare!

Den holdning er tilsyneladende meget udbredt.

Istedet for at lade maskinen checke at alt er godt, overlader man det til sig selv.

Sidst jeg checkede, var mennesker kendt for at begå fejl.

> Jaaah, der er så meget man kan diskutere. Man kan altså ikke forvente at alt
> kommer som man vil have det skal være så snart man installerer det. Man må
> også gøre lidt selv. Så ser ikke et problem? Hvorfor kan du ikke lige så
> godt lave det om, istedet for muligvis jeg eller Niels Andersen skal lave
> det om?!?

Jeg gør blot opmærksom på ting, jeg mener er uhensigtsmæssigheder. Du er velkommen
til at være uenig.

--
Med venlig hilsen
Christian Laursen

---

> Den holdning er tilsyneladende meget udbredt.
>
> Istedet for at lade maskinen checke at alt er godt, overlader man det til
sig selv.
>
> Sidst jeg checkede, var mennesker kendt for at begå fejl.

Jepper, du har helt ret. Men ser ikke et problem i f.eks. man sætter en
parameter på som hedder f.eks. variabel=2

Den bliver alligevel ikke fortolket på serveren eftersom man ikke bruger den
til noget.

Men hvis det er vigtigt at man kun vil have parametre med man selv definerer
er den ikke værrere end at bruge en simpel $QUERY_STRING og tjekke efter
hvilke parametre der er med

> > Jaaah, der er så meget man kan diskutere. Man kan altså ikke forvente at
alt
> > kommer som man vil have det skal være så snart man installerer det. Man
må
> > også gøre lidt selv. Så ser ikke et problem? Hvorfor kan du ikke lige så
> > godt lave det om, istedet for muligvis jeg eller Niels Andersen skal
lave
> > det om?!?
>
> Jeg gør blot opmærksom på ting, jeg mener er uhensigtsmæssigheder. Du er
velkommen
> til at være uenig.

jamen det er jo ikke uhensigtsmæssigt! Det havde været uhensigtmæssigt hvis
man ikke kunne lave om på det. Men eftersom man selv kan vælge hvorledes
error reporting osv. kan indstilles er det ikke en ulempe!

mvh

Johan

---

"Johan" <tcr480@ofir.dk> writes:

> > Den holdning er tilsyneladende meget udbredt.
> >
> > Istedet for at lade maskinen checke at alt er godt, overlader man det til
> sig selv.
> >
> > Sidst jeg checkede, var mennesker kendt for at begå fejl.
>
> Jepper, du har helt ret. Men ser ikke et problem i f.eks. man sætter en
> parameter på som hedder f.eks. variabel=2
>
> Den bliver alligevel ikke fortolket på serveren eftersom man ikke bruger den
> til noget.

Jeg tror, du har misforstået mit budskab. Det er netop denne mulighed kombineret
med, at man ikke bliver advaret om variabler, der bruges uden først at være
initialiseret korrekt, der er farligt.

> Men hvis det er vigtigt at man kun vil have parametre med man selv definerer
> er den ikke værrere end at bruge en simpel $QUERY_STRING og tjekke efter
> hvilke parametre der er med

Jeg kan snildt sende variabler med på andre måde end i QUERY_STRING. Den var
blot et eksempel.

> > > Jaaah, der er så meget man kan diskutere. Man kan altså ikke forvente at
> alt
> > > kommer som man vil have det skal være så snart man installerer det. Man
> må
> > > også gøre lidt selv. Så ser ikke et problem? Hvorfor kan du ikke lige så
> > > godt lave det om, istedet for muligvis jeg eller Niels Andersen skal
> lave
> > > det om?!?
> >
> > Jeg gør blot opmærksom på ting, jeg mener er uhensigtsmæssigheder. Du er
> velkommen
> > til at være uenig.
>
> jamen det er jo ikke uhensigtsmæssigt! Det havde været uhensigtmæssigt hvis
> man ikke kunne lave om på det. Men eftersom man selv kan vælge hvorledes
> error reporting osv. kan indstilles er det ikke en ulempe!

Default-indstillinger bør være sat udfra et sikkerhedsmæssigt og evt.
konservativt syn på tingene. Specielt når man henvender sig til folk, der ikke
alle kan forventes at tænke dybere over disse ting.

Prøv engang ved lejlighed at læse en eller flere sikkerhedsrelaterede
mailinglister og læg mærke til, at der jævnligt dukker exploits op mod
diverse php-scripts som i mange af tilfældende skyldes de ting, jeg har
skrevet om.

--
Med venlig hilsen
Christian Laursen

---

> Jeg tror, du har misforstået mit budskab. Det er netop denne mulighed
kombineret
> med, at man ikke bliver advaret om variabler, der bruges uden først at
være
> initialiseret korrekt, der er farligt.
>
> > Men hvis det er vigtigt at man kun vil have parametre med man selv
definerer
> > er den ikke værrere end at bruge en simpel $QUERY_STRING og tjekke efter
> > hvilke parametre der er med
>
> Jeg kan snildt sende variabler med på andre måde end i QUERY_STRING. Den
var
> blot et eksempel.

Ok, f.eks. POST? men der kan du også sagnes tjekke på hvilke variabler du
smider med... Er der andre?

> > jamen det er jo ikke uhensigtsmæssigt! Det havde været uhensigtmæssigt
hvis
> > man ikke kunne lave om på det. Men eftersom man selv kan vælge hvorledes
> > error reporting osv. kan indstilles er det ikke en ulempe!
>
> Default-indstillinger bør være sat udfra et sikkerhedsmæssigt og evt.
> konservativt syn på tingene. Specielt når man henvender sig til folk, der
ikke
> alle kan forventes at tænke dybere over disse ting.

Nej, for folk der ikke kan finde ud af det, smider ikke en webserver i
luften med adgang til alle. Hvis de gør dette, er det godt nok heller ikke
specielt kloge overhovedet. Så burde de holde sig helt væk fra computere.
Det som "uprofessionelle" brugere primært vil bruge PHP installationen til,
er at smide den op på sin personlige maskine for at lege med PHP, ligesom
jeg f.eks. har på min bærbare, hvor sikkerhedsniveuet er meget lille, da den
heller ikke er connected til internettet men kun bruges når jeg er
hjemmefra, og har lidt der skal klares!

> Prøv engang ved lejlighed at læse en eller flere sikkerhedsrelaterede
> mailinglister og læg mærke til, at der jævnligt dukker exploits op mod
> diverse php-scripts som i mange af tilfældende skyldes de ting, jeg har
> skrevet om.

Er fuldstændig klar over de ting der sker. Og er da også interesseret i det.
Men mener klart du overvurderer problemerne.
Iøvrigt, smid lige et par links til nogle mailinglister omkring sikkerhed i
bl.a. PHP... gerne andre end dem som lists.php.net har

mvh

Johan

---

"Johan" <tcr480@ofir.dk> writes:

> Er fuldstændig klar over de ting der sker. Og er da også interesseret i det.
> Men mener klart du overvurderer problemerne.

Sikkerhed bliver alt for mange steder ikke taget alvorligt nok.

> Iøvrigt, smid lige et par links til nogle mailinglister omkring sikkerhed i
> bl.a. PHP... gerne andre end dem som lists.php.net har

Prøv at kigge på http://www.securityfocus.com/, der burde du kunne finde en
eller flere.

Jeg tror, jeg vil stoppe her.

--
Med venlig hilsen
Christian Laursen

---

On Wed, 20 Jun 2001 12:40:35 +0200, Johan wrote:

> Jepper, du har helt ret. Men ser ikke et problem i f.eks. man sætter en
> parameter på som hedder f.eks. variabel=2
>
> Den bliver alligevel ikke fortolket på serveren eftersom man ikke bruger den
> til noget.

Jo, den bliver fortolket. Den bliver samtidig importeret i dit scripts
namespace.

>> Jeg gør blot opmærksom på ting, jeg mener er uhensigtsmæssigheder. Du er
> velkommen
>> til at være uenig.
>
> jamen det er jo ikke uhensigtsmæssigt! Det havde været uhensigtmæssigt hvis
> man ikke kunne lave om på det. Men eftersom man selv kan vælge hvorledes
> error reporting osv. kan indstilles er det ikke en ulempe!

Jeg tror vi er enige om at ovenstående kan opfattes som om du er uenig i
hvad Christian skriver.
Jeg er tilbøjelig til at give Christian ret på et par punkter (i det
mindste):
- Errorreporting er som udgangspunkt sat for lavt. Om ikke andet, så fordi
man eksempelvis ikke for warnings hvis man laver stavefejl i variabelnavne.
- Post og Get-variable burde ikke ukritisk importeres ind i scriptets
namespace. Hvis eksempelvis man definerer en given variabel inde i en løkke
som $hest .= "string", vil $hest potentielt være "tainted", eller hvad man
nu kalder det i php.

Det gør naturligvis php let at gå til, men jeg vil tillade mig at kalde det
suboptimalt.

--
Søren O.

Running 1736x1302 NI @ 91 Hz

---

"Søren Boll Overgaard" <boll@fw1.dk> wrote in message
news:slrn9j13ak.dqs.boll@treebeard.tolkien.dk...
> Hvis eksempelvis man definerer en given variabel inde i en løkke
> som $hest .= "string", vil $hest potentielt være "tainted", eller hvad man
> nu kalder det i php.

Hvis man ikke INDEN løkken definerer $hest = "" el. lign er man da selv en
hest...

--
Mvh.

Niels Andersen

---

On Wed, 20 Jun 2001 14:12:24 +0200, Niels Andersen wrote:

> Hvis man ikke INDEN løkken definerer $hest = "" el. lign er man da selv en
> hest...

Der er rigtig mange heste det ganske danske (og ikke helt så danske) land.

--
Søren O.

Set a new course. There's coffee in that nebulae.

---

> > Den bliver alligevel ikke fortolket på serveren eftersom man ikke bruger
den
> > til noget.
>
> Jo, den bliver fortolket. Den bliver samtidig importeret i dit scripts
> namespace.

Jaah, men kan ikke se hvad der går galt, med mindre man kluderer totalt i
den?!? Og ting hvor det kan gå galt burde testes inden de går i luften. Så
må indrømme at jeg ikke ser faren!

> Jeg tror vi er enige om at ovenstående kan opfattes som om du er uenig i
> hvad Christian skriver.
> Jeg er tilbøjelig til at give Christian ret på et par punkter (i det
> mindste):
> - Errorreporting er som udgangspunkt sat for lavt. Om ikke andet, så fordi
> man eksempelvis ikke for warnings hvis man laver stavefejl i
variabelnavne.

Hmm, kan diskuteres. Synes det er op til den enkelte bruger. Vil ikke blande
mig I om brugeren vil have warnings pga. fejl. Det må være op til personen
selv. Og folk som ikke har de store erfaringer, laver sjældent koder der
ikke er overskuelige!

> - Post og Get-variable burde ikke ukritisk importeres ind i scriptets
> namespace. Hvis eksempelvis man definerer en given variabel inde i en
løkke
> som $hest .= "string", vil $hest potentielt være "tainted", eller hvad man
> nu kalder det i php.

Hmm, nu kunne jeg heller ALDRIg finde på at lave en $hest .= "string". Hvis
man ikke ved det, er man ikke kompetent nok til at begå sig med php. Man
skal trods alt tænke længere end til sin egen havelåge!
F.eks. skal man heller ikke sætte et textfield til at være maxlength hvis
man ikke også tjekker stringlength inden man smider den ind i en DB... det
er alle sammen små ting man bør vide...

> Det gør naturligvis php let at gå til, men jeg vil tillade mig at kalde
det
> suboptimalt.

Hmm, intet kan være optimalt. Netop derfor er det muligt at nemt lave om på
configurationen! Optimalt kan aldrig laves, med mindre man laver det kun til
en enkel bruger...

mvh

Johan

---

On 20 Jun 2001 11:47:30 GMT, boll@fw1.dk (Søren Boll Overgaard) wrote:

>Hvis eksempelvis man definerer en given variabel inde i en løkke
>som $hest .= "string", vil $hest potentielt være "tainted", eller hvad man
>nu kalder det i php.

.... og hvis man starter hvert script med at slette $filnavn, så er man
heller ikke smart?

Dit eksempel falder jo ind under kategorien med at holde styr på sit
input. Det behøver ikke at have noget med PHP at gøre.

Hvad angår den generelle sikkerhed, ville jeg dog selv være mere tryg
ved at give en nybegynder PHP-adgang (i SafeMode) end at give samme
nybegynder perl-adgang (eller shell-adgang i det hele taget) på min
hygge-linuxdåse.


--
- Pede
Professionel nørd

---

Peter Brodersen <professionel@nerd.dk> writes:

> Hvad angår den generelle sikkerhed, ville jeg dog selv være mere tryg
> ved at give en nybegynder PHP-adgang (i SafeMode) end at give samme
> nybegynder perl-adgang (eller shell-adgang i det hele taget) på min
> hygge-linuxdåse.

Der er jo flere parter, for hvilke sikkerhed er betydende.

Safemode sikrer jo primært udbyderen/administratoren, at gutten, der
har php kørende ikke generer andre end sig selv.

Det, tråden indtil nu har handlet om, er sikkerheden i det php,
ovenstående gut kører i relation til slutbrugerne.

Men jeg er da ganske enig. :)

--
Med venlig hilsen
Christian Laursen

---

Christian Laursen wrote:

> Det, tråden indtil nu har handlet om, er sikkerheden i det php,
> ovenstående gut kører i relation til slutbrugerne.

Det med at importere globals er en ond ting, men i PHP er det ikke lige
så stort et problem som i de fleste sprog da globals ikke er en del af
namespace i funktioner. Det er altså "global" kode der skal bekymre sig
om tainted globals.

function bla() {
   $hest .= "string";
}

er altså beskyttet mod at $hest skulle være sat i globalt scope i
forvejen.

--
Hroi Sigurdsson
Fried ice cream is a reality! -- George Clinton

---

"Christian Laursen" <xi@borderworlds.dk> wrote in message
news:m3y9qncz7d.fsf@borg.borderworlds.dk...
> > "[all the variables get turned into global variables] has the side
effect
> > that any user can easily pollute your global namespace."
> Det, jeg mener, er, at enhver besøgende kan lave globale variabler, blot
> ved at sende disse med som get-parametre til scriptet.

1) Man har lavet noget MEGET dårligt kode, hvis det betyder noget
2) Det kan slåes fra.

> > "However this will not be noticed because the default error reporting
level
> > is by default set too low."
> >
> > Du er fuldstændig fri til at ændre den. Default er (for mig at se)
ganske
> > fin for begyndere, men for lav til dem der vil lidt mere.
>
> Men er de opmærksomme på det?

Ja, hvis man "vil lidt mere". Hvis ikke, er "alle de warnings" bare pisse
irriterende.

> > 1. Disable "register_globals"
> > 2. Enable "track_vars"
> > 3. [set error_reporting to 15]
> Jeg synes dog, det burde være default. Så kunne man altid
> ændre det, hvis man skulle have lyst.

Den helt nye begynder foretrækker det nok på den måde som er default, og det
synes JEG er fint. Vi kan sagtens blive enige om at det ikke er godt i
længden, men som sagt... Hvis man "vil lidt mere" kommer det af sig selv.

> PEAR forsøger at kompensere for noget af det rod, der er bygget ind i PHP,

Nah... Ikke som JEG ser det. Jeg ser PEAR som en bunke UDVIDDELSER til PHP.

> men hvor mange er i praksis opmærksomme på, at det findes?

Der er tre slags mennesker:
1) Dem som kender PEAR
2) Dem som har brug for PEAR, og finder det lige om lidt
3) Dem som ikke har brug for PEAR.

Jeg tror hele diskussionen kan koges voldosmt ned:
Hvis man virkelig vil noget, så læser man manualen og nogle artikler, og så
finder man ud af alt det sjov.
Hvis man ikke vil noget særligt, er det hele alligevel nærmest
ligegyldigt...

--
Mvh.

Niels Andersen

---

On Wed, 20 Jun 2001 13:15:56 +0200, "Niels Andersen"
<niels-usenet@myplace.dk> wrote:


>Jeg tror hele diskussionen kan koges voldosmt ned:
>Hvis man virkelig vil noget, så læser man manualen og nogle artikler, og så
>finder man ud af alt det sjov.
>Hvis man ikke vil noget særligt, er det hele alligevel nærmest
>ligegyldigt...

Jeg tror snarere at christians pointe er noget m. at defaultsettings i
software som har det mindste m. sikkerhedsting at gøre, bør være
konservative.

Af samme grund som man laver whitelists fremfor blacklists.

--
vh
Thomas Jensen, http://pil.dk/

---

"Thomas Jensen - pil.dk" <tj@dev.null> wrote in message
news:h121jtckncejkq5fv4vch0o3agaq8oqdos@4ax.com...
> Jeg tror snarere at christians pointe er noget m. at defaultsettings i
> software som har det mindste m. sikkerhedsting at gøre, bør være
> konservative.

Hvad sikerhedsdelen angår, ca. det samme som jeg mente. :)

> Af samme grund som man laver whitelists fremfor blacklists.

Nu er der jo også noget der hedder for HØJT sikerhedsniveau, selv om det
ikke er så slemt om "for lavt".

Da jeg havde ISDN brugte jeg blacklists i min firewall, det var passende.
Jeg var alligevel ikke på mere end højest et par timer af gangen, og jeg
havde ikke alverden at bryde ind i.
Nu har jeg ADSL, og en server der kører nogle ting og sager. Ved skiftet gik
jeg over til at whiteliste. Jeg bevægede mig et skridt frem, og blev en lidt
mere avanceret netbruger. I den forbindelse læste jeg om sikkerhed, og
tilpassede min firewall efter det.

På samme måde starter man med "Hello World" i PHP, og tilpasser sit niveau
med opgaverne.

De "sikkerhedsproblemer" Christian snakker om har (for mig at se) kun
relevans hvis man beskæftiger sig med noget der overstiger ens evner. Og så
går det alligevel galt...

--
Mvh.

Niels Andersen

---

"Niels Andersen" <niels-usenet@myplace.dk> writes:

> De "sikkerhedsproblemer" Christian snakker om har (for mig at se) kun
> relevans hvis man beskæftiger sig med noget der overstiger ens evner. Og så
> går det alligevel galt...

Alternativt erkender man på et tidspunkt, at uanset hvor gode ens evner ellers
måtte være, laver man fejl fra tid til anden.

Om det tidspunkt så først kommer, efter at en eller anden har ændret vigtige
data i ens database er så spørgsmålet.

--
Med venlig hilsen
Christian Laursen

---

"Christian Laursen" <xi@borderworlds.dk> wrote in message
news:m3r8wf732q.fsf@borg.borderworlds.dk...
> > De "sikkerhedsproblemer" Christian snakker om har (for mig at se) kun
> > relevans hvis man beskæftiger sig med noget der overstiger ens evner. Og
så
> > går det alligevel galt...
>
> Alternativt erkender man på et tidspunkt, at uanset hvor gode ens evner
ellers
> måtte være, laver man fejl fra tid til anden.

Nu snakker du jo om noget HELT andet...

--
Mvh.

Niels Andersen

---

On Wed, 20 Jun 2001 10:50:14 +0200, "Christian Laursen"
<xi@borderworlds.dk> wrote:

> Det, jeg mener, er, at enhver besøgende kan lave globale variabler,
> blot ved at sende disse med som get-parametre til scriptet.
Det kan nu være ret praktisk. Der er dog naturligvis folk, der ikke
forstår det, og som derfor introducerer potentielle problemer. Man kan
slå det fra, hvis man har lyst.

> PEAR forsøger at kompensere for noget af det rod, der er bygget ind i
> PHP
Du sammenligner indirekte med Perl. Hvis ikke perl er en rodebunke af et
sprog, så ved jeg ikke, hvad der er rodet.

> men hvor mange er i praksis opmærksomme på, at det findes?
Måske ikke så mange endnu. Jeg kan tale for mig selv, og jeg bruger PEAR.

> Mht. til databaseabstraktionen har jeg valgt at lave min egen, idet den
> i PEAR ikke var god nok, sidst jeg kiggede på den.
Virker fint for mig. Ingen af de andre abstraktions-lag var gode nok for
dig, så du skrev ét selv? - Det tyder for mig at se på, at du har svært
ved at genbruge andres kode.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Christian Laursen" <xi@borderworlds.dk> skrev i en meddelelse
news:m3u21cngf9.fsf@borg.borderworlds.dk...

> Jeg kom lige til at skrive en lille artikelagtig ting
> om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> henad vejen.

Jeg er fuldstændigt enig, både ang. sikkerhed, og "dårligt design" ...
Men følger man de punkter du har skrevet op, synes jeg at PHP er et rigtigt
dejligt sprog.

Når disse instillinger så er foretaget er det eneste der irriterer mig lidt,
navngivningen af funktioner, og argumenters placering.
Fx. burde substr() hedde str_sub(), eller også skulle str_replace() hedder
replacestr(). Efter min mening burde argumenternes placering også være ens,
fx. sådan at i streng-funktioner, var "høstakken" første argument, og
"nålen" andet.

Just my 2 cents :)

--
Mvh. Jonas Delfs, http://delfs.dk

"Rigtige mænd scorer på ICQ" -Christian Jørgensen

---

"Jonas Delfs" <jonas@nospam.delfs.dk> skrev i en meddelelse
news:9gqcbb$66e$1@sunsite.dk...
> "Christian Laursen" <xi@borderworlds.dk> skrev i en meddelelse
> news:m3u21cngf9.fsf@borg.borderworlds.dk...
>
[snip]
> Fx. burde substr() hedde str_sub(), eller også skulle str_replace()
hedder
> replacestr(). Efter min mening burde argumenternes placering også være
ens,
> fx. sådan at i streng-funktioner, var "høstakken" første argument, og
> "nålen" andet.

Ja, dette er lettere irriterende, men skyldes faktisk at str_replace
ikke er "tænkt" som en
str* funktion, men som en letvægtsudgave af ereg_replace() , derfor _ og
derfor den "omvendte" parameter liste.

MVH Per Thomsen,
http://www.pert.dk/

---

Christian Laursen wrote:

> Jeg kom lige til at skrive en lille artikelagtig ting
> om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> henad vejen.
>
> Den er på engelsk.
>
> http://borderworlds.dk/writings/why_php_is_broken.html

Jeg har lige en lille personlig tilføjelse:
Bitwise operationer på tal som ikke kan indeholdes af signed int virker
ikke (specielt belastende når man skal lave ip kalkuleringer).

$a = 3648315905 // 217.116.226.1
$a >> 1 == -1073741824
$a += 100
$a = 3648316005
$a >> 1 == -1073741824
$a = 100
$a >> 3 == 12

--
Hroi Sigurdsson
Fried ice cream is a reality! -- George Clinton

---

Hroi Sigurdsson <hroi@asdf.dk> writes:

> Christian Laursen wrote:
>
> > Jeg kom lige til at skrive en lille artikelagtig ting
> > om et par uhensigtsmæssigheder i PHP, jeg er stødt på
> > henad vejen.
> >
> > Den er på engelsk.
> >
> > http://borderworlds.dk/writings/why_php_is_broken.html
>
> Jeg har lige en lille personlig tilføjelse:
> Bitwise operationer på tal som ikke kan indeholdes af signed int virker
> ikke (specielt belastende når man skal lave ip kalkuleringer).

Det var faktisk aktuelt her så sent som i går eller forgårs.

Men egentlig er det vel mere en manglende feature, at man ikke kan have
heltal uden fortegn, end en egentlig fejl.

Måske skulle man bare submitte et patch...

--
Med venlig hilsen
Christian Laursen

---

Christian Laursen wrote:

> > Bitwise operationer på tal som ikke kan indeholdes af signed int virker
> > ikke (specielt belastende når man skal lave ip kalkuleringer).
>
> Det var faktisk aktuelt her så sent som i går eller forgårs.
>
> Men egentlig er det vel mere en manglende feature, at man ikke kan have
> heltal uden fortegn, end en egentlig fejl.

Jeg vil mene at det er en buggy implementation af bitwise ops, ikke en
manglende feature. De definerer nogle operationer som ikke kan håndtere
sin egen gummi-int type. Ikke særligt konsekvent IMHO.

Perl og Ruby klarer det f.eks. fint:

$ perl -e 'print 3648315905 >> 1'; echo
1824157952
$ ruby -e 'puts 3648315905 >> 1'
1824157952

--
Hroi Sigurdsson
Fried ice cream is a reality! -- George Clinton

---

In article <m3u21cngf9.fsf@borg.borderworlds.dk>, "Christian Laursen"
<xi@borderworlds.dk> wrote:

> Jeg kom lige til at skrive en lille artikelagtig ting om et par
> uhensigtsmæssigheder i PHP, jeg er stødt på henad vejen.

Jeg har skrevet en lille artikel om et par fede ting i Ruby

Ang. artiklen kan jeg kun være ganske enig i dine synspunkter omkring den
forurening af det globale namespace og deraf følgende sikkerhedsrisiko
som get/post/cookie variabler introducerer. Det løses dog relativt nemt
vha. konfiguration. Hvad standardinstillingerne skal være, er dog en
anden diskussion (i et andet forum).

/A

---

Anders Johannsen wrote:

> Jeg har skrevet en lille artikel om et par fede ting i Ruby

Hvor?

--
Hroi Sigurdsson
Fried ice cream is a reality! -- George Clinton