---

Hej.

På mit mit webhotel er "magic_quotes_gpc" sat til on og
"magic_quotes_runtime" sat til off. Jeg forstår det sådan, at det ikke
er nødvendigt at bruge addslashes når noget skal puttes i en mysql db,
men man er nød til at bruge stripslashes når det skal hentes ud igen.

Er det korrekt?

Med venlig hilsen
Jesper Hansen

---

On Mon, 21 Jul 2003 21:02:49 +0200, Jesper Hansen <sebulba_@mailme.dk>
wrote:

>Hej.
>
>På mit mit webhotel er "magic_quotes_gpc" sat til on og
>"magic_quotes_runtime" sat til off. Jeg forstår det sådan, at det ikke
>er nødvendigt at bruge addslashes når noget skal puttes i en mysql db,
>men man er nød til at bruge stripslashes når det skal hentes ud igen.
>
>Er det korrekt?
>
>Med venlig hilsen
>Jesper Hansen

Det er korrekt at du ikke behøver bruge addslashes(), men du behøver
heller ikke bruge stripslashes() når du henter resultatet ud.
MVH Martin S

---

On Mon, 21 Jul 2003 21:58:19 +0200, Martin Sveegaard
<sveegaard@tdcadslFJERN:DETTE.dk> wrote:

>Det er korrekt at du ikke behøver bruge addslashes(), men du behøver
>heller ikke bruge stripslashes() når du henter resultatet ud.
>MVH Martin S

Tak til alle for jeres svar. Jeg fandt ud af at det gik galt netop
fordi jeg brugte addslashes(), da jeg slettede dem fungerede det fint,
kan så stadig ikke helt gennemskue hvorfor Jeg vil lige læse
Peter's lange indlæg, så kan det være jeg bliver klogere.

Med venlig hilsen
Jesper Hansen

---

> På mit mit webhotel er "magic_quotes_gpc" sat til on og
> "magic_quotes_runtime" sat til off. Jeg forstår det sådan, at det ikke
> er nødvendigt at bruge addslashes når noget skal puttes i en mysql db,
> men man er nød til at bruge stripslashes når det skal hentes ud igen.

Hvis dit webhotel har apache, så sæt magic_quotes_gpc til off vha. en
..htaccess fil. Magic quotes er sort magi der må være skabt for at frustrere
php programmører. Hvis du kører din kode på en server hvor der ikke er magic
quotes på, skal det jo gerne være sikkert - så du skal bare sørge for
addslashes på bruger input - fx fra GET og POST.

---

"No1" <cccccccccc@nonexisting.doooooomain.com> wrote in message
news:bfhhqe$pi9$1@sunsite.dk...
> > På mit mit webhotel er "magic_quotes_gpc" sat til on og
> > "magic_quotes_runtime" sat til off. Jeg forstår det sådan, at det ikke
> > er nødvendigt at bruge addslashes når noget skal puttes i en mysql db,
> > men man er nød til at bruge stripslashes når det skal hentes ud igen.
>
> Hvis dit webhotel har apache, så sæt magic_quotes_gpc til off vha. en
> .htaccess fil. Magic quotes er sort magi der må være skabt for at
frustrere
> php programmører.

Forklar, forklar
Jeg har selv tænkt over om det egentligt er rart eller et potentielt
sikkerhedshul at magic_quotes er On, men kom aldrog til en fornuftig
konklusion.

Mvh
Jimmy

---

On Mon, 21 Jul 2003 22:55:43 +0200, "Jimmy" <nyhedsgruppe@get2net.dk>
wrote:

>Jeg har selv tænkt over om det egentligt er rart eller et potentielt
>sikkerhedshul at magic_quotes er On, men kom aldrog til en fornuftig
>konklusion.

Phew, der er lige så mange meninger og betragtninger, som der er folk.
Her er et par betragtninger fra min side. Langt indlæg, men
konsekvensen for kodemiljøet er oigså kompliceret.

magic_quotes redder sikkert en del tilfælde, der ellers kunne have
gået galt, for helt nye PHP-folk, der ikke er vant til
database-arbejde, datavalidering, etc. - folk, som bare kaster folks
variable ind i en mysql_query() uden at tænke på hvordan den endelig
query ser ud.

Her vil man kunne mene, at uden forståelse for denne funktionalitet,
så vil brugeren uden magic_quotes risikere database-fejl (eller
kompromittering), og med magic_quotes risikere lidt grimt output til
brugeren nu og da. Af de to tilfælde er sidstnævnte nok mest at
foretrække - hvis man kigger strengt isoleret på det.

Med tiden kan problemet opstå, at brugeren føler sig unødigt "sikker".
Brugeren lærer måske hvad magic_quotes gør, og bekymrer sig derfor
ikke om at validere sin data, men tænker blot at "magic_quotes sørger
for at folk ikke kan hælde data i mine queries". Dette kan dog
stadigvæk være et problem med dårligt udformede queries i stil med:
<?php
mysql_query("SELECT kontonummer FROM tabel WHERE pinkode = $pinkode");
?>
(bemærk at der ikke er ' rundt om $pinkode - det giver så problemet)

Selv hvis brugeren kan forestille sig query'en inde i hovedet, så
bliver man måske vant til at alle variable altid vil være addslash'et.
Det går så galt, selv efter brugeren har brugt PHP i flere år, når
noget data, der skal indsættes i en database, lige pludselig kommer
fra en fil, fra et andet website (hentet med fopen() eller
fsockopen()) eller fra et databaseopslag - så er tanken om at køre
addslashes() på sine variable måske brugeren så fjern, at han ikke
tænker over det i lige præcis dette tilfælde.

magic_quotes er så selvfølgelig også et problem i alle de andre
tilfælde, hvor man skal bruge variable, men ikke lige præcis smide dem
i en mysql-database. Fx hvis man skal smide dem i en Oracle-database,
outputte dem på skærmen, gemme dem i en fil, submitte dataen videre
via fsockopen(), og så fremdeles. I mange af de tilfælde skal man
først køre stripslashes() for at komme tilbage til udgangspunktet, og
derefter gøre noget passende for at behandle dataen til den videre
funktionalitet. Skal dataen outputtes på en webside, skal man normalt
bruge htmlspecialchars() derpå. Skal dataen i en Oracle-database, skal
den escape's på en anden måde (eller man skal indstille sin Oracle til
det). Skal dataen ind i en URL, man får PHP til at requeste, så skal
man måske hælde rawurlencode efter dataen.

Her er det altså irriterende, at man ved variablen altid skal gå
tilbage og i en anden (eller tredje eller fjerde eller..) retning. Det
kan let blive et htmlspecialchars(stripslashes($data)) eller
rawurlencode(stripslashes($data))-helvede, før man får sat det i
system.

magic_quotes rykker en verden (mysql's) tættere på, men samtidig
rykker man længere væk fra alle de andre verdener (som vist i
ovennævnte eksempler), hvilket måske er en mærkelig prioritering. Det,
der fra starten af, var behov for, var et abstraktionslag, så man ikke
skulle bekymre sig så meget om forskellige databasers virkemåde.

Perl-verdenen har brugt database-abstrationslag længe, og PEAR har
også et acceptabelt - her bruger man ganske enkelt placeholders, og så
bliver dataen behandlet, som den nu skal behandles. Fx:

<?php
// For eksempel
$sth = $db->prepare("SELECT id FROM tabel WHERE efternavn = ?");
$result = $db->execute($sth, 'Petersen');
// eller
$efternavn = "Petersen";
$sth = $db->prepare("SELECT id FROM tabel WHERE efternavn = ?");
$result = $db->execute($sth, $efternavn);
?>

Vi skal således ikke bekymre os om at craft'e/"sammensætte" en query
eller på anden måde lege rå query-snedker. Ovenstående har så også den
fordel, at folk ikke laver oplagte misforståelser (som fx myten med
"Man skal bruge addslashes() når man lægger data ind i databaser, og
stripslashes() når man hiver den ud igen" - det er en misforståelse om
hvad addslashes' funktionalitet ifbm. mysql_query() rent faktisk er,
og hvorfor, man overhovedet bruger addslashes()). Kører man uden
magic_quotes, så er det ligemeget, hvor data kommer fra, når man
således bruger PEARs abstraktionslag.

Lige nu er problemet så også, at folk er delte i holdningen. Det
betyder, at skal man lægge kode online, er der en lang række
forholdsregler, inkl. en række
"if (get_magic_quotes_gpc())..."-tilfælde, hvor man så at sige
abstraherer sig ud af en funktion, der kun optræder nogle gange.

"Målet" må være, at komme helt væk fra magic_quotes, addslashes og
stripslashes igen. PEAR og -DBI'et er dog så sent ude ift. PHP's
udvikling, udbredelse og kodeeksempler i miljøet, at det nok er et
sisyfosarbejde at afvænne folk fra at bruge mysql_query direkte.
Dertil kommer alle de tilfælde, hvor udbydere ikke har adgang til
relevante PEAR-pakker, eller hvor brugere selv installerer PHP på
deres Windows-maskine og ikke lige får sat PEAR op i include_path'en i
deres php.ini.

Kigger jeg mine egne gamle filer igennem (dog inkl. masser af
testfiler og eksempel-filer, jeg har banket sammen i løbet af de
sidste 5+ år), finder jeg ikke mindre end 40 tilfælde af addslashes og
224 tilfælde af stripslashes. De tal skal helst ikke stige!

Min konklusionen er desværre ikke så opmuntrende:
magic_quotes har været introduceret i så lang tid, at det fortsat vil
være en ting, for folk, der skriver generiske applikationer, skal have
i baghovedet - altså at funktionaliteten både kan være aktiveret og
deaktiveret. Det hjælper sikkert nye brugere (da PHP og MySQL ofte går
hånd i hånd), men det er en bjørnetjeneste, når det går hen og
irriterer al andet end mysql-funktionalitet.

register_globals er blevet deaktiveret i default-funktionaliteten af
PHP - jeg ved ikke om det samme burde ske med magic_quotes_gpc.
Risikoen er jo, at folk bare aktiverer den igen. De store
webhosting-firmaer har fx heller ikke haft lyst til lige at diktere
overfor et par tusinde kunder, at nu vælger de som den eneste udbyder
at deaktivere register_globals pga. en opgradering, som kunden ikke
selv har planlagt.

Alt i alt har vi tabt :)

--
- Peter Brodersen

---

"Peter Brodersen" <usenet@ter.dk> wrote in message
news:bfhnpv$a0j$1@dknews.tiscali.dk...
> On Mon, 21 Jul 2003 22:55:43 +0200, "Jimmy" <nyhedsgruppe@get2net.dk>
> wrote:
>
> >Jeg har selv tænkt over om det egentligt er rart eller et potentielt
> >sikkerhedshul at magic_quotes er On, men kom aldrog til en fornuftig
> >konklusion.
>
> Phew, der er lige så mange meninger og betragtninger, som der er folk.
> Her er et par betragtninger fra min side. Langt indlæg, men
> konsekvensen for kodemiljøet er oigså kompliceret.


Super - tak for det meget informative og lange indlæg.
Det burde placeres i FAQ'en.

Mvh
Jimmy

---

On Tue, 22 Jul 2003 21:53:08 +0200, "Jimmy" <nyhedsgruppe@get2net.dk>
wrote:

>Det burde placeres i FAQ'en.

Jeg har tilrettet det lidt, og smidt det i FAQ'en. Dog er det, som
nævnt, mere overordnede meta-betragtninger om PHP, der ikke har noget
konkret svar.

Jeg håber dog, det stadigvæk kan bruges for mere end "bare endnu en
mening".

--
- Peter Brodersen

---

On Mon, 21 Jul 2003 21:02:49 +0200, Jesper Hansen <sebulba_@mailme.dk>
wrote:

>På mit mit webhotel er "magic_quotes_gpc" sat til on og
>"magic_quotes_runtime" sat til off.

Det er normalt, ja.

>Jeg forstår det sådan, at det ikke
>er nødvendigt at bruge addslashes når noget skal puttes i en mysql db,

*Forudsat* at lige præcis den data altså kommer udefra, ja. Hvis det
er blevet kastet ind udefra vha. get, post eller cookie, så er
addslashes() kørt på de variable.

Men hvis du fx henter dataen fra en tekstfil (måske på baggrund af et
brugervalg), fra en anden database eller lignende, så er addslashes()
ikke kørt på teksten.

>men man er nød til at bruge stripslashes når det skal hentes ud igen.

Nej, tværtimod. Dataen kommer "ren" ud, som den står i databasen. Med
"magic_quotes_runtime" sat til on, så vil der også her blive kørt
addslashes() på dataen - fx hvis det skal flyttes over i en anden
database.

Selv jeg er ved at være godt træt af magic_quotes_gpc - jeg vil tro at
forsinkelsen på et acceptabelt DBI (som fx PEARs) har givet folk
indgroede vaner og spøjs kode.

--
- Peter Brodersen