On Sun, 19 Dec 2004 15:16:24 +0100, Bertel Lund Hansen
<nospamius@lundhansen.dk> wrote:
>Jeg er ved at opbygge en database der skal styres via PHP og
>HTML. Fra en side med en formular sendes inputtet til en anden
>side (eller den samme) som sammensætter en sQL som den så fyrer
>afsted til en MySQL-database.
>
>Jeg er nu klar over at det setup er åbent for injektion. Hvordan
>garderer jeg mig imod det?
Du har måske på nuværende tidspunkt fundet ud af, at en default PHP
automatisk afvikler addslashes() på al input udefra. Funktionen hedder
"magic_quotes_gpc", og kan rettes i php-konfigurationen, hvis du har
adgang til denne.
I det omfang, at du bruger variable direkte, og i øvrigt quoter
strenge, så er der ingen problemer. Der er heller ikke noget galt med
strenge i stil med .. WHERE id = '{$_REQUEST['id']}' .. - i MySQL,
også selvom id er et talfelt.
Dog, magic_quotes kan være lidt noget hø. For hvis du fx vil bruge
inputtet til at forudfylde et INPUT-felt i en form, fx <input
type="text" name="fornavn" value="Peter" /> , så har du ikke brug for
en addslashed udgave, men en htmlspecialchars'ed udgave - og bliver
derfor nødt til at afvikle
htmlspecialchars(stripslashes($_REQUEST['navn']))
Du kan læse meget mere om magic_quotes-problemstillingen i
<news:bfhnpv$a0j$1@dknews.tiscali.dk>
(hvor længe mon
www.php-faq.dk skal være nede?)
Endnu en gang vil jeg dog gerne slå et salg for at man slår
magic_quotes fra, og så bruger PEAR DB:
http://pear.php.net/manual/en/package.database.db.php
FORDEL #1: Placeholders.
Man behøver ikke at bekymre dig om escape-metoder. Man skal ikke
klippeklistre queries.
$db->query("SELECT name FROM table WHERE id = ?",$_REQUEST['id']);
eller
$sth = $db->prepare("SELECT name FROM table WHERE id = ?");
$res = $db->execute($sth,$_REQUEST['id']);
$res = $db->execute($sth,20);
$res = $db->execute($sth,600);
FORDEL #2: Ingen magic_quotes
Inputtet er rent, og skal ikke altid igennem stripslashes(), uanset
hvad man skal gøre ved det (fx hælde det igennem htmlspecialchars(),
sende inputtet i en mail, indsætte det i et billede i en GD-funktion,
etc.).
magic_quotes kan man dog selvfølgelig godt slippe for uden at bruge
PEAR DB :)
FORDEL #3: Gode kvikfunktioner til simple queries, fx:
$name = $db->getone("SELECT name FROM table WHERE id =
?",$_REQUEST['id']);
eller
$row = $db->getrow("SELECT name, birthday, zip FROM table WHERE id =
?",$_REQUEST['id']);
Der er også getall() (multidimensionelt array), getcol() (evt. som
associativt array), m.m.
I mange tilfælde har man ikke behov for at jonglere med resultatsæt,
men er alligevel kun interesseret i en enkelt værdi. Koden kan blive
mere overskuelig på den måde, og generelt vil man alligevel have glæde
over flere funktioner til behandling af arrays, end specifikke
funktioner til behandling af et resultatsæt.
FORDEL #4: Udbredt API
Skifter man fx fra/til perl, er interfacet velkendt og stort set
identisk.
FORDEL #4b: Database-abstraktion
Skifter man fra MySQL til en anden (nær kompatibel) database, skal man
ikke ændre så meget.
Man skal måske rette MySQL-specifikke funktioner (fx LIMIT og
lignende), men man har ikke vendor-specifikke funktioner mange steder
i koden (fx tusindevis af linjer indeholdende mysql_query() og andre
mysql_*-funktioner).
Andre fremhæver dette som den største årsag til at bruge et
abstraktionslag, omend jeg synes at de andre fordele taler mere for
det.
FORDEL #4c: MySQL-opgraderingsfordele
Selv hvis man har besluttet sig for aldrig at bruge andet end PHP og
MySQL, så kunne man stadigvæk have gjort sig en stor tjeneste ved at
have brugt PEAR DB, når man endelig opgraderer til MySQL 4.1.
Vil man benytte MySQL 4.1s fordele som fx prepared statements, etc.,
kommer man til at skulle rette alle sine mysql-funktionskald fra
mysql_* til mysqli_* og omskrive kode. Hvis man i stedet har benyttet
PEAR DB, skal der kun rettes ét sted for at overgå til
mysqli-funktionerne. Hvis man har brugt prepare-statements i API'et
(hvor API'et blot har emuleret det for MySQL 4.0-servere), vil man
pludselig få den fulde udnyttelse ud af det, når man går over til 4.1
og bruger mysqli.
--
- Peter Brodersen