UTF ??? probleem

Het zal zeker werken voor het doel dat je nu voor ogen hebt, maar ik bedoel te zeggen, dat het misgaat in de echo-regel.
Daar komt ten onrecht een \ in te staan.

En escaping van html en sql is niet alleen bedoeld als beveiliging tegen kwaadwillende derden.

Als jij lijsten inleest met geboorteregisters en dergelijke dan kan ik me voorstellen dat een deel daarvan met OCR is ingelezen en dat daarbij een C die wat hoeking geschreven is, zo maar verandert in een <

Of dat iemand bij het overtypen een typfout maakt en een < of iets dergelijks opneemt in de lijst.

Dáár wil je je ook tegen beschermen.
Dat kan leiden tot kapotte invoer in je database, of onverwacht blanco schermen

Voorbeeld?
Ik heb ooit eens een bug moeten zoeken omdat iemand in een fabriek nooit orders kon invoeren in het intranet.
Bij iedereen ging het goed, alleen bij deze gebruiker niet.

Uiteindelijk bleek dat degene die het gebouwd had van mening was dat de invoer uit de database veilig was en dat escaping onnodig zou zijn.

Alleen werd bij de order niet alleen user_id opgeslagen maar ook de naam.
En je raadt het al: deze persoon had een ' zijn naam zitten.

Dat gaf dus overlast voor deze gebruiker;
kostte tijd voor de opvolger van de developer (me)

Daarnaast wil je weer niet dat in je database Dhr Röntgen als "R&oul;tgen" wordt opgeslagen,
en op het scherm wil je de \\\\ niet zien staan.

Daarom ben ik voorstander van:
- altijd escapen op de plek waar het nodig is zodat je niet vertrouwen moet op "10 regels geleden zal dat wel geregeld zijn"
- en ook alleen daar waar het nodig is.

Je loopt dan ook niet aan tegen "ik moet een patch uitvoeren op de naam van dit record."
Want het gaat net zo goed fout bij een ' in de voornaam, geboorteplaats en zijn mailadres (al zullen daar weinig van zijn in dit geval)

Ignace Verschaeve op 05/02/2024 10:56:14

Dat escape teken komt dan wel niet zichtbaar in het uiteindelijke resultaat. En het doet wat ik wil doen. Qua beveiliging volstaat dit door het feit dat enkel bepaalde beheerders deze bewerkingen kunnen toepassen geen gebruikers. In wezen is het enkel alleen ik die het doe. Ik ben bezig met het opstellen van een lijst van 10.000den naamvarianten voor genealogische doeleinden. Gebaseerd op indexen van parochieregisters van omstreeks 1600 tot 1796 waarbij oude vormen gekoppeld worden aan de moderne versies. Mijn fout was dat ik een verkeerde redenering volgde over de werking van de real escape string. Ik slaag er nu eenmaal maar in om theorie te leren aan de hand van de praktijk en niet omgekeerd. Mijn leeftijd zeker?

Nee, PHP is nodeloos ingewikkeld, zo is het nu eenmaal, dat heeft niets met leeftijd te maken.
En het gebruik van Mysqli::real_escape_string() is lastig, omdat je zelf heel goed moet snappen hoe je het per geval dient te gebruiken. Daarmee fouten maken kan catastrofaal zijn voor de veiligheid van je programma en de gegevens, SQL injectie staat nog steeds op de 3e plaats van meest voorkomende software fouten in de wereld in 2023: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
Laten we eerlijk zijn, mysqli::real_escape_string() helpt daarbij nou niet echt om software veiliger te maken.

Gelukkig bestaat er ook nog zoiets als prepared statements, waarin escaping automatisch gaat. Je hoeft alleen een query te voorzien van plaatsvervangende symbolen, zoals $1, of met namen, zoals met PDO. Aparte PHP variabelen geef je mee aan de functies en escaping gaat dan altijd goed, er is geen onduidelijkheid over welk deel nu SQL code is, en welk deel SQL data. Zie: https://www.php.net/manual/en/mysqli.quickstart.prepared-statements.php

Het enige jammere van prepared statements is dat het niet voor alle situaties werkt. Stel je wilt de naam van een tabel in een JOIN variabel maken, dan is de enige optie om dat met de hand te doen (zoals met bijna alles waar het leuker wordt met SQL).
Er zijn ook betere databases als PostgreSQL. PostgreSQL heeft in PHP wel ondersteuning met pg_escape_identifier(), en nog veel meer leuke dingen.