[PHP/MYSQL] Input hoge komma's krijg ik niet weg.

[Justin]

Hi allemaal,

Ik ben al een tijdje met iets bezig wat ik gewoon niet voor elkaar krijg....

Ik heb een script die automatisch transacties ophaalt bij een bank en in een database wegschrijft. Nou heb ik een transactie van het restaurant met den gouden bogen (de McD). Daar staat iets van:

McDonald's Zwolle NLD

Door de hoge komma ' gaat mijn code stuk en krijg ik een foutmelding:

You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 's Zwolle ZWOLLE NLD','1516900880')' at line 1


Wie oh wie kan mij helpen met onderstaande code? Het gaat om het ['subject'] gedeelte..

code:

$sql_add = mysql_query("INSERT INTO trans (executionDate, amount, subject, type, searchButtonValue, timestamp) VALUES ('".$trans[$i]['executionDate']."','".$trans[$i]['amount']."','".$trans[$i]['subject']."','".$trans[$i]['type']."','".$trans[$i]['searchButtonValue']."','".time()."')") or die (mysql_error());

$sql_add = mysql_query("INSERT INTO trans (executionDate, amount, subject, type, searchButtonValue, timestamp) VALUES ('".$trans[$i]['executionDate']."','".$trans[$i]['amount']."','".$trans[$i]['subject']."','".$trans[$i]['type']."','".$trans[$i]['searchButtonValue']."','".time()."')") or die (mysql_error());

[CurlyMo]

http://php.net/mysqli_real_escape_string
http://php.net/pg_escape_string

Voor je toekomstige vraag: Wikipedia: SQL injection

[ Voor 20% gewijzigd door CurlyMo op 25-01-2018 19:09 ]

[DukeBox]

En ga ook asap met prepared statements werken..

[Justin]

CurlyMo schreef op donderdag 25 januari 2018 @ 18:58:
http://php.net/manual/en/function.addslashes.php

Voor je toekomstige vraag: Wikipedia: SQL injection

Allemaal al geprobeerd.

addslashes, mysql_real_escape_string, str_replace

Maar ik denk dat ik het verkeerd toepas.

[DukeBox]

Justin schreef op donderdag 25 januari 2018 @ 19:01:
Maar ik denk dat ik het verkeerd toepas.

Laat dat denk maar weg

Plaats eens wat je nu doet..

[CurlyMo]

Justin schreef op donderdag 25 januari 2018 @ 19:01:
[...]
Allemaal al geprobeerd.

addslashes, mysql_real_escape_string, str_replace

Maar ik denk dat ik het verkeerd toepas.

Dan moet je gaan debuggen. Dat betekent dat je wil zien wat je exact naar de database stuurt:

code:

echo "INSERT INTO trans (executionDate, amount, subject, type, searchButtonValue, timestamp) VALUES ('".$trans[$i]['executionDate']."','".$trans[$i]['amount']."','".$trans[$i]['subject']."','".$trans[$i]['type']."','".$trans[$i]['searchButtonValue']."','".time()."')";

[ShitHappens]

In SQL, zegt deze apostrof "hier eindigt het veld", en vervolgens zit er iets in de query wat niet klopt ("s Zwolle " etc). Je zult er dus voor moeten zorgen dat deze van de juiste escaping voorzien wordt, dat de database deze negeert in de query en dus het veld gewoon af maakt.

Dus 3 dingen, in volgorde van belangrijk naar nog belangrijker:
- Met prepared statements werken
- Niet meer de mysql_* functies gebruiken, maar mysqli_*
- Alle input voorzien van escaping en opschonen voor deze de query bereikt.

[DJMaze]

CurlyMo schreef op donderdag 25 januari 2018 @ 18:58:
http://php.net/manual/en/function.addslashes.php

Ook al bedoel je het goed: NEE, NEE en nog eens NEE.
Zou je alsjeblieft je post willen aanpassen naar:

http://php.net/mysqli_real_escape_string
http://php.net/pg_escape_string

[CurlyMo]

DJMaze schreef op donderdag 25 januari 2018 @ 19:08:
[...]

Ook al bedoel je het goed: NEE, NEE en nog eens NEE.
Zou je alsjeblieft je post willen aanpassen naar:

http://php.net/mysqli_real_escape_string
http://php.net/pg_escape_string

Punt is hetzelfde. Je moet op de juiste plekken escapen

[DJMaze]

@CurlyMo punt is dat addslashes() niet voor database doeleinden is en je dus iemand iets verkeert aanleert.
Punt is dus niet hetzelfde.

[McKaamos]

Doe gewoon wat deze held zegt. Prepared Statements.
Ditte: http://php.net/manual/en/ref.pdo-mysql.php

[CurlyMo]

DJMaze schreef op donderdag 25 januari 2018 @ 19:12:
@CurlyMo punt is dat addslashes() niet voor database doeleinden is en je dus iemand iets verkeert aanleert.
Punt is dus niet hetzelfde.

Waarom suggereer je mysqli_real_escape_string terwijl we eigenlijk van prepared statements moeten uit gaan? Dan moeten we het gelijk goed doen. Ik blijf erbij dat TS prima is geholpen met addslashes voor zijn specifieke probleem, waar inderdaad nog veel meer mis mee is.

https://ilia.ws/archives/...-Prepared-Statements.html

[Justin]

@Allemaal - dank voor de tips dusver!

Dat het script verder verouderd is en misschien niet geheel veilig maakt voor mij niet uit. Het is een private script wat enkel wordt aangeroepen voor een cronjob vanaf de server.

- Alle input voorzien van escaping en opschonen voor deze de query bereikt.

Heb je heel misschien een voorbeeld hoe ik dit goed kan toepassen?

[McKaamos]

CurlyMo schreef op donderdag 25 januari 2018 @ 19:28:
[...]

Waarom suggereer je mysqli_real_escape_string terwijl we eigenlijk van prepared statements moeten uit gaan? Dan moeten we het gelijk goed doen. Ik blijf erbij dat TS prima is geholpen met addslashes voor zijn specifieke probleem, waar inderdaad nog veel meer mis mee is.

https://ilia.ws/archives/...-Prepared-Statements.html

Njah Addslashes is gewoon niet database safe. Die is juist voor PHP zelf, b.v. Post en Get variables.

En idd, prepared statements is wat je zou moeten doen.

However, als je al een bestaande applicatie hebt, kan het een enorme klus zijn om het te verbouwen. Maja overal mysql_real_escape_string toevoegen is ook een hels karwei.

Gezien TS de escapestring al niet voor elkaar kreeg, toch even een voorbeeldje.

PHP:

$sql_add = mysql_query("INSERT INTO trans (executionDate, amount, subject, type, searchButtonValue, timestamp) VALUES ('".$trans[$i]['executionDate']."','".$trans[$i]['amount']."','".mysql_real_escape_string($trans[$i]['subject'])."','".$trans[$i]['type']."','".$trans[$i]['searchButtonValue']."','".time()."')") or die (mysql_error());

[gekkie]

Justin schreef op donderdag 25 januari 2018 @ 19:32:
@Allemaal - dank voor de tips dusver!

Dat het script verder verouderd is en misschien niet geheel veilig maakt voor mij niet uit. Het is een private script wat enkel wordt aangeroepen voor een cronjob vanaf de server.


[...]


Heb je heel misschien een voorbeeld hoe ik dit goed kan toepassen?

Tot dat mijn bedrijf '; DELETE FROM trans; ... of nog sneller '; TRUNCATE trans; heet
altijd fijn als little bobby tables weer eens langs komt.

[CurlyMo]

McKaamos schreef op donderdag 25 januari 2018 @ 19:36:
[...]
Njah Addslashes is gewoon niet database safe. Die is juist voor PHP zelf, b.v. Post en Get variables.

De link die ik poste laat zien dat mysqli_real_escape_string dat dus ook niet (altijd) is.

[McKaamos]

CurlyMo schreef op donderdag 25 januari 2018 @ 19:47:
[...]

De link die ik poste laat zien dat mysqli_real_escape_string dat dus ook niet (altijd) is.

Dat is ook wel zo idd. Zoals Tom Scott al liet zien, gebruik maken van escapestring, is welliswaar beter, maar zonder dat met woorden uit te spreken, concludeert hij dat prepared statements de enige veilige methode is.

En ja, addslashes lost het directe apostrofprobleem van TS wel op, en als je dan tóch een wrapper om je variable heen legt, is het net zo makkelijk om het veiliger te doen dan addslashes. Mysql_real_escape_string is onbetwistbaar veiliger dan addslashes als t om databeesten gaat.

Hoe dan ook, user input moet je altijd wantrouwen. Ook als het data is van een user die niet direct met jouw systeem interfaced, maar data via een ander systeem bij jou terecht kan laten komen.

[Justin]

Het is gelukt met dank aan McKaamos! Alle input voorzien was inderdaad de oplossing, bedankt allemaal!!

[RobIII]

Mensen mensen toch. 17 replies al en nog niet 1 keer: Over het gebruik van Parametrized Queries

Justin schreef op donderdag 25 januari 2018 @ 20:06:
Het is gelukt met dank aan McKaamos! Alle input voorzien was inderdaad de oplossing, bedankt allemaal!!

Wil je alsjeblieft je "beste antwoord" nog eens herzien? Want het gebruik van mysql_real_escape_string is niet aan te raden (ik bedoel: je ziet toch zelf ook wel die dikke vette rode waarschuwing?? Denk je dat dat voor de sier is?). Hier is maar 1 correct antwoord*: parameterized queries en niets anders.

Maar neeeeee, want het mysql_real_escape_string was zo lekker knippen-en-plakken en werkte zomaar meteen! Fantastisch toch!? En zo, beste kijkbuiskinderen, blijft deze eeuwige rommel oneindig op 't web verkondigd worden en blijven nieuwkomers verkeerde dingen aanleren...

* Tenzij we gaan uitwijken naar ORM's en dat soort ongein.

[ Voor 85% gewijzigd door RobIII op 25-01-2018 20:24 ]

[McKaamos]

RobIII schreef op donderdag 25 januari 2018 @ 20:06:
Mensen mensen toch. 17 replies al en nog niet 1 keer: Over het gebruik van Parametrized Queries

[...]

Wil je alsjeblieft je "beste antwoord" nog eens herzien? Want het gebruik van mysql_real_escape_string is niet aan te raden. Hier is maar 1 correct antwoord: parameterized queries en niets anders.

Parametrized query is gewoon prepared statement met naampjes ipv vraagtekens.
Either way works, maar PQ is wel leesbaarder.

Of zie ik dan iets totaal over het hoofd?

[RobIII]

McKaamos schreef op donderdag 25 januari 2018 @ 20:09:
Parametrized query is gewoon prepared statement met naampjes ipv vraagtekens.

Nee!? Excuus. Ja. Nee. Maybe. Ze zijn min-of-meer synoniem ja. Ik begreep even dat jouw voorbeeld een "parameterized query" moest voorstellen; don't ask why want het stond er duidelijk niet. My bad.

Overigens in in "PHP land" PDO ook een prima optie. Of een ORM. Maar dat zijn hele andere beestjes.

Hier nog een stukje voor mensen die niet bekend zijn met de materie

De korte versie dan: in een parameterized query / prepared statement / hoe-ze-het-vandaag-weer-noemen stuur je een query met daarin 'placeholders'. De db-driver die je platform/programmeertaal gebruikt om met de DB te praten stuurt de argumenten (of je 'parameters') daarnaast mee. Dat hoef je helemaal niets te escapen, hoef je geen rekening te houden met datetime-formaten en ga zo maar door. Je geeft native types (veelal primitives) door zonder alles in een string te moeten flikkeren en je afvragen hoe je RDBMS dat type nou weer wou hebben (in het geval van een DateTime bijv dd/mm/yyyy vs mm/dd/yyyy => irrelevant bij parameterized queries, je geeft gewoon je DateTime variabele mee en laar de driver/het RDBMS 't oplossen; in het geval van een string => lekker laten zitten dat escapen, wederom: probleem voor de driver/RDBMS).

[ Voor 70% gewijzigd door RobIII op 25-01-2018 20:23 ]

[McKaamos]

RobIII schreef op donderdag 25 januari 2018 @ 20:11:
[...]

Nee!?


[...]

Ja.
Heb je de link zelf al eens gelezen (of verder gekeken dan je neus lang is?)

Toegegeven, ik ben er even vlug overheen gescanned.
En in de link die je zelf geeft worden ze in 1 zin genoemd als synoniem.
Maar ik zal later (op een groter scherm) eens uitgebreider lezen.

[RobIII]

McKaamos schreef op donderdag 25 januari 2018 @ 20:14:
[...]

Toegegeven, ik ben er even vlug overheen gescanned.
En in de link die je zelf geeft worden ze in 1 zin genoemd als synoniem.
Maar ik zal later (op een groter scherm) eens uitgebreider lezen.

Nee, my bad. Ik las/interpreteerde je post verkeerd. Zie mijn edit.

[ Voor 19% gewijzigd door RobIII op 25-01-2018 20:19 ]

[McKaamos]

RobIII schreef op donderdag 25 januari 2018 @ 20:16:
[...]

Nee, my bad. Ik las/interpreteerde je post verkeerd. Zie mijn edit.

Ah, ik volg de verwarring
Maakt niet uit, heb ik ook wel eens last van.

Eitherway, hoe je het beestje ook noemt, een query met placeholders is zeker the way to go.
Helemaal met je eens

Justin schreef op donderdag 25 januari 2018 @ 20:06:
Het is gelukt met dank aan McKaamos! Alle input voorzien was inderdaad de oplossing, bedankt allemaal!!

Yeah, t werkt, maar het blijft een sub-par oplossing. Vergeet ook niet dat die functie komt te vervallen.
Support op oude PHP versies gaat er dit jaar uit, dus dan heb je geen security patches meer en moet je wel over naar PHP7, ipv maximaal 5.6 wat je nu hebt.
En dan werkt je script dus niet meer.

Ik zou adiviseren om je script preventief om te bouwen naar een model met prepared statements (of parametrized queries, of welke exacte implementatie er van je het mooiste vindt).
Je script loopt nu wel ff, maar het moment dat PHP5.x z'n laatste nekschot krijgt komt rap dichterbij.
Beter om t nu op je gemak te doen, dan als je tegen die tijd oppeens moet hollen, toch?

[ Voor 49% gewijzigd door McKaamos op 25-01-2018 20:34 ]

[DukeBox]

RobIII schreef op donderdag 25 januari 2018 @ 20:06:
Mensen mensen toch. 17 replies al en nog niet 1 keer:

Jawel, 2e post..

[RobIII]

DukeBox schreef op donderdag 25 januari 2018 @ 21:00:
[...]

Jawel, 2e post..

Ik doelde op 't linkje naar onze enige echte eigen FAQ

[DukeBox]

RobIII schreef op donderdag 25 januari 2018 @ 21:01:
Ik doelde op 't linkje naar onze enige echte eigen FAQ

Uitgaande van het niveau van de vraag van de TS (nofi); hoe mooi en compleet die faq ook is, als je de juiste term niet weet (in dit geval voor php) dan zegt dat stuk je niets.

[RobIII]

DukeBox schreef op donderdag 25 januari 2018 @ 21:05:
[...]

Uitgaande van het niveau van de vraag van de TS (nofi), hoe mooi en compleet die faq ook is, als je de juiste term niet weet (in dit geval voor php) dan zegt dat stuk je niets.

We gaan inmiddels aardig offtopic dus ik laat 't hierbij: punt was dat ik 't van een aantal regulars wel verwacht had het linkje te posten. Niet meer, niet minder. Trek 't je niet aan; het was niet lullig of wat-dan-ook bedoeld.

[DukeBox]

RobIII schreef op donderdag 25 januari 2018 @ 21:06:
..punt was dat ik 't van een aantal regulars wel verwacht had het linkje te posten..

Tja, dan val ik meteen door de mand Ben geen regular, kom vrijwel nooit in /14

Hoe dan ook voor TS (@Justin , blijkbaar een hele goede tip om de FAQ eens door te nemen. Tegenwoordig is iedere andere manier dan die daar staat een dikke NO.

[Xantios]

*snip* doe eens effe normaal

[ Voor 90% gewijzigd door RobIII op 30-01-2018 14:31 ]