hvis man bruger mysql_real_escape_string() slipper man så for at skal bruge addslashes() ?
Kan man ikke: mysql_query(mysql_real_escape_string($sql)) ? (har selv et bud på hvorfor ikke, men det ville da være meget smartere frem for at bruge den ved hver eneste value der skal inputtes)
Det man skal gør i dag, er at bruge http://php.net/mysqli med parameters, og glemme alt om sprintf, addslashes, mysql_real_escape_string. Det eneste bøvlede er at få fjernet de "slashes" som PHP selv kan vælge at sætte på input fra form-felter.
Det er bl.a. derfor det er et naturligt krav at stille - sql-injections har jo flere gange givet anledning til sjove episoder. Men det er også for at lade systemet selv holde styr på datatyper - fx programmeringssprog med en dato-type.
Der er 4 fordele ved parameters/prepared statement: 1) du undgår problemer med legale data med ' i f.eks. O'Toole 2) du undgår SQL injection 3) du undgår problemer med dato formater 4) du vil i mange tilfælde få bedre performance
(jeg er ikke helt klar over hvorvidt #3 og #4 gælder for PHP)
Både og - hvis værdien kommer fra et felt i en form (eller querystring, eller cookie), kan der allerede være sat \-ere på, og så gør du dobbelt arbejde.
Der er i virkeligheden langt mindre arbejde - og væsentligt færre bekymringer - ved at bruge mysqli. Det væsentlige arbejde ved programmering ligger ikke i at skrive 'de par tegn', koden består af ;o)
"men sql injections er stadig forhindret." måske - kun måske - hvis du har husket det hver eneste gang. Det slipper man for at tænke på med "vores" metode. Og for en kritisk kunde, vil man kunne "bevise", at der ikke er problemer med sql-injections.
Hvis jeg skulle leve af det eller udover at være pædagog blot var nørdet nok (undskyld på forhånd, men at være nørdet er for mig ikke nedværdigende), så ville jeg nok også benytte mig af mysqli. Eller hvis jeg skulle lære mysql forfra.
Og så skal jeg lige huske at sige til dig, at talfelter også kræver opmærksomhed med din metode - det er også en fin indgang for sql-injektion for folk med skumle hensigter.
"jeg kan nu heller ikke se" - men det sker alligevel en gang imellem. Du har måske tænkt på den direkte vej fra brugeren til tabellen, men måske er der den indirekte vej, hvor data kommer fra et felt i en tabel, og bliver brugt igen i en SQL-sætning.
Men det er inderligt ligegyldigt. Problemet med SQL-injections løses 100%, og uden sved på panden, ved at bruge parameters (eller tilsvarende). Så kan man bruge sine kræfter på resten af systemet.
mysqli og prepared statement beskytter mod teknikken
escape string og addslashes beskytter muligvis mod teknikken - det kan man jo undersøge
SQL injection sker desværre en gang imellem. En af de mest kendte sager var Valus: http://www.computerworld.dk/art/17176 hvor man ved at angive SHUTDOWN i en passende URL kunne få database serveren til at lukke ned !
Jeg forstår til en vis grad, at du synes, det er irriterende at skulle til at lære PHP'e MySQL håndtering om igen og fra bunden (selvom det faktisk langtfra er tilfældet). Det syntes jeg selv ved første øjekast, men blev lynhurtigt meget klogere!
Tro mig (, Arne og Erik - samt utallige andre): Det bliver faktisk meget lettere at kode PHP/MySQL i sidste ende ... og det er ret hurtigt lært ;o)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
