Bekijk Volledige Versie : 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
Ronald Klip
25/11/05, 19:45
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
Gerard van Wilgen
25/11/05, 20:45
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
Gerard van Wilgen
26/11/05, 11:15
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_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?
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
Gerbrand van Dieijen
26/11/05, 12:30
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)
Michiel de Roo
26/11/05, 14:00
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.
Warden Dave
26/11/05, 15:30
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
Erik Hensema
26/11/05, 16:30
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;
In de browser wordt dan dus '&' 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
Erick T. Barkhuis
26/11/05, 16:30
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.
Warden Dave
26/11/05, 16:30
"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
Erick T. Barkhuis
26/11/05, 16:45
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?
Warden Dave
26/11/05, 17:00
"Erick T. Barkhuis" <erick.usenet@ardane.c-o-m> wrote:
> 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?
Eerder al verwees ik ook al naar 'http://nl2.php.net/mysqli_multi_query' en
het zal zijn dat de angst ontstond dat 'nl2.php.net' over den toeren zou
raken van alle aandacht.
> Is http://nl3.php.net/intval stuk, of achterhaald, of iets anders?
Anders. Je kunt bij 'www.php.net' voor '/intval' gewoon een 'Found' +
'Location: http://nl3.php.net/intval' op je brood krijgen en tegen zo'n
prachtvondst ga ik me niet verzetten. Maar als je 't zaakje niet vertrouwt
en 'een luchtje' denkt waar te nemen dan probeer je ze toch allemaal uit!?
(Een fijne regenachtige zaterdagmiddag 'zoek de verschillen'. ;))
groet,
WD
Erik Hensema
26/11/05, 17:15
Install http://support.microsoft.com/kb/900930 to read this message.
begin quote of Erick T Barkhuis (erick.usenet@ardane.c-o-m):
> 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?
Klopt, de 'ab' wordt stilletjes gedropt. Silly php. Punt is
echter dat dat geen invloed heeft op de veiligheid. Je krijgt
misschien onzin in de database, maar wel veilige onzin.
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
"But officer, I was only trying to gain enough speed so I could coast
to the nearest gas station."
Erick T. Barkhuis
26/11/05, 17:15
Erik Hensema:
> Install http://support.microsoft.com/kb/900930 to read this message.
> begin quote of Erick T Barkhuis (erick.usenet@ardane.c-o-m):
>
Hee, een attachment?
--
Erick
"If a man speaks in the forest and there are no women there to hear him,
is he still wrong?"
> Als het je alleen gaat om het voorkomen van SQL-injecties, is het
> bovenstaande ietwat overdreven. mysql_real_escape_string() is daarvoor
> afdoende.
Ik zit zomaar wat te proberen om het te gaan begrijpen en heb het volgende
gedaan:
$string = "jan') AND DELETE * WHERE '1'='1' " ;
$sql="INSERT INTO vacatures (tekst) VALUES ('$string')";
echo $sql ;
echo "<br>";
echo "<br>";
$sql="INSERT INTO vacatures (tekst) VALUES ($string)";
echo $sql ;
echo "<br>";
echo "<br>";
$string2 = mysql_real_escape_string($string) ;
$sql="INSERT INTO vacatures (tekst) VALUES ('$string2')";
echo $sql ;
echo "<br>";
echo "<br>";
$string3 = addslashes ($string) ;
$sql="INSERT INTO vacatures (tekst) VALUES ($string3)";
echo $sql ;
echo "<br>";
echo "<br>";
en daar kwam het volgende uit:
INSERT INTO vacatures (tekst) VALUES ('jan') AND DELETE * WHERE '1'='1'')
INSERT INTO vacatures (tekst) VALUES (jan') AND DELETE * WHERE '1'='1')
INSERT INTO vacatures (tekst) VALUES ('jan\') AND DELETE * WHERE
\'1\'=\'1\'')
INSERT INTO vacatures (tekst) VALUES (jan\') AND DELETE * WHERE \'1\'=\'1\')
Maar wat doet nu wat?
Haico
"Erik Hensema" <usenet@smac.hensema.net> schreef in bericht > Kortom: check
of de data voldoet aan je verwachtingen. Daarmee
> creeer je veiligheid. Niet door zomaar wat functies aan te
> roepen.
OK, dank je wel, een duidelijk verhaal. Ook het idee om te controleren op
juiste invoer en niet op foute invoer is interressant. Helaas heb ik veel
velden waar hele lappen tekst ( be- c.q. omschrijvingen ) ingevoerd kunnen
worden.
Haico
Eric B. Bednarz
26/11/05, 20:00
"Haico" <hspaapenMONKEYTALEtiscali-INHOLLAND> writes:
> "Erik Hensema" <usenet@smac.hensema.net> schreef:
> Kortom: check of de data voldoet aan je verwachtingen.
> OK, dank je wel, een duidelijk verhaal. Ook het idee om te controleren op
> juiste invoer en niet op foute invoer is interressant.
Hmja, *hoe* interessant dat is zie je vooral bij regexp email
'validatie'. :->
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Erik Hensema
26/11/05, 22:15
Install http://support.microsoft.com/kb/900930 to read this message.
begin quote of Haico ():
>
> "Erik Hensema" <usenet@smac.hensema.net> schreef in bericht > Kortom: check
> of de data voldoet aan je verwachtingen. Daarmee
>> creeer je veiligheid. Niet door zomaar wat functies aan te
>> roepen.
>
> OK, dank je wel, een duidelijk verhaal. Ook het idee om te controleren op
> juiste invoer en niet op foute invoer is interressant. Helaas heb ik veel
> velden waar hele lappen tekst ( be- c.q. omschrijvingen ) ingevoerd kunnen
> worden.
Maakt niet uit. Dan nog kun je checken op een maximale lengte,
bijvoorbeeld. Of ASCII < 32. Vervolgens gewoon even addslashes()
en het kan veilig de database in.
Bij weergave in html haal je het door htmlentities() en ook dat
is dan veilig.
Soms heb je meer layout nodig in de opgeslagen tekst, dan kun je
gaan werken met striptags().
--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Quoting-HOWTO: http://www.leerquoten.nl
Warden Dave
26/11/05, 22:15
"Erik Hensema" <usenet@smac.hensema.net> wrote:
> Install http://support.microsoft.com/kb/900930 to read this message.
Nog steeds volledig offtopic.
> begin quote of Erick T Barkhuis (erick.usenet@ardane.c-o-m):
>> 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?
> Klopt, de 'ab' wordt stilletjes gedropt. Silly php.
Jij kunt dat nu 'silly' vinden, maar het is bij zo'n conversie geen
ongewoon gedrag en staat ook beschreven: "The value is given by the
initial portion of the string. If the string starts with valid
numeric data, this will be the value used. Otherwise, the value will
be 0 (zero).".
> Punt is echter dat dat geen invloed heeft op de veiligheid.
> Je krijgt misschien onzin in de database, maar wel veilige onzin.
Met dat in gedachte hoef je niet eerst te stellen dat het nog weer
'beter' is mensen die 999 jaar oud zijn buiten te sluiten. etc.
(Mensen zijn overigens wel ouder dan 120 jaar geworden.)
WD
>> OK, dank je wel, een duidelijk verhaal. Ook het idee om te controleren op
>> juiste invoer en niet op foute invoer is interressant.
>
> Hmja, *hoe* interessant dat is zie je vooral bij regexp email
> 'validatie'. :->
Jeetje, regexp..... moet ik dat weer gaan opzoeken. Oh reguliere
expressies..
Eigenlijk meer voor mezelf omdat ik het nu eenmaal beter leer als ik het
opschrijf het onderstaande:
2 jaar geleden gebruikte ik deze voor e-mail validatie ( uit Larry Ullman's
PHP voor het world wide web ), ik kreeg echter een paar ( 1 of 2 ) mailtjes
van mensen die hun bestaande -emailadres niet gevalideerd kregen:
=============
$lengte = strlen($address) ;
$patroon = ".+@.+\..+";
$patroon = "^([0-9a-z]+)([0-9a-z\.-_]+)@([0-9a-z\.-_]+)\.([0-9a-z]+)";
if(!eregi($patroon,$address)){
=================
Even kijken : we beginnen met minstens 1 cijfer of letter gevolgd door
minstens 1 cijfer, letter, punt, streepje of underscore, gevolgd door een
apestaart, gevolgd door minstens 1 cijfer, letter, punt, streepje of
underscore, gevolgd door een punt, gevolgd door minstens 1 cijfer, letter.
Het lijkt me dat meneer.jan.jansenccc@hetvvvnet.yy er wel door zal komen
maar meneer.jan.jansen@parijs.frankrijk.hetvvvnet.yy weer niet, of toch
wel, huh... een raar e-mailadres hadden ze dan....
en deze kwam ik net tegen met Google "regexp mail validation" (
http://www.codetoad.com/asp_email_reg_exp.asp ), was een ASP voorbeeld
overigens
===============
regEx.Pattern =
"^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z0-9][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$"
isValidE = regEx.Test(myEmail)
================
Wat zou dit kunnen zijn? Beginnen met kleine of hoofdletters maar geen
cijfer, gevolgd door 0 (nul) of meer ( die asterix ) woordkarakters ( \w =
a-z0-9 ) punt en/of streepje, gevolgd door een of meer (hoofd)letters en/of
cijfers, dan de apestaart, dan letters en cijfers, nul of meer
woordkarakters punten en/of streepjes, dan 1 of meer (hoofd)letters en/of
cijfers, dan een verplichte punt, dan 1 of meerdere (hoofd)letters, dan
eventueel nul of meerdere (hoofd)letters en/of punten en tenslotte eindigend
op 1 of meerdere (hoofd)letters.
Dit zal xxxx@xxxx.nl dekken en ook xxx.xxx.xxx.xxx@x1x.x1x.co.uk
( met dank aan http://www.4guysfromrolla.com/webtech/052899-1.shtml )
Haico
PS, met excuses voor de late reacties, het duurt altijd even voordat ik het
door of opgezocht heb ;-)
Eric B. Bednarz
27/11/05, 01:00
"Haico" <hspaapenMONKEYTALEtiscali-INHOLLAND> writes:
> Jeetje, regexp..... moet ik dat weer gaan opzoeken.
Ik scherts een beetje in reactie op het toetsen van de 'goede' input.
Ook dat gaat in de praktijk vaak erg fout.
Reguliere expressies op een email adres los te laten is er een klassiek
voorbeeld van (een ander is het 'parsen' van HTML).
> $patroon = "^([0-9a-z]+)([0-9a-z\.-_]+)@([0-9a-z\.-_]+)\.([0-9a-z]+)";
> "^[a-zA-Z][\w\.-]*[a-zA-Z0-9]@[a-zA-Z0-9][\w\.-]*[a-zA-Z0-9]\.[a-zA-Z][a-zA-Z\.]*[a-zA-Z]$"
Nou nou. Jij trapt er iets *te* makkelijk in.
Om inspiratie op te doen zou je de reguliere expressie uit het Perl
module Mail::RFC822::Address kunnen bestuderen.
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
..\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
..|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
..(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)
Weet waar je aan begint.
Erick T. Barkhuis
27/11/05, 06:30
Eric B. Bednarz:
> (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
> \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
> ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
> \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
> 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
> ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
> (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
> (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
> |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
> ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
[...]
> ?:\r\n)?[ \t])*))*)?;\s*)
>
>
> Weet waar je aan begint.
Sommige mensen doen ook alles om niet het risico te lopen opnieuw in een
..sig te passen, he?
--
Erick
"Da's geen IE-hack, da's een standaard EHBO procedure" - Eric B. Bednarz
in niwo
"Eric B. Bednarz" <bednarz@fahr-zur-hoelle.org> schreef
> Om inspiratie op te doen zou je de reguliere expressie uit het Perl
> module Mail::RFC822::Address kunnen bestuderen.
>
> (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
> \000-\031]+(?:(?:(?:\r\n)?[ \t]
> )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
> \t]))*"(?:(?:
> \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
> \000-\031]+(?:(?:(
<knip knip knip>
> +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
> \t])*)(?:\
> .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
> \t])+|\Z
> |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
> \t])*))*\>(?:(
> ?:\r\n)?[ \t])*))*)?;\s*)
> Weet waar je aan begint.
Dit is Perl? Dat zou je in theorie toch gewoon in combinatie met PHP kunnen
gebruiken? Vind je het overigens heel erg dat ik je aanbod om dit uit te
pluizen even oversla? Ik heb wel een pagina met daarop uitleg van wat wat
betekent:
http://www.tldp.org/linuxfocus/Nederlands/July1998/article53.html#53lfindex1
Gelukkig krijgt onze website een opt-in via het door hun ingevoerde
e-mailadres en als hun invoer niet binnen een bepaalde tijd geactiveerd
wordt wordt het Record automatisch verwijderd. Als ik met addslashes() SQL
injecties tegen kan gaan en dan eventueel met strip_tags of
htmlspecialcharacters() de uitvoer dan zit ik redelijk safe ( nadat ik de
input gecheckt heb op wat ik logischerwijs in dat invoerveld mag
verwachten ):
$string = strip_tags($string, '<a><b><i><u>');
Waarschuwing
Deze functie verandert geen attributen in de tags die je toestaat met
allowable_tags, waaronder de style and onmouseover attributen die een
slechtwillende gerbuiken kan misbruiken bij het posten van tekst dat gezien
kan worden door andere bezoekers.
groet,
Haico
Ronald Klip
27/11/05, 13:45
Haico wrote:
> Ronald:
>>Als het je alleen gaat om het voorkomen van SQL-injecties, is het
>>bovenstaande ietwat overdreven. mysql_real_escape_string() is daarvoor
>>afdoende.
De PHP manual zegt immers "This function must always (with few
exceptions) be used to make data safe before sending a query to MySQL.".
Maar eigenlijk is ook dat weer overdreven, zo valt te lezen op
http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html :
"Strictly speaking, MySQL requires only that backslash and the quote
character used to quote the string in the query be escaped. This
function quotes the other characters to make them easier to read in log
files." addslashes() zou dus afdoende moeten zijn.
Overigens moet je voor gebruik van addslashes() kijken wat de waarde van
magic_quotes_gpc is: indien 'true', worden quotes al geescaped en zou
addslashes() dat nogmaals doen.
> Maar wat doet nu wat?
Wat doet wat?
--
groet, Ronald
Michiel de Roo
28/11/05, 13:30
Warden Dave wrote:
> "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.)
Je hebt gelijk, met deze functie gaat het wel lukken. Maar met mysql_query
uit het voorbeeld gaat het niet.