Er det sikkert kun at validere brugerinput med Intval før database opslag?

Hvis du har en krystalkugle og kan se 10 aar ud i fremtiden og har checket at du aldrig faar brug for at bruge andet end integers (og at du aldrig skal bruge en anden database end MySQL) saa:
- goer du det paa den maade
- sender mig en kopi af lotto tallene for hver uge fremover

Hvis du ikke har en krystalkugle, saa goer du det ordentligt og skifter til prepared statement.

Jeg bruger allerede prepared statements andre steder, men det var jo så ikke det der var spørgsmålet her. Jeg har ingen krystalkugle, men medmindre vi begynder at tælle i bogstaver i stedet for at bruge tal, så vil det aldrig blive et problem.


Hvordan ville du så hente et tal ud af en GET, rense den for skidt og bruge den i SQL, på en bedre måde, uden ekstra overhead? Samme tal vil meget sjældent blive kaldt, så jeg kan ikke se den store gevinst ved prepared statements i forhold til overstående.

Jeg ville helt klart bruge prepared statement og det tal som parameter.

Den beskytter mod SQL injection.

Ogsaa den dag der tilfoejes et felt mere som der skal skal testes paa.

Arne, jeg kender godt til fordele og ulemper ved prepared statements. Som sagt vil der ikke komme flere felter der skal testes på i fremtiden (de er allerede lavet andet steds og bruger prepared statements). Kan vi ikke forholde os til emnet, intval i stedet?


Hvis intval er sikker, så er eneste forskel ved at bruge en prepared statement en ekstra tur over netværket. Intval er desuden uafhængig af den bagvedliggende database da det er en PHP funktion, så jeg kan ikke se hvorfor du mener det skulle være et problem hvis jeg skifter database en dag.

Mener du prepared statement i sig selv skulle være bedre mod SQL injection end intval? I så fald, hvordan?

Som jeg allerede forklarede i #1 saa beskytter brugen af inval mod SQL injection.

Den er ikke helt funktionel ekvivalent med prepared statement, men forskellen vil saa vidt jeg kan se kun vaere relevant hvis du har et id 0.

Men verden er fuld af eksempler paa:
1) en daarlig udvikler vaelger ikke at bruge prepared statement fordi det ikke er noedvendigt for at beskytte mod SQL injection lige nu
2) en anden daarlig udvikler tilfoejer saa senere noget som aabner op for SQL injection
3) og senere igen bliver sitet hacket via SQL injection

Kode med brug af intval boer ikke slippe gennem code review. Det er en ommer.

SQL'en er MySQL specifik fordi du har '' omkring et tal.

I andre databaser vil det give en fejl at sammentligne et tal felt med en streng.

Jeg ved ikke hvad jeg havde forventet af eksperten. Heldigvis findes der andre steder at have en god diskussion, hvor man ikke behøver høre på en løftet pegefinger eller filosofisk vrøvl, begge ubegrundet.

Prepared statements er ikke lavet til at beskytte mod SQL injection. Det er en side bonus. Det er en hel del langsommere end mange andre metoder, som f.eks. hex/unhex, der er langt hurtigere og mindst lige så sikkert når man kun skal køre hver specifikt opslag én gang per session.

Utroligt som ekspertens brugere altid kender spørgerens usercase bedre end dem selv...

Prepared statements er den rigtige maade at beskytte mod SQL injection. Det er den mest konsistente maade og den maade som goer det mindst sandsynlig at maintenance programmeoeren laver et stort sikkerhedshul senere.

Der er mange fora paa internettet, men jeg tror ikke at du vil finde et med kompetente folk, hvor du ikke vil blive anbefalet at bruge prepared statement for at besjytte dig mod SQL injection.

Og jeg er meget skeptisk overfor at brugen af prepared statements skulle forringe performance maaleligt.