SQL injection

Den her side (almindeligt indhold og kommentare) bør give dig lidt mere syn på sagen (fra begge sider):
http://php.net/manual/en/security.database.sql-injection.php

Derudover:
http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php

Søg efter "PHP MySQL Injection"

glemte at skrive at det skulle være på dansk...

Så begrænser det lidt.

http://phptips.dk/brug_af_mysql_real_escape_string.tip

Og den DK Wikipedia

http://da.wikipedia.org/wiki/SQL_injection

tag et kig på prepared statements.

#5 links??

Nu mangler jeg nok kun: Hvordan kan man se fra side til side hvad man skal skrive og om siden er sikret? Altså på wikipedia bruger de og på phptips.dk

Du kan aldrig vide, hvad der vil virke på en fremmed side, når du ikke har set kildekoden. Hvis man forsøger at lave en SQL injection på en side, vil man derfor typisk forsøge med adskillige koder, der kunne virke.

Det eneste du dog skal være sikker på for at undgå SQL-injections er, at alt indhold i din forespørsel er escaped, dvs. at " bliver lavet om til \" og ' bliver lavet om til \', hvis det da er disse tegn du bruger til at omkrænse data.

Hvis du sikrer dig i mod den slags, så vil du være sikker i mod SQL injections i hvert fald. Måden at gøre det på er at bruge PHP-funktionen mysql_real_escape_string() på alt brugerinput og hvad ellers du putter i din SQL-forespørgsel som du ikke selv har fuldstændig kontrol over.

Okay... Hvor kan man se i kildekoden hvad der vil virke?

SQL-injections er latterligt nemme at undgå: man anvender prepared statements, og indsætter alle værdier med parameters. Man indsætter aldrig (i dette tilfælde i betydningen: ALDRIG) værdier i SQL-sætninger ved konkatenering af strenge.

Ja. Det gjorde ikke spor ondt vel?

Hvis det gjorde lidt ondt, så kan det fordi gamle og håbløse lærebøger og tutorials viser det på en anden måde, og indrømmet: PHP har ikke altid kunnet klare prepared statements. Eller fordi det kræver en anelse mere skrivearbejde.

Til gengæld er det umiddelbart observerbart om en given anvendelse af en SQL-sætning er beskyttet mod SQL-injection.

Enhver der advokerer manuel eller automatisk escaping eller fjernelse af "giftige" tegn, bør hænges op i Rundetårn med hovedet nederst, til bespottelse for den almene befolkning.

(Enkelte strejf af ironisk tilsnit kan forekomme i ovenstående betragtninger, men min erfaring viser at overdrivelse fremmer forståelsen)

http://phptips.dk/brug_af_mysql_real_escape_string.tip
<?php
$username = mysql_real_escape_string($_POST['username']);
$password = mysql_real_escape_string($_POST['password']);

$sqls = "select * from user where user = '$username' and '$password'";
$users = mysql_query($sqls);
?>

Erikjacobsen: Det var en meget hård og kontakt udtale uden en særlig god begrundelse.

Ja, problemet kan løses med prepared statements, men det kan også løses på andre måder. Det er overkill at anvende prepared statements, hvis man ikke har behov for den ekstra funktionalitet, det giver: mulighed for at sende den samme forespørgsel mange gange.

Når du laver et prepared statement, så sender du først dit statement til SQL-serveren, hvorefter du sender dine værdier - det er spild af ressourcer og kan blive en flaskehals i større applikationer.

Derfor er det meget groft at slå så hårdt ned på den gængse anvendelse, når den i langt de fleste tilfælde er mere effektiv!

Til pstidsen vil jeg derfor slutte af med at sige, at der intet er i vejen med de "almindelige" ikke-prepared forespørgseler, hvis man husker at escape sit input.

Erikjacobsen:
Det var da en hård konklusion. Ja, prepared statements har meget godt at bidrage med, men det er bestemt ikke en erstatning for de gænse forespørgsler. Ganske vist kan prepared statements fjerne noget af presset, hvis man ikke selv magter at escape sit input, men alting har en pris.

Prepared statements er meget effektive, hvis man skal udføre den samme forespørgsel mange gange men med forskellige værdier - ellers ikke.

Det der sker, når man laver et prepared statement er, at den først sender selve forespørgslen med placerholders til SQL-serveren, hvorefter man sender de værdier, der skal sættes ind i forespørgslen; man sender altså to forespørgsler til serveren, hver gang man reelt kun udfører én handling. Det kan (ikke overraskende) sagtens skabe et ydelsesproblem og en flaskehals i nogle anvendelse.

Din grove påstand om, at de gænse forespørgsler er så slemme som du nu engang udgiver dem for er helt hen i vejret - dem er der absolut intet i vejen med - i langt de fleste tilfælde vil de tilmed være hurtigere og lige så sikre, så længe man da manuelt husker at escape sit input.

Til pstidsen vil jeg derfor afslutningsvis pointere, at der intet er galt i at lave SQL-forespørgsler som du gør nu, så længe du altid husker at escape dit input.

Det var da godt at Eksperten gad vise mit endelig, nu hvor jeg netop have skrevet det igen. Suk.

#13: Ja der er nogle bugs her på E....

Nå, men jeg savner stadig en måde på at se hvordan man skal lave SQL injection på en fremmede side. Nu lyder det som om jeg skal hacke, men det er fordi at jeg har en bruger på nogle knap så professionelle sider og efter jeg har hørt om SQL injection, frygter jeg om jeg nemt kan hackes der.

Hvis man IKKE kan se hvordan man skal lave SQL injection på en given side, så vil jeg gerne se en liste over nogle man kan prøve.

Det er ikke helt lovligt at gøre sådan (forsøge) og derfor heller ikke tilladte at give udførlig hjælp til at gøre noget sådant på Eksperten (se faq).

Det er jo til at "hacke" min egen bruger...

Men på en side du ikke ejer, derfor er det ikke tilladt.

Så må jeg nøjes med at gøre det på min egen side... Hjælp hertil søges.

???

hallo hallo??????????????????????????????????????????????????????????????

A "Hej - jeg vil gerne lære at bruge det der torrent så jeg kan downloade de nyeste film?"

B "Det er ulovligt, det hjælper vi ikke med her!"

A "Nå, men så vil jeg gerne lære at bruge det der torrent så jeg kan uploade og downloade mine helt egne filer"

... Den tror jeg de færreste her på siden hopper på og det er nok derfor der ikke kommer mere svar på den. Selvfølgelig er det svært at teste for om sikkerheden på ens egne sider er OK hvis man ikke ved hvad man skal beskytte imod (men det har vi dog svaret på, dog skal nok også nævnes fx XSS). Er man usikker på om de sider man benytter er usikre må man enten leve med usikkerheden eller søge andre steder hen.

nå.