Invalid argument supplied for foreach()

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: « vorige 1 2

Thomas van den Heuvel

Thomas van den Heuvel

21/06/2020 23:14:27
Quote Anchor link
- Ariën - op 21/06/2020 22:23:51:
Ik zie geen SQL-injection in een vaste waarde hoor.

Wat bedoel je met vaste waarde?

- Ariën - op 21/06/2020 22:23:51:
Of je single-quotes gebruikt bij getallen of niet, tja... dat blijft een eigen keuze.

Het streven is hoe dan ook je queries veilig maken en veilig houden, lijkt mij. Je wilt hierbij een zo simpel mogelijke methode hanteren. Even los van het gebruik van prepared statements als alternatief lijkt mij het quoten + escapen van alle waarden (alle DATA-delen in het SQL-statement) de simpelste methode om dit te bereiken. Je doet gewoon altijd hetzelfde en het is altijd veilig. Dit is hoe in je in zijn algemeenheid met je database om zou moeten gaan: je vertrouwt niet wat je er instopt, en ook niet wat je er (weer) uithaalt, want uiteindelijk is de data die je hier in stopt van een externe bron (vaak "de gebruiker") afkomstig. En je wilt hier verder ook helemaal niet over nadenken.

Natuurlijk helpt validatie vooraf natuurlijk ook, wanneer je een numerieke waarde verwacht, dat je deze ook als zodanig controleert als je deze ontvangt, maar dit staat in principe los van het veilig maken van queries. Dit zou niet afhankelijk moeten zijn van validatie, maar dit moet op zichzelf veilig zijn. Als je dat niet doet, en je valideert iets verkeerd (of niet), dan heb je mogelijk stront in je database.

Dus nee, het is niet zozeer een eigen keuze, het is een werkwijze die dingen simpel en veilig houdt, zonder dat dit enig denkwerk kost, want dit denkwerk hoef je slechts één keer te doen. If anything is het een overwogen / onderbouwde keuze. Dat is iets anders dan een "eigen keuze", waar mogelijk een flinke portie willekeur/eigen voorkeur vanuit gaat.

Alle andere methoden, zoals het onderscheid maken tussen wat wel en wat niet ge-escaped hoeft te worden maakt alles alleen maar complexer en bovendien foutgevoeliger. Dit omdat je dan constant keuzes moet maken: wel quotes? geen quotes? wel escapen? niet escapen? En ook bij het nalezen van eerder opgestelde queries is dat vervelend, je moet dan constant nadenken.

De enige "eigen keuze" in dit geheel is het doorgronden van het "grotere belang" voor veilige queries en hier eens over nadenken (of niet), en dat je hierbij getallen als strings behandelt is toch echt van onderschikt belang. Immers, normaal gesproken is noch PHP noch MySQL echt typegevoelig (hell, MySQL behandelt praktisch in 9 van de 10 gevallen alles toch als string), dus waarom zou je nu ineens wel doen alsof dit uitmaakt? Dat lijkt mij meer iets in de hoek van "eigen voorkeur", zo van "meh, dit is een getal, dus ik zet hier liever geen quotes omheen". Dat klinkt als een esthetisch argument?
Gewijzigd op 21/06/2020 23:24:34 door Thomas van den Heuvel
 
PHP hulp

PHP hulp

25/11/2024 03:51:13
 
- Ariën  -
Beheerder

- Ariën -

22/06/2020 11:20:56
Quote Anchor link
Het ligt er ook een beetje aan, wat voor datatype je gebruikt. Ik heb ooit eens een ENUM gebruikt (ja, geen aanrader!) met als waarde: '0','1'. Probeer dan maar eens SELECT this, that FROM tblname WHERE this = 1.
Dat gaat hoe dan ook niks opleveren.

Maar als ik vaste waardes heb dan gooi ik er geen quotes omheen. Niemand kan dat aanpassen.
Of dat met veiligheid te maken heeft? Nope. Ik houd me eerder aan het stramien van PHP vast. Ieder zijn keuze. Als ik het later aanpas, moet je gewoon oplettend blijven! (of gezellig prepared statements gebruiken).
 
Thomas van den Heuvel

Thomas van den Heuvel

22/06/2020 15:47:30
Quote Anchor link
Ah, met "vaste waardes" bedoel je informatie die onderdeel is van de query zelf, en dus geen (variabele) externe invoer betreft. In dat geval doe je wat toepasselijk is voor het type en is geen escaping nodig, omdat dit onderdeel is van de SQL zelf, het betreft geen (externe) DATA.

Ik denk dat we het over twee verschillende dingen hebben. Het is zaak dat er ondescheid wordt gemaakt tussen de SQL- en DATA-delen in een SQL-query. Ik heb het uitsluitend over extern aangeleverde DATA. Daarbij is het wat mij betreft noodzakelijk dat alles gewoon ge-escaped wordt zodat het niet geïnterpreteerd kan worden als SQL, en om de escaping effectief te laten zijn zul je dit altijd moeten combineren met quotes. Het een is niet veilig zonder het ander, dit heb ik al meerdere keren uiteengezet in andere threads. Ik zie hier simpelweg geen ruimte voor een eigen keuze, tenzij je elke keer opnieuw, in elke query, een soort van gevalsonderscheid wilt gaan maken? Dat lijkt mij extreem vermoeiend, en totaal onnodig.

Natuurlijk zijn er gevallen waarbij het niet noodzakelijk is om te quoten en/of te escapen, maar je zult dan de query als geheel moeten interpreteren om te kunnen constateren of deze constructie veilig is. Ook rijst dan elke keer de vraag of escapen/quotes expres zijn weggelaten of per ongeluk zijn vergeten. En dit zal elke keer gebeuren als iemand zo'n query bekijkt. Als je daarentegen al deze delen gewoon voorziet van quotes en escaped dan zal dit altijd veilig zijn, en je hoeft hier nooit (meer) over na te denken; dat wil zeggen, je hoeft de query niet elke keer opnieuw te analyseren, je mag altijd over de veiligheid van je code/SQL blijven nadenken :). Dit lijkt mij gewoon veel prettiger ontwikkelen.

Als je veel code/queries schrijft dan is dit een van de plooien die je op een gegeven moment wilt gladstrijken zodat je hier verder geen omkijken meer naar hebt. Ik ben benieuwd naar een veilig en simpel alternatief (zonder gebruikmaking van prepared statements uiteraard*), zo die er een is. Hoe zou jij dit dan aanpakken @Ariën?

* en de keuze voor prepared statements heeft meer facetten dan enkel veiligheid, dus dat is in zekere zin een andere discussie
 

Pagina: « vorige 1 2



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.