Injection attacks

addslashes() er vel rigeligt :)

stripslashes() den anden vej.

Hvis vi går udfra, du bruger MySQL:

SQL injections undgås ved:

1) Når du skriver en query, skal du bruge ' ' om værdien:

Mindre godt: mysql_query("DELETE FROM users WHERE id = ".$id)

Godt: mysql_query("DELETE FROM users WHERE id = '".$id."'");

2) Alt input skal escapes dvs. karakterer som ' " skal der sættes en \ foran. Dette gør PHP automatisk med input fra post, get, cookies hvis værdien af 'magic_quotes_gpc' er sand i php.ini. Dette er den normalt, men du bør kontrollere dette i dit script (med eksempelvis ini_get), hvis du satser på denne mekanisme. Alternativt kan du gøre det manuelt med addslashes() funktionen.

Så skal SQL injections ikke forekomme.

Endvidere bør du, som du selv er inde på, altid validere gyldigheden af data. Dette har som sådan ikke noget med sql injections at gøre, men sikrer konsistens i din database udfra regler, du selv opstiller.

"Så skal SQL injections ikke forekomme" = "Så kan SQL injections ikke forekomme"

Og nej, du skal ikke gøre noget, når du hiver da ud af databasen igen.

Nej det er IKKE håbløst hvis der er mange felter. det kræver blot ligeså mang linier med tests.

if( ! is_numeric( $talfelt ) ) {
    echo "Ja der står søreme et tal i 'talfelt'.";
}

se også de andre check funktion på siden: http://dk.php.net/manual/en/function.is-numeric.php

mvh JakobA

mercur8's virker ligeså godt. men derfor er vi alligevel død-ueninge. Jeg synes det er 'syndigt' at bruge mySQL's streng-til-tal konvertering til noget den ikke er beregnet til.

googolplex & mercur8....> Så blev jeg lidt klogere.
Lige for at sikre mig at jeg har forstået det hele rigtigt.
Såfremt min udbyder ikke har 'magic_quotes_gpc' slået til, bruger jeg addslashes, stripslashes og '' uden om mine værdier i en query.
Ellers kan jeg "nøjes" med at bruge '' uden om mine værdier?

jakoba....> Hvis jeg har et felt hvor der skrives et referat, vil det da være et større arbejde at sikre sig, hvis altså det skal ske ved hjælp at validering??

jakoba: Åh nej, nu ikke igen :) Jeg siger jo HVER GANG, at man OGSÅ skal validere sit input. Livrem og seler. Og gør du iøvrigt ikke de ting (2), jeg nævner får du (uanfægtet validering) fejl, hvis du indsætter en streng, der indeholder '.

googoplex: Hvis 'magic_quotes_gpc' ikke er slået til, skal du anvende addslashes når du indsætter og stripslashes når du skriver ud.

hvis feltet er tekst skal der aæigeveæ '-er om for at SQL kan se at det er en streng. Der er der kun risiko fo injection hvis du gemmer værdien i en .php fil, ikke hvis du gemmer den i en database.

aæigeveæ  ==  alligevel

Rettelse:

googoplex: Hvis 'magic_quotes_gpc' ikke er slået til, skal du anvende addslashes når du indsætter.

(du skal i denne forbindelse aldrig bruge stripslashes)

Læs iøvrigt: http://www.owasp.org/documentation/guide

The OWASP Guide to Building Secure Web Application and Web Services has become staple diet for many web security professionals over the last 18 months the initial version 1.0 has now been downloaded over 2 million times. It forms the basis for corporate web security policies for several Fortune 500 companies.

The Guide is a aimed at architects, developers and auditors and is a comprehensive manual for designing, developing and deploying secure web applications.

jakoba skrev:
"hvis feltet er tekst skal der aæigeveæ '-er om for at SQL kan se at det er en streng. Der er der kun risiko fo injection hvis du gemmer værdien i en .php fil, ikke hvis du gemmer den i en database."

Tror ikke jeg forstår hvad du mener. Hvis jeg har:

$streng = "davs' du";

mysql_query("INSERT INTO foo SET streng = '".$string."'");

Får jeg da en fejl.

Ja den situation kræver addslashes, men hvad har det med injection at gøre?

Intet. Det var blot om en kommentar om, at vi da ikke kunne være så uenige. Jeg mener, input skal jo escapes under alle omstændigheder.

Så altså for at opsummere. Step 1 kan udelades, hvis man ved validering (eksempelvis is_numeric) har sikret sig, at man indsætter et tal.

mercur8: Jeg har følgende liggende:

function my_addslashes($string)
{
    if (!get_magic_quotes_gpc())
    {
        $string = addslashes($string);
    }
        return $string;
}

function my_stripslashes($string)
{
    if (!get_magic_quotes_gpc())
    {
        $string = stripslashes($string);
    }
        return $string;
}

Det er vel meget smart at tjekke på den måde, hvis man bruger stripslashes osv og 'magic_quotes_gpc' er slået til, går det jo lidt i ged.

Jeps my_addslashes er god.

Men my_stripslashes kan du droppe. Det skal du ikke.

Det eneste tidspunkt, hvor du skal bruge stripslashes, er når du vil udskrive ting, tilbage ud i en form, eksempelvis:

<input type='text' name='foo' value='<?= stripslashes($_POST['foo']); ?>' />

Indtaster jeg "søren's" og submitter formen, ville der blive skrevet "Søren\'s" tilbage ud i formen. Derfor stripslashes her.
Og for at være helt godt burde udskriften gøres som <?= htmlentities(stripslashes($_POST['foo']), ENT_QUOTES); ?>. Men nok om det.

Din my_stripslashes er i den sammenhæng vi diskturer ikke nødvendig. my_addslashes er god.

Når du indsætter med \ foran specialtegn, bliver disse \ ikke indsat i selve databasen. Derfor behøver du ikke fjerne dem igen med stripslashes.

Ja, stripslashes er naturligvis kun til udtræk :)

Så skal jeg kun bruge dem på noget jeg lige har brugt addslashes på derefter vil udskrive, men ikke til database udtræk ?

Rettelse: Så skal jeg kun bruge stripslashes på en streng jeg lige har brugt addslashes på og derefter vil udskrive? Ikke til database udtræk fra en db?

"Så skal jeg kun bruge dem på noget jeg lige har brugt addslashes på (el. 'magic_quotes_gpc' er aktiveret), og derefter vil udskrive, men ikke til database udtræk ?"

Ja.

Ja :)

Hmmmm.... blev en smule klogere.....

Indtil videre får i pointene... kommer der guldkorn fra andre, så kan der hurtigt komme flere point på bordet....