---

Hej

Er denne SQL 100% sikker mod onde brugere?

Al form for magic_quotes er slået fra.


UPDATE
test
SET
My_Longtext_Field = '". addslashes ($_REQUEST ['x']) ."',
My_Integer_Field = '". addslashes ($_REQUEST ['y']) ."'


Jeg har fået at vide at man kunne undslippe adslashes() på en eller anden
måde, men jeg tvivler og han kunne ikke være mere præcis.

Mvh
Jimmy

---

Jimmy wrote:

> Er denne SQL 100% sikker mod onde brugere?
>
> Al form for magic_quotes er slået fra.
>
>
> UPDATE
> test
> SET
> My_Longtext_Field = '". addslashes ($_REQUEST ['x']) ."',
> My_Integer_Field = '". addslashes ($_REQUEST ['y']) ."'
>
>
> Jeg har fået at vide at man kunne undslippe adslashes() på en eller anden
> måde, men jeg tvivler og han kunne ikke være mere præcis.

tjahh - udover at hele tabellen opdateres og man kan smide html-kode ind
i felterne er den vel fin...

Mvh Tommy

---

On Sun, 24 Oct 2004 00:25:46 +0200, Jimmy wrote:

> Jeg har fået at vide at man kunne undslippe adslashes() på en eller anden
> måde, men jeg tvivler og han kunne ikke være mere præcis.

addslashes()'s måde at escape'e strenge på - ved indsættelse af
"\"-tegn - er faktisk ikke-standard. Men da PHP traditionelt ofte har
været anvendt sammen med MySQL (som er en af de DBMSer, der accepterer \
som escape-tegn), er folk ofte blevet foreslået blot at benytte
addslashes() som streng-neutraliseringsfunktion. Men hvis man benytter
"hack'et" i forb. med en hel del andre DBMS-produkter, kan man sagtens
forestille sig, at det går galt.

Ud over, at \ er ikke-standard, er der vist også situationer, hvor
benyttelse af udspekulerede tegnsæt-tricks kan snyde addslashes(?).

Bl.a.[1] derfor synes jeg, at man bør gøre noget andet:

- Benyt prepared statements. - Enten via DBMS-driverens
egen facilitet dertil, eller evt. emuleret i et
DB abstraktionslag. Se fx
http://pear.php.net/manual/en/package.database.db.db-common.prepare.php
eller fx
http://dk.php.net/manual/en/function.oci-parse.php
- Hvis man benytter et DBMS abstraktionssystem (såsom PEAR DB),
så benyt abstraktionssystemets streng-quoting facilitet. Eksempelvis:
http://pear.php.net/manual/en/package.database.db.db-common.quote.php
(Hvis éns PEAR er relativt ny, bør man dog benytte en anden metode,
hvilket siden beskriver.)
- Benyt DBMS-driverens egen, specifikke quote-funktion. Se fx.
http://dk.php.net/pg_escape_string
http://dk.php.net/mysql-real-escape-string

Med andre ord: Efter min mening, er addslashes()-funktionen en af dem, der
burde ryge i en oprydning af PHP. Men det er der næppe nogen, der tør,
fordi den desværre har været anbefalet så systematisk - inkl. af
undertegnede (tidligere) og en side såsom
http://dk.php.net/manual/en/security.database.sql-injection.php


Note 1:
Se også
http://groups.google.com/groups?selm=pan.2004.08.29.11.23.42.556450%40arvin.dk

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

"Troels Arvin" <troels@arvin.dk> wrote in message
news:pan.2004.10.25.10.42.55.816504@arvin.dk...
> On Sun, 24 Oct 2004 00:25:46 +0200, Jimmy wrote:
>
> > Jeg har fået at vide at man kunne undslippe adslashes() på en eller
anden
> > måde, men jeg tvivler og han kunne ikke være mere præcis.
>
> addslashes()'s måde at escape'e strenge på - ved indsættelse af
> "\"-tegn - er faktisk ikke-standard. Men da PHP traditionelt ofte har
> været anvendt sammen med MySQL

Ja, det glemte jeg at nævne. Det er i forbindelse med MySQL at jeg spørger.


> Ud over, at \ er ikke-standard, er der vist også situationer, hvor
> benyttelse af udspekulerede tegnsæt-tricks kan snyde addslashes(?).

Det er den slags jeg søger. Googling har ikke givet mig noget og det ser ud
til blot at være spekulationer, der ikke kan bevises.


> Med andre ord: Efter min mening, er addslashes()-funktionen en af dem, der
> burde ryge i en oprydning af PHP.

Ikke helt forstået.
Den virker jo, og med mindre nogen kan vise den er usikker (sammen med
MySQL) kan jeg ikke se hvorfor den skulle ryge?

Tak for svaret.

Mvh
Jimmy

---

On Wed, 27 Oct 2004 09:35:12 +0200, "Jimmy" <bla@bla.bla> wrote:

>Den virker jo, og med mindre nogen kan vise den er usikker (sammen med
>MySQL) kan jeg ikke se hvorfor den skulle ryge?

Da den er rettet mod mysql, så kan man lige så godt bruge en
tilsvarende mysql-specifik funktion: mysql_real_escape_string()

Der er dog ingen tvivl om at magic quotes er medvirkende til
irritationen mod addslashes(). Reelt set har vi nu en funktion, der er
rettet mod mysql, men alligevel skal omgås, hvis man fx vil bruge
mysql_real_escape_string():

Note: If magic_quotes_gpc is enabled, first apply stripslashes() to
the data. Using this function on data which has already been escaped
will escape the data twice.

I det hele taget holder jeg stadigvæk på at udviklere bør bruge et API
som fx PEAR DB. Med prepare-statements og placeholders er risikoen for
at det går galt langt mindre, og så er vi ude over situationen, hvor
udvikleren skal klippeklistrelime queries sammen, hvilket i første
omgang er en smule smågrimt og sammenrodet.

Fordelen er tillige, at hvis man har brugt PEARs abstraktionslag, og
en dag går opgraderer sin MySQL-server til 4.1, så skal der kun rettes
ét sted (phptype rettes fra mysql til mysqli) for at få PEAR DB til at
gøre brug af MySQL 4.1s indbyggede mulighed for prepare-statements, i
stedet for abstraktionslagets egen kompenserende funktionalitet.

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

"Peter Brodersen" <usenet@ter.dk> wrote in message
news:clnk0i$mn0$1@katie.ellegaard.dk...
> On Wed, 27 Oct 2004 09:35:12 +0200, "Jimmy" <bla@bla.bla> wrote:
>
> >Den virker jo, og med mindre nogen kan vise den er usikker (sammen med
> >MySQL) kan jeg ikke se hvorfor den skulle ryge?
>
> Da den er rettet mod mysql, så kan man lige så godt bruge en
> tilsvarende mysql-specifik funktion: mysql_real_escape_string()

Det er en smagssag.
Jeg vil helst addslashe i det øjeblik jeg henter variablerne fra POST/GET og
derved have kortere og pænere SQL.


> Der er dog ingen tvivl om at magic quotes er medvirkende til
> irritationen mod addslashes().

MQ er i den grad irriterende. Måske fordi jeg ikke har sat mig ordentligt
ind i den, men det er noget jeg slår fra via htaccess så snart jeg kan komme
til det.


> I det hele taget holder jeg stadigvæk på at udviklere bør bruge et API
> som fx PEAR DB. Med prepare-statements og placeholders er risikoen for
> at det går galt langt mindre

Det er helt sikkert. Jeg synes også placeholders er smarte, og de minimerer
i hvert fald SQL injection.


> , og så er vi ude over situationen, hvor
> udvikleren skal klippeklistrelime queries sammen, hvilket i første
> omgang er en smule smågrimt og sammenrodet.

Ja, men det kan dog være nødvendigt. Jeg skriver lige næste gang jeg har
brug for det for at se om man kan komme omkring det på en måde.

Dog savner jeg stadig et konkret eksempel på hvordan addslashes() ikke er
tilstrækkeligt sikkkert, når jeg bruger MySQL...

Mvh
Jimmy

---

On Wed, 27 Oct 2004 09:57:24 +0200, "Jimmy" <bla@bla.bla> wrote:

>> Da den er rettet mod mysql, så kan man lige så godt bruge en
>> tilsvarende mysql-specifik funktion: mysql_real_escape_string()
>Det er en smagssag.
>Jeg vil helst addslashe i det øjeblik jeg henter variablerne fra POST/GET og
>derved have kortere og pænere SQL.

Det var nu ikke så meget det - min tanke var nærmere, at hvis
funktionen alligevel var tænkt på at være vendor-specifik, så kunne
man alligevel tage skridtet fuldt ud.

addslashes() kan dog sikkert bruges til andre ting, fx hvis man fedter
noget javascript sammen eller lignende.

>Dog savner jeg stadig et konkret eksempel på hvordan addslashes() ikke er
>tilstrækkeligt sikkkert, når jeg bruger MySQL...

Jeg har ikke bredt nok kendskab til alle de forskellige tegnsæt, mysql
kommer til at understøtte, men jeg kan tage udgangspunkt i fx tankerne
bag UTF-8.

Lige præcis UTF-8 er så snedigt indrettet, at ethvert multibyte-tegn
udelukkende består af highbit-octets, så en kombination i stil med Ã"
vil aldrig være gyldig. Det kan dog godt være, at der findes andre
tegnsæt, der ikke er lige så snedige, hvor Ã" (eller Ã\ ) betragtes
som ét gyldigt multibyte-tegn. I det tilfælde vil det være et problem,
hvis Ã" konverteres til Ã\" , såfremt Ã\ betragtes som et enkelt tegn,
og backslashen således ikke påvirker det efterfølgende tegn.

Igen, jeg skal ikke kunne sige, om et sådan tegnsæt findes, og om
mysql i så fald implementeret dette. Det kan selvfølgelig være, det
vil dukke op med tiden, omend det normalt vil være uden for en brugers
kontrol at fremtvinge et bestemt tegnsæt i den aktuelle
mysql-connection.

Så intet konkret eksempel, og jeg kan ikke se, at man er i risiko,
hvis man bruger latin1 som client characterset.
--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)

---

On Wed, 27 Oct 2004 09:35:12 +0200, Jimmy wrote:

>> Ud over, at \ er ikke-standard, er der vist også situationer, hvor
>> benyttelse af udspekulerede tegnsæt-tricks kan snyde addslashes(?).
>
> Det er den slags jeg søger. Googling har ikke givet mig noget og det ser ud
> til blot at være spekulationer, der ikke kan bevises.

Der må jo ligesom være en grund til, at MySQL-folkene har tilføjet
funktionen: Man foretager ikke sådanne API-ændringer uden, at det er
godt for et eller andet.

- Men jeg må indrømme, at det er sparsomt, hvad der findes af
informationer om evt. farer ved at benytte mysql_escape_string
i modsætning til mysql_real_escape_string.

På http://education.nyphp.org/phundamentals/PH_storingretrieving.php -
der i øvrigt ser ud som en af de bedre artikler om emnet - skriver de
lidt om det, særligt i fodnoterne.

Hvis emnet i øvrigt interesserer dig, kan du prøve at spørge på en
MySQL-liste, om der er folk, der kan komme med konkrete eksempler på,
hvor mysql_real_escape_string gør en forskel.

Bortset fra det: Mht. addslashes() versus de to andre, så må du dog
indrømme, at der i det mindste er forskel på addslashes og
mysql_escape_string: mysql_escape_string er
1. skrevet specifikt til MySQL, af dem, der må antages
af være eksperterne i MySQL, nemlig MySQL's udviklere.
2. mere grundig end addslashes; google selv på det (der _er_
forskel)

>> Med andre ord: Efter min mening, er addslashes()-funktionen en af dem,
>> der burde ryge i en oprydning af PHP.
>
> Ikke helt forstået.
> Den virker jo, og med mindre nogen kan vise den er usikker (sammen med
> MySQL) kan jeg ikke se hvorfor den skulle ryge?

Du må da i det mindste indrømme, at det er noget sprogligt rod at kalde
en DBMS-specifik funktion med et generisk navn. Der er et antal af den
slags funktioner i PHP, hvor de burde hedde noget mere logisk (eller helt
udgå til fordel for bedre funktioner), men hvor man holder dem i live
grundet bagudkompatibilitet.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Wed, 27 Oct 2004 10:16:46 +0200, Troels Arvin <troels@arvin.dk>
wrote:

>Du må da i det mindste indrømme, at det er noget sprogligt rod at kalde
>en DBMS-specifik funktion med et generisk navn.

Det er en svær debat, fordi selvom funktionen måske har været tænkt
specifikt op imod mysql, så er der, som du også selv påpeger, forskel
på funktionerne, og dermed er den alligevel ikke DBMS-specifik.

Jeg har ikke noget imod at funktionen er der (ligesom jeg heller ikke
har noget imod andre søg&erstat-genvejsfunktioner som fx nl2br() ),
men det er ærgerligt, at dens oplagte brug bliver angivet som
databaserelateret, fx:
"Returns a string with backslashes before characters that need to be
quoted in database queries etc.", "An example use of addslashes() is
when you're entering data into a database."

--
- Peter Brodersen

Ugens sprogtip: pc (og ikke PC)