[PHP] Prepared statement en preg_match()

[bindsa]

Ik heb 2 kleine vragen waar ik niet uit kom:

- Ik ben bezig met het maken van prepared statements in PHP & MySQL met MySQLi, alles werkt prima. Ik vroeg me alleen 1 ding af, je moet variabelen koppelen aan de query en dan het type opgeven. Maar wat gebeurt er nu als ik integer specifieer en een string doorgeef? (voor zover ik het kan zien werkt het gewoon (!)). En is het heel lelijk om gewoon altijd 's' of 'b' op te geven (dan zit je namelijk safe)? (En ja, ik weet dat ik moet checken of de input voldoet aan de vorm waarin ik het wil hebben, was just wondering)

- Ook ben ik ereg() aan het vervangen door preg_match(), met de ereg() patronen was ik vertrouwd alleen die van preg_match() zijn weer net iets anders, nou heb ik van ereg() zo'n mooi cheatsheetje op m'n bureau liggen waarop precies staat wat elk symbool betekent. Weet iemand zo'n sheetje voor preg_match() patronen? Of nog beter: Weet iemand een makkelijke manier om die patronen om te zetten?

Bedankt alvast

[ Voor 0% gewijzigd door bindsa op 27-04-2010 10:23 . Reden: Typfout ]

[JackPoint]

Ik heb geen tijd om ze allemaal door te spitten, maar hier staan een aantal php cheatsheets: http://devcheatsheet.com/search/?q2=php

[Hipska]

Enkele nuttige links voor het leren van regular expressions:
RegEx Cheat Sheet
RegExr: Free Online RegEx Testing Tool

[bindsa]

Hipska schreef op dinsdag 27 april 2010 @ 10:28:
Enkele nuttige links voor het leren van regular expressions:
RegEx Cheat Sheet
RegExr: Free Online RegEx Testing Tool

JackPoint schreef op dinsdag 27 april 2010 @ 10:27:
Ik heb geen tijd om ze allemaal door te spitten, maar hier staan een aantal php cheatsheets: http://devcheatsheet.com/search/?q2=php

Ok superbedankt, daar heb ik wat aan

Weet iemand ook iets over die types van paremetrized statements?

[HuHu]

L0calh0st schreef op dinsdag 27 april 2010 @ 15:33:
[...]


[...]


Ok superbedankt, daar heb ik wat aan

Weet iemand ook iets over die types van paremetrized statements?

PHP kent niet echt types, dus als je een string geeft waar een int wordt verwacht, dan gaat PHP proberen die string om te zetten naar een int.

Ik zou zeggen, probeer het eens en laat de query naar het scherm schrijven om te zien wat er gebeurd.

[Manuel]

En om even een aanvulling te geven op HuHu, dat kan heel simpel door dit: 'SELECT ?' en dan daar natuurlijk de string (of integer) die je wilt hebben.

Verder staan al die cheatsheets op internet en kon je in feite zo vinden m.b.v Google.

[RobIII]

Het is me niet helemaal duidelijk wat je wil bereiken, maar hou er rekening mee dat ik als (bijv.) "omschrijving" van een product de tekst "312097" kan willen invoeren; en dan wil je dat natuurlijk niet als integer passen aan je DB als het veld "omschrijving" een string is. Als je dus aan 't doen bent wat ik vermoed: Niet doen

Wat ik vermoed: je wil aan de hand van de inhoud van de variabelen die gepassed worden naar je prepared statement automatisch detecteren of je 'm als "s", "i", "b" etc. moet passen naar MySQLi dus de gebruiker van je class de moeite besparen om voor elke variabele ook nog een type mee te moeten geven. Er is een reden waarom je het type ook aan MySQLi moet doorgeven; anders deden ze dat zelf wel detecteren

[ Voor 38% gewijzigd door RobIII op 27-04-2010 17:55 ]

[pderaaij]

@localhost.

Het lijkt er op dat je PDO gebruikt en dan de quote() functie. Daar moest je inderdaad een type opgeven, maar het is beter om de prepare() functie van PDO te gebruiken. Die is eenvoudiger te gebruiken en ook een stuk sneller.

Daarnaast hoef je dus ook het type niet op te geven.

Zie voor meer info de opmerkingen in de manual: http://www.php.net/manual/en/pdo.quote.php

[ Voor 13% gewijzigd door pderaaij op 27-04-2010 18:34 ]

[bindsa]

RobIII schreef op dinsdag 27 april 2010 @ 17:51:
Het is me niet helemaal duidelijk wat je wil bereiken, maar hou er rekening mee dat ik als (bijv.) "omschrijving" van een product de tekst "312097" kan willen invoeren; en dan wil je dat natuurlijk niet als integer passen aan je DB als het veld "omschrijving" een string is. Als je dus aan 't doen bent wat ik vermoed: Niet doen

Wat ik vermoed: je wil aan de hand van de inhoud van de variabelen die gepassed worden naar je prepared statement automatisch detecteren of je 'm als "s", "i", "b" etc. moet passen naar MySQLi dus de gebruiker van je class de moeite besparen om voor elke variabele ook nog een type mee te moeten geven. Er is een reden waarom je het type ook aan MySQLi moet doorgeven; anders deden ze dat zelf wel detecteren

Ik snap dat je het niet zelf moet gaan detecteren met is_number() enz. dan schiet het zijn doel voorbij. Mijn vraag is meer, is het een heel dom iets om altijd het type op 's' te zetten? Omdat ik bij 'gewone' MySQL queries namelijk ook altijd alles quote, ook numerieke waarden (had ook met SQL-injecties te maken).

pderaaij schreef op dinsdag 27 april 2010 @ 18:33:
@localhost.

Het lijkt er op dat je PDO gebruikt en dan de quote() functie. Daar moest je inderdaad een type opgeven, maar het is beter om de prepare() functie van PDO te gebruiken. Die is eenvoudiger te gebruiken en ook een stuk sneller.

Daarnaast hoef je dus ook het type niet op te geven.

Zie voor meer info de opmerkingen in de manual: http://www.php.net/manual/en/pdo.quote.php

Het gaat hier om MySQLi, en de functie $mysqli->bind_param();

[RobIII]

L0calh0st schreef op dinsdag 27 april 2010 @ 19:20:
[...]


Ik snap dat ... dan schiet het zijn doel voorbij.
...is het een heel dom iets om altijd het type op 's' te zetten?

Want dan schiet 't z'n doel niet voorbij
Het sowieso wat mij betreft gewoon onzin dat MySQL het überhaupt vreet. Op dit soort impliciete casts gaan rekenen draait je vroeger of later de nek om.

L0calh0st schreef op dinsdag 27 april 2010 @ 19:20:
Omdat ik bij 'gewone' MySQL queries namelijk ook altijd alles quote, ook numerieke waarden (had ook met SQL-injecties te maken).

Bull en bull. Numerieke waardes horen niet gequote te worden (anders gaat MySQL imlpiciete casts doen) en het heeft geen kont met SQL-injecties te maken zolang je zorgt dat numerieke waardes ook daadwerkelijk numeriek zijn voor je ze passed.

[ Voor 4% gewijzigd door RobIII op 27-04-2010 19:42 ]

[bindsa]

RobIII schreef op dinsdag 27 april 2010 @ 19:41:
[...]

Want dan schiet 't z'n doel niet voorbij
Het sowieso wat mij betreft gewoon onzin dat MySQL het überhaupt vreet. Op dit soort impliciete casts gaan rekenen draait je vroeger of later de nek om.


[...]

Bull en bull. Numerieke waardes horen niet gequote te worden (anders gaat MySQL imlpiciete casts doen) en het heeft geen kont met SQL-injecties te maken zolang je zorgt dat numerieke waardes ook daadwerkelijk numeriek zijn voor je ze passed.

Ok duidelijk gewoon netjes het juiste type aangeven dan Bedankt voor de info.

Offtopic: Nice icon pick script trouwens

[ Voor 4% gewijzigd door bindsa op 27-04-2010 19:54 ]

[cariolive23]

RobIII schreef op dinsdag 27 april 2010 @ 19:41:
Bull en bull. Numerieke waardes horen niet gequote te worden (anders gaat MySQL imlpiciete casts doen) en het heeft geen kont met SQL-injecties te maken zolang je zorgt dat numerieke waardes ook daadwerkelijk numeriek zijn voor je ze passed.

Toch heb je geen gelijk, zie de functie mysql_real_escape_string():

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

Een stuk SQL wordt dus niet geescaped, zolang je genoemde tekens er maar niet in zet. Het gebruik van quotes in je SQL is dus noodzakelijk om SQL injection tegen te gaan, dat is de enige manier om foute content gewoon als string in de query te krijgen:
De query:

code:

SELECT * FROM x WHERE 1 = ?

En dan nu met de content, voorzien wat een stukje sql wat niet wordt geescaped!: 1 OR true

code:

SELECT * FROM x WHERE 1 = 1 OR true; -- SQL injection!

Of:

code:

SELECT * FROM x WHERE 1 = '1 OR true'; -- gewoon een kansloze string waar je geen last van hebt.

Je hebt een punt wanneer je vooraf altijd controleert of er wel een getal wordt ingevoerd, maar dat soort controles gaan vroeg of laat fout. Niets menselijks is een programmeur vreemd!

Gebruik dus altijd quotes of ga met echte prepared statements aan de slag waarbij de database bepaalt of je het juiste datatype gebruikt. Dan gebruik je geen quotes voor je variabelen, is dan niet nodig. Voor MySQL-databases kun je dan MySQLi of PDO gebruiken.

Dus ook nummerieke waardes ga je quoten, dat doet geen zeer, het voorkomt juist pijn: SQL injection

[DataGhost]

Euh, als je gewoon cast naar integer of op een andere manier controleert of een variabele puur numeriek is weet je 100% zeker dat er geen gekke SQL in kan zitten (behalve out of bounds gedoe). Quotes aanhalen om in hun eentje SQL-injectie tegen te gaan is, vooral in combinatie met je voorbeeld, nogal kansloos. Één aanhalingsteken in je voorbeeld erbij en het is alweer mis. Het is dus of valideren of escapen, niet gewoon dom alles als een string je db in flikkeren. Als je ergens een integerwaarde verwacht moet je er ook echt voor zorgen dat het een integer is in plaats van voorbereidingen te treffen voor wanneer je input dat niet is.

PHP:

$x = (int) $_POST["bla"];
// eventuele check hier om te kijken of $x ==(=) $_POST["bla"] of een andere validatie
$result = mysql_query("SELECT * FROM tabel WHERE id=$x");

Injecteer ze!

[ Voor 13% gewijzigd door DataGhost op 27-04-2010 22:16 ]

[RobIII]

cariolive23 schreef op dinsdag 27 april 2010 @ 22:03:
Je hebt een punt wanneer je vooraf altijd controleert of er wel een getal wordt ingevoerd

Dat hoor je sowieso te doen.

cariolive23 schreef op dinsdag 27 april 2010 @ 22:03:
of ga met echte prepared statements aan de slag waarbij de database bepaalt of je het juiste datatype gebruikt.

Daar gaat het hele topic nou net over *wijst naar topictitel*

[ Voor 4% gewijzigd door RobIII op 27-04-2010 22:19 ]

[FragFrog]

cariolive23 schreef op dinsdag 27 april 2010 @ 22:03:
Dus ook nummerieke waardes ga je quoten, dat doet geen zeer, het voorkomt juist pijn: SQL injection

In principe kan PHP natuurlijk ook prima numerieke waardes casten met een (int), prima veilige manier om getallen zonder quotes je DB in te schoppen. Onderliggende punt echter is dat je hoe dan ook gaat lopen casten aangezien zowat alles wat van een gebruiker komt toch eerst door PHP als string wordt opgevat (alles in je GET, POST en COOKIE parameters in elk geval voor zover ik weet). Het is dan ook een beetje een discutabel punt: erg netjes om het goede type mee te geven, maar geen man overboord als je het niet doet en niet anders dan wanneer je de gewone mysql functies zou gebruiken wat ik gok 99% van de PHP gebruikers doet. De conversie hou je, of je het nu door PHP of MySQL laat doen.

DataGhost schreef op dinsdag 27 april 2010 @ 22:14:
Quotes aanhalen om in hun eentje SQL-injectie tegen te gaan is, vooral in combinatie met je voorbeeld, nogal kansloos.

Als je zijn voorbeeld goed leest snap je dat het probleem juist is dat ook met goede escaping (middels mysql_real_escape_string) je nog steeds kans hebt op SQL injectie als je niet ofwel quotes gebruikt ofwel eerst zelf de variabele gaat casten. Dan kun je standaard geen quotes gebruiken en hopen dat je nooit vergeet die cast te zetten, of ze gewoon wel altijd gebruiken met hooguit een overbodige extra conversie - wat op zich niet zo'n ramp is.

[ Voor 27% gewijzigd door FragFrog op 27-04-2010 22:24 ]

[cariolive23]

RobIII schreef op dinsdag 27 april 2010 @ 22:15:


Daar gaat het hele topic nou net over *wijst naar topictitel*

Mij ging het hier om:

Numerieke waardes horen niet gequote te worden

Dat is namelijk onzin, quotes heb je geen last van, ze kunnen je helpen bij het voorkomen van SQL injection. Met prepared statements bepaalt de database zelf wel of er quotes noodzakelijk zijn, dat doe jij niet, jij gebruikt ze gewoon.

RDBMS-en en SQL bestaan al een jaar of 40, daar is dus redelijk over nagedacht, dat is bewezen techniek en dat werkt uitstekend. Maak er dan ook gebruik van, scheelt je veel overbodig werk.

[RobIII]

cariolive23 schreef op dinsdag 27 april 2010 @ 22:41:
Dat is namelijk onzin, quotes heb je geen last van

MySQL wel (en gehad)

cariolive23 schreef op dinsdag 27 april 2010 @ 22:41:
ze kunnen je helpen bij het voorkomen van SQL injection

Ikzelf gebruik geen quotes om numerieke values; nooit gedaan ook niet. Maar dat is, imho, een kwestie van smaak.

cariolive23 schreef op dinsdag 27 april 2010 @ 22:41:
Met prepared statements bepaalt de database zelf wel of er quotes noodzakelijk zijn, dat doe jij niet, jij gebruikt ze gewoon.

Huh? Ik gebruik ze (quotes?) juist niet. En al helemaal niet bij prepared statements.

PHP:

$query = 'insert into mytable (a, b, c) values (?, ?, ?)';

Voila.

cariolive23 schreef op dinsdag 27 april 2010 @ 22:41:
RDBMS-en en SQL bestaan al een jaar of 40, daar is dus redelijk over nagedacht, dat is bewezen techniek en dat werkt uitstekend. Maak er dan ook gebruik van, scheelt je veel overbodig werk.

Ik heb een hekel aan impliciete casts; als er iets gecast moet worden doe ik dat zelf wel. Maar dat heeft ook te maken met dat ik veel met strong-typed talen bezig ben en weinig met PHP en consorten.

[ Voor 4% gewijzigd door RobIII op 27-04-2010 22:59 ]