Onderwerp: PHP - Notatie voor een veilig SQL injectie

Hallo,

ik ben op zoek, en ik heb echt gezocht, naar een redelijk veilige manier om
ingevulde velden in een formulier in een database te kunnen zetten. Wat mij
opviel is dat niemand het met elkaar eens is en er geen echte veilige
oplossing (b)lijkt te bestaan. Bijna elke site over veiligheid kopiëert
letterlijk bepaalde voorbeelden maar een echt sluitend antwoord ( wat ik ook
kan begrijpen ) vind ik niet. Daarom heb ik wat kreten/functies hier als
voorbeeld neergezet met de vraag of ik hiermee een beetje ingedekt ben:

<?php
if (isset($_POST['invoer'] ))
{
$invoer = "foute invoer"; // afkomstig uit een formulier
$invoer =
addslashes(htmlspecialchars(htmlentities(strip_tag s(utf8_decode($invoer)))))
;
$sql="INSERT INTO table_name (invoer) VALUES ('$invoer')" ;
}
?>

Ik zeg er eerlijk bij dat ik het niet heb uitgeprobeerd maar er moet toch
een standaard notatie zijn om het overgrote deel op te kunnen vangen.

Bedankt,

Haico

P.S. Ik werk met $_SESSION['invoer'] en vind het geen probleem ( maar ben er
wel tegen ) als iemand die afluistert of een session ID scoort. Het gaat
mij om een veilige SQL invoer.

Haico <hspaapenMONKEYTALEtiscali-INHOLLAND>:
> ik ben op zoek, en ik heb echt gezocht, naar een redelijk veilige manier
> om ingevulde velden in een formulier in een database te kunnen zetten.

Dat doe je over het algemeen met prepared statements. PHP zal daar vast
support voor hebben.

--
robert

Haico schreef:
>
> ik ben op zoek, en ik heb echt gezocht, naar een redelijk veilige manier om
> ingevulde velden in een formulier in een database te kunnen zetten.
>
> if (isset($_POST['invoer'] ))
> {
> $invoer = "foute invoer"; // afkomstig uit een formulier
> $invoer =
> addslashes(htmlspecialchars(htmlentities(strip_tag s(utf8_decode($invoer)))))
> ;
> $sql="INSERT INTO table_name (invoer) VALUES ('$invoer')" ;
> }

Als het je alleen gaat om het voorkomen van SQL-injecties, is het
bovenstaande ietwat overdreven. mysql_real_escape_string() is daarvoor
afdoende.

Die functies 'binnen' addslashes zijn wellicht bedoeld om bij uitvoer
uit de db naar HTML XSS te voorkomen. Maatregelen daartegen kun je dan
ook beter nemen tijdens het genereren van de uitvoer.

Zie de manual voor het verschil tussen htmlspecialchars en htmlentities.
Allebei gebruiken zal niet tot veel goeds leiden.

--
groet, Ronald

Haico wrote:
> Hallo,
>
> ik ben op zoek, en ik heb echt gezocht, naar een redelijk veilige manier om
> ingevulde velden in een formulier in een database te kunnen zetten. Wat mij
> opviel is dat niemand het met elkaar eens is en er geen echte veilige
> oplossing (b)lijkt te bestaan. Bijna elke site over veiligheid kopiëert
> letterlijk bepaalde voorbeelden maar een echt sluitend antwoord ( wat ik ook
> kan begrijpen ) vind ik niet. Daarom heb ik wat kreten/functies hier als
> voorbeeld neergezet met de vraag of ik hiermee een beetje ingedekt ben:
>
> <?php
> if (isset($_POST['invoer'] ))
> {
> $invoer = "foute invoer"; // afkomstig uit een formulier
> $invoer =
> addslashes(htmlspecialchars(htmlentities(strip_tag s(utf8_decode($invoer)))))
> ;
> $sql="INSERT INTO table_name (invoer) VALUES ('$invoer')" ;
> }
> ?>
>

Dit lijkt me een nogal drastische beveiliging die misschien soms meer
doet dan je wilt. Het lijkt me bijvoorbeeld niet zinnig om zowel
htmlentities() als htmlspecialchars() uit te voeren. Nadat de invoer
door htmlentities() is verwerkt, is er voor htmlentities() niets meer
overgebleven wat geconverteerd zou kunnen worden.

Mijn eigen filosofie is dat in principe alles wat iemand invoert,
ongewijzigd in de database opgeslagen kan worden (voor zover datatype en
maximumlengte van de velden dat toelaten). Pas als ik de data uit de
database lees en ergens voor ga gebruiken, ga ik kijken wat er eventueel
geconverteerd of weggefilterd moet worden. Als de data bijvoorbeeld op
een webpagina weergegeven moeten worden, converteer ik ze met
htmlentities(), en als de data in een dynamische SQL-query ingevuld
worden, converteer ik ze met addslashes().

Je kunt wel proberen de database "schoon" te houden, maar je kunt er
nooit zeker van zijn dat er niet, bijvoorbeeld door een fout in een
invoerprogramma, toch iets in terechtkomt wat later problemen kan
veroorzaken.


--

Gerard van Wilgen

www.majstro.com - Veeltalig vertaalwoordenboek
www.erotikejo.com - Internationaal sexportaal

On Fri, 25 Nov 2005 20:30:43 +0100,
Gerard van Wilgen <gvanwilgen@planet.nl> wrote:
> Haico wrote:
>> Hallo,
>>
>> $invoer =
>> addslashes(htmlspecialchars(htmlentities(strip_tag s(utf8_decode($invoer)))))


> Mijn eigen filosofie is dat in principe alles wat iemand invoert,
> ongewijzigd in de database opgeslagen kan worden (voor zover datatype en
> maximumlengte van de velden dat toelaten). Pas als ik de data uit de
> database lees en ergens voor ga gebruiken, ga ik kijken wat er eventueel
> geconverteerd of weggefilterd moet worden.

Dat lijkt me nogal nutteloos. Waarom zou je op een pagina die 400.000 keer
per dag wordt bekeken een bewerking uitvoeren die je ook eenmalig kunt doen
bij de invoer?

> Als de data bijvoorbeeld op
> een webpagina weergegeven moeten worden, converteer ik ze met
> htmlentities(), en als de data in een dynamische SQL-query ingevuld
> worden, converteer ik ze met addslashes().
>
> Je kunt wel proberen de database "schoon" te houden, maar je kunt er
> nooit zeker van zijn dat er niet, bijvoorbeeld door een fout in een
> invoerprogramma, toch iets in terechtkomt wat later problemen kan
> veroorzaken.

Dat is redelijk mogelijk voor 90% van de invoer. Dat je voor die 10% zo'n
achteraf werkwijze zou hanteren is wel te verdedigen ja.

Hans
--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn

http://blacklist.kernelnewbies.nl

Hans wrote:
> On Fri, 25 Nov 2005 20:30:43 +0100,
> Gerard van Wilgen <gvanwilgen@planet.nl> wrote:
>
>>Haico wrote:
>>
>>>Hallo,
>>>
>>> $invoer =
>>>addslashes(htmlspecialchars(htmlentities(strip_ tags(utf8_decode($invoer)))))
>
>
>
>>Mijn eigen filosofie is dat in principe alles wat iemand invoert,
>>ongewijzigd in de database opgeslagen kan worden (voor zover datatype en
>>maximumlengte van de velden dat toelaten). Pas als ik de data uit de
>>database lees en ergens voor ga gebruiken, ga ik kijken wat er eventueel
>>geconverteerd of weggefilterd moet worden.
>
>
> Dat lijkt me nogal nutteloos. Waarom zou je op een pagina die 400.000 keer
> per dag wordt bekeken een bewerking uitvoeren die je ook eenmalig kunt doen
> bij de invoer?

Ik denk dat de tijd die nodig is om een functie als addslashes() of
htmlspecialcharacters() uit te voeren, verwaarloosbaar is vergeleken met
de tijd die nodig is om de data uit de database te lezen.

>>Je kunt wel proberen de database "schoon" te houden, maar je kunt er
>>nooit zeker van zijn dat er niet, bijvoorbeeld door een fout in een
>>invoerprogramma, toch iets in terechtkomt wat later problemen kan
>>veroorzaken.
>
>
> Dat is redelijk mogelijk voor 90% van de invoer. Dat je voor die 10% zo'n
> achteraf werkwijze zou hanteren is wel te verdedigen ja.

Ik zou er zelf niet op durven vertrouwen dat er nooit door een fout van
mezelf, een systeemstoring of door de acties van een hacker met slechte
bedoelingen, data in de database worden opgeslagen die problemen kunnen
veroorzaken wanneer ze op een gegeven moment gebruikt worden.

In de praktijk ben ik meer dan eens tegen problemen aangelopen die
veroorzaakt bleken te worden door data die verondersteld werden foutloos
te zijn. Daarbij komt nog dat je soms te maken krijgt met data die
geïmporteerd zijn uit bronnen komen waarover je zelf geen controle hebt.
Denk bijvoorbeeld aan gegevens die van derde partijen gekocht zijn,


--

Gerard van Wilgen

www.majstro.com - Veeltalig vertaalwoordenboek
www.erotikejo.com - Internationaal sexportaal

Hans schreef:
>
> Dat is redelijk mogelijk voor 90% van de invoer. Dat je voor die 10% zo'n
> achteraf werkwijze zou hanteren is wel te verdedigen ja.
>

Als een kwaadaardige gebruiker in een invoerveld iets invuld als
pietje"); DELETE * FROM persoon WHERE ("blah"=("bla;

En ik lees het invoerveld direct uit, zonder het te converteren, dan
gaat het volgende toch fout?
mysql_query ("INSERT INTO persoon (waarde)VALUES(\"$waarde\")");


Ik gebruik zelf (in Java) preparedstatements, maar ik had begrepen dat
dit in php nogal eens problemen kan geven als de add_slashes vergeten wordt.

(noot gebruikt overigens, weet niet zeker of dit in huidige versies van
PHP nog gaat werken)

Gerbrand van Dieijen wrote:
> Hans schreef:
>
>>
>> Dat is redelijk mogelijk voor 90% van de invoer. Dat je voor die 10% zo'n
>> achteraf werkwijze zou hanteren is wel te verdedigen ja.
>>
>
> Als een kwaadaardige gebruiker in een invoerveld iets invuld als
> pietje"); DELETE * FROM persoon WHERE ("blah"=("bla;
>
> En ik lees het invoerveld direct uit, zonder het te converteren, dan
> gaat het volgende toch fout?
> mysql_query ("INSERT INTO persoon (waarde)VALUES(\"$waarde\")");

Tegen sql injectie check je natuurlijk vooraf, maar voor xss kan het ook
achteraf. Overigens gaat dit voorbeeld niet op, want php-mysql ondersteunt
geen meerdere queries in één string.

NNTP-Posting-Host: s55908212.adsl.wanadoo.nl
X-Trace: nl-news.euro.net 1133015091 20916 85.144.130.18 (26 Nov 2005 14:24:51 GMT)
X-Complaints-To: usenet@nl-news.euro.net
NNTP-Posting-Date: Sat, 26 Nov 2005 14:24:51 +0000 (UTC)
Cancel-Lock: sha1:8fZarTg7U9axYeZuZJgHa6ACiXo= sha1:kK3sDbvkQvd4fGB/8fX29FCMDFQ=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2670
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Xref: nl-news.euro.net nl.internet.www.server-side:39853

"Michiel de Roo" <yourlove@welovespam.nl> wrote:

> Overigens gaat dit voorbeeld niet op, want php-mysql ondersteunt
> geen meerdere queries in één string.

Toch wel. Zie http://nl2.php.net/mysqli_multi_query (Vanaf MySQL versie 4.1
bestaat de mogelijkheid van meerdere statements in 1 query string; zie
daarvoor ook CLIENT_MULTI_STATEMENTS en MYSQL_OPTION_MULTI_STATEMENTS_ON
etc.)

WD

On Sat, 26 Nov 2005 11:03:10 +0100,
Gerard van Wilgen <gvanwilgen@planet.nl> wrote:
> Hans wrote:

>>>maximumlengte van de velden dat toelaten). Pas als ik de data uit de
>>>database lees en ergens voor ga gebruiken, ga ik kijken wat er eventueel
>>>geconverteerd of weggefilterd moet worden.
>>
>>
>> Dat lijkt me nogal nutteloos. Waarom zou je op een pagina die 400.000 keer
>> per dag wordt bekeken een bewerking uitvoeren die je ook eenmalig kunt doen
>> bij de invoer?
>
> Ik denk dat de tijd die nodig is om een functie als addslashes() of
> htmlspecialcharacters() uit te voeren, verwaarloosbaar is vergeleken met
> de tijd die nodig is om de data uit de database te lezen.

Het is toch extra processor tijd die je moet uitvoeren. Vooral bij erg
drukke sites kun je er je voordeel mee halen.

>>>Je kunt wel proberen de database "schoon" te houden, maar je kunt er
>>>nooit zeker van zijn dat er niet, bijvoorbeeld door een fout in een
>>>invoerprogramma, toch iets in terechtkomt wat later problemen kan
>>>veroorzaken.

....

> In de praktijk ben ik meer dan eens tegen problemen aangelopen die
> veroorzaakt bleken te worden door data die verondersteld werden foutloos
> te zijn. Daarbij komt nog dat je soms te maken krijgt met data die
> geïmporteerd zijn uit bronnen komen waarover je zelf geen controle hebt.
> Denk bijvoorbeeld aan gegevens die van derde partijen gekocht zijn,

Ook daar kun je een validatie op los laten voor je het je database ingooit
volgens mij.

Groet,

Hans

--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn

http://blacklist.kernelnewbies.nl

Reply-To: hans@blacklist.kernelnewbies.nl
Message-ID: <slrndogt6b.lq2.replyelsewhere@server.lonki.xs4all .nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.7.3 (Linux)
Date: 26 Nov 2005 14:35:35 GMT
Lines: 29
NNTP-Posting-Host: 82.92.62.7
X-Trace: 1133015735 dreader31.news.xs4all.nl 7891 82.92.62.7:12893
Xref: nl-news.euro.net nl.internet.www.server-side:39855

On Sat, 26 Nov 2005 13:50:01 +0100,
Michiel de Roo <yourlove@welovespam.nl> wrote:
> Gerbrand van Dieijen wrote:
>> Hans schreef:
>>
>>> Dat is redelijk mogelijk voor 90% van de invoer. Dat je voor die 10% zo'n
>>> achteraf werkwijze zou hanteren is wel te verdedigen ja.
>>>
>> Als een kwaadaardige gebruiker in een invoerveld iets invuld als
>> pietje"); DELETE * FROM persoon WHERE ("blah"=("bla;
>>
>> En ik lees het invoerveld direct uit, zonder het te converteren, dan
>> gaat het volgende toch fout?
>> mysql_query ("INSERT INTO persoon (waarde)VALUES(\"$waarde\")");
>
> Tegen sql injectie check je natuurlijk vooraf, maar voor xss kan het ook
> achteraf. Overigens gaat dit voorbeeld niet op, want php-mysql ondersteunt
> geen meerdere queries in één string.

mysqli heeft er al ondersteuning voor als ik me niet vergis.

Groet,

Hans
--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn

http://blacklist.kernelnewbies.nl

Install http://support.microsoft.com/kb/900930 to read this message.
begin quote of Haico ():
> ik ben op zoek, en ik heb echt gezocht, naar een redelijk veilige manier om
> ingevulde velden in een formulier in een database te kunnen zetten. Wat mij
> opviel is dat niemand het met elkaar eens is en er geen echte veilige
> oplossing (b)lijkt te bestaan. Bijna elke site over veiligheid kopiëert
> letterlijk bepaalde voorbeelden maar een echt sluitend antwoord ( wat ik ook
> kan begrijpen ) vind ik niet. Daarom heb ik wat kreten/functies hier als
> voorbeeld neergezet met de vraag of ik hiermee een beetje ingedekt ben:
>
><?php
> if (isset($_POST['invoer'] ))
> {
> $invoer = "foute invoer"; // afkomstig uit een formulier
> $invoer =
> addslashes(htmlspecialchars(htmlentities(strip_tag s(utf8_decode($invoer)))))
> ;
> $sql="INSERT INTO table_name (invoer) VALUES ('$invoer')" ;
> }
> ?>

Je doet nu een aantal dingen dubbel en nog eens niet op de juiste
plek ook.

Ten eerste zou een utf8_decode niet nodig moeten zijn wanneer je
volledig in utf8 werkt.
Als alternatief kun je je webpagina's natuurlijk ook gewoon in
ISO-8859-1 maken, dan krijg je je invoer ook in die charset
binnen.

Vervolgens doe je een strip_tags(). Die functie is voornamelijk
bedoeld om forumpostings te strippen van html tags en ondertussen
toch een subset van tags toe te staan (bijvoorbeeld: p, b, i).
Het is een keuze die je maakt. Het strippen van *alle* tags vind
ik persoonlijk niet zo nuttig.

Vervolgens htmlentities. Dat is een functie die ik pas zou
aanroepen na het uitlezen van de database. Het maakt het
manipulere van strings makkelijker na het uitlezen (bijvoorbeeld:
pak de eerste 15 tekens van een string).

Een htmlspecialchars na een htmlentities is een bug, meestal. Het
effect is dat je dubbele escapes krijgt:
& -> &amp; -> &amp;amp;
In de browser wordt dan dus '&amp;' weergegeven.

De addslashes vervolgens is de enige functie die *echt* nodig is
om data veilig je database in te krijgen.

Overigens heb je het hier over willekeurig gestructureerde data
die je wilt opslaan in een database. Dat komt niet zo heel veel
voor in de praktijk. Meestal is de data gestructureerd: een
emailadres, een datum, een tekst.
In je code moet je dan ook checks doen of de data voldoet aan je
verwachtingen.
Let op dat je *niet* gaat checken op foute invoer. Als je te
weinig checkt, dan laat je dus foute invoer door. Als je checkt
op *goede* invoer en je maakt een fout, dan laat je te weinig
door, maar dat is wel veilig.
Voorbeeld: je verwacht een leeftijd. Je doet deze check:

if(preg_match('/[a-z]/', $_POST['leeftijd']) die("geen letters
toegestaan in een leeftijd");

Overduidelijk dat dat niet voldoende is. Je laat vanalles nog
door.

Dit is een betere check:
if(preg_match('/^[0-9]{1,3}$/', $_POST['leeftijd'])) {
# opslaan
}

Nog niet echt geweldig overigens, want niemand is 999 jaar oud.

Dit is nog weer beter:
$leeftijd = (int) $_POST['leeftijd'];
if($leeftijd >= 0 && $leeftijd <= 120) {
# opslaan
} else {
# afgekeurd
}

Kortom: check of de data voldoet aan je verwachtingen. Daarmee
creeer je veiligheid. Niet door zomaar wat functies aan te
roepen.

--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl

Erik Hensema:

> Dit is nog weer beter:
> $leeftijd = (int) $_POST['leeftijd'];
> if($leeftijd >= 0 && $leeftijd <= 120) {
> # opslaan
> } else {
> # afgekeurd
> }

Post eens voor de grap de waarde "12ab" als invoer?


--
Erick

"I have opinions of my own -- strong opinions --but I don't always agree
with them." - George Bush Sr.

"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> Erik Hensema:

>> Dit is nog weer beter:
>> $leeftijd = (int) $_POST['leeftijd'];
>> if($leeftijd >= 0 && $leeftijd <= 120) {
>> # opslaan
>> } else {
>> # afgekeurd
>> }

> Post eens voor de grap de waarde "12ab" als invoer?

Je kunt zo wel zeggen dat het resultaat van ' (int) "onzin" ' wel eens 0
(nul) zou kunnen zijn, dus het kon inderdaad /nog/ beter. [Men ziet bijv.
'is_numeric' (http://nl3.php.net/is_numeric) en 'intval'
(http://nl2.php.net/intval)]

WD

Warden Dave:

> [Men ziet bijv.
> 'is_numeric' (http://nl3.php.net/is_numeric) en 'intval'
> (http://nl2.php.net/intval)]

Hee, dit is grappig.
Waarom verwijs je voor is_numeric naar nl3.php en voor intval naar
nl2.php?

Is http://nl3.php.net/intval stuk, of achterhaald, of iets anders?