testen sql-injection

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

T-SQL Database developer

Functie omschrijving Ben jij een ETL database specialist? Houd jij ervan om te puzzelen met Databases, Query's & Stored procedures? Zoek jij uitdaging, vrijheid en verantwoordelijkheid? Zoek dan niet verder! Wij zijn per direct op zoek naar medior en senior database developers. Je gaat werken voor een relatief klein softwarebedrijf in omgeving Tilburg. Samen met 12 collega's (allemaal techneuten), ga jij je bezig houden met het bouwen en/of onderhouden van database software. Deze software wordt internationaal ingezet voor het automatiseren van logistieke processen. Jouw werkzaamheden gaan er als volgt uit zien: Je bent in een klein team met developers, verantwoordelijk

Bekijk vacature »

Junior .NET developer

Functie Ons programma is voor afgestudeerde enthousiastelingen die het als een uitdaging zien om met een klein dynamisch team bij de grootste bedrijven van Nederland aan de slag te gaan. Tijdens jouw dienstverband word jij begeleid door een talent manager. Het ontwikkelen van jouw talent staat hierbij centraal. Het programma doorloop je met een team van circa 8 Mede- trainees. De eerste maand start je met een fulltime inhouse opleiding. Deze staat geheel in het teken van de werkzaamheden die jij verder in het programma zult uitvoeren. Na deze opleidingsmaand ga je aan de slag in een dynamische omgeving bij

Bekijk vacature »

.NET Developer

Dit ga je doen (Door)Ontwikkelen van het applicatielandschap; (Door)Ontwikkelen van microservices; Bouwen van nieuwe functionaliteiten; Verbeteringen aandragen voor het applicatielandschap; Sparren met de business. Hier ga je werken De organisatie is werkzaam in de financiële dienstverlening met meer dan 200 medewerkers en meer dan 250.000 eindgebruikers is het een van de grotere binnen haar branche. Je komt te werken in een team waarmee je verantwoordelijk bent voor het ontwikkelen en onderhouden van de financiële applicaties binnen de organisatie, denk hierbij aan het bouwen en onderhouden van portalen. Als .net developer ga jij het development team ondersteunen met de transitie naar

Bekijk vacature »

.NET developer

Functie Als ervaren .NET ontwikkelaar start jij een team met 12 programmeurs. Jullie zijn verantwoordelijk voor het huidige platform van deze organisatie. Als team werken jullie in tweewekelijkse sprints en starten jullie iedere dag met een stand-up. Jij werkt samen met jouw team aan het uitbreiden van het huidige platform door middel van nieuwe features. Daarnaast zorg jij er samen met jouw team voor dat het platform veilig is en gebruiken jullie de nieuwste technieken om deze veiligheid te waarborgen. Zo maken jullie gebruik van C# .NET, .NET Core, React, Azure, Kubernetes, ASP.NET, MVC. Jij gaat aan het werk in

Bekijk vacature »

Mendix Consultant / Developer

Dit ga je doen Het in kaart brengen en analyseren van de functionele wensen van de klant rondom Mendix applicaties; Het fungeren als sparringpartner voor de (interne) klanten; Het opstellen van requirements en het vertalen hiervan naar technische mogelijkheden; Het opstellen van user stories; Het bouwen van de Mendix applicaties in samenwerking met jouw team of zelfstandig; Het testen van op te leveren software en het zorg dragen voor de implementatie; Trainen van gebruikers in het gebruik van de applicatie; Werken in een Agile omgeving. Hier ga je werken De organisatie begeeft zich in de retail branche en focust zich

Bekijk vacature »

Full Stack PHP Developer

Functieomschrijving Ervaren PHP Developer gezocht! Wij zijn op zoek naar een ervaren PHP Developer die het IT team van een organisatie in de regio Ermelo gaat versterken. Voor deze functie zijn we op zoek naar een enthousiaste en breed georiënteerde IT-er die deze innovatieve organisatie nog een stap verder gaat brengen. Wij zijn op zoek naar iemand die communicatief goed is en die zelfstandig problemen op kan lossen. Je bent verantwoordelijk voor het samenwerken met een externe partij het is hierbij jouw taak om deze partij uit te dagen op het geleverde werk. Het schrijven van concepten aan de AI

Bekijk vacature »

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Lead C++ Developer

De rol van Lead C++ Developer Als Lead C++ developer bij KUBUS word je verantwoordelijk voor het implementatie design van requirements en de software architectuur van de desktop applicaties van BIMcollab, ons platform voor 3D model-validatie en issue-management bedoeld om de kwaliteit van 3D design-modellen voor gebouwen te verbeteren. Betere 3D modellen leiden tot betere gebouwen, dus zo draag je bij aan verduurzaming van de gebouwde omgeving met slimmer gebruik van materialen, minder verspilling en energie-efficiënte gebouwen. Een goede gebruikerservaring staat bij ons hoog in het vaandel; we gaan in onze ontwikkeling voor innovatie en kwaliteit. In je rol als

Bekijk vacature »

Frontend Developer - Leeuwarden

Als Frontend Developer bouw jij mee aan het onderwijs van de toekomst! In een scrum team werken met jonge en enthousiaste collega’s, moderne technieken, ruimte voor eigen ontwikkeling en op een proactieve wijze kunnen meewerken aan innovatie binnen het onderwijs. Magister is het state-of-the-art softwarepakket dat scholen in het voortgezet onderwijs op alle fronten ontzorgt. Van leerlingenadministratie tot het ondersteunen van individuele leerlijnen, van toegang tot digitaal lesmateriaal tot het plannen van het lesrooster. In de Magister app bedient Magister ruim 2,5 miljoen gebruikers waarvan, dagelijks meer dan 600.000 unieke. Hiermee is Magister de absolute marktleider in onderwijsland. Wat vragen

Bekijk vacature »

Teamlead PHP Developer

Functieomschrijving Voor een gewaardeerde werkgever in de buurt van Middelburg zijn wij op zoek naar een gemotiveerde teamlead PHP developer met affiniteit met Symfony/Laravel. Een enthousiast persoon die het ontwikkelteam komt versterken met het aanpakken van uitdagende projecten. Ben jij op zoek naar een uitdaging waar je de tijd en ruimte krijgt jezelf te ontwikkelen en je eigen IT-team aan te sturen? Lees dan snel verder! Die ga je doen: Bijdragen aan de implementatie van aanpassingen, verbeteringen en aanvullingen in de PHP based applicaties; Ontwikkeling en beheer van de serviceportal in Symfony en de webshops in de tweede versie van

Bekijk vacature »

Developer Full Stack

Functie omschrijving Developer gezocht! Ben jij een enthousiaste developer die graag wil bijdragen aan ontwikkelingen binnen een mooie organisatie? Solliciteer dan snel. Wij zijn op zoek naar een Full Stack Developer uit de regio Nijkerk die gaat bijdragen aan het door ontwikkelen, onderhouden en optimaliseren van een SaaS applicatie. Je moet beschikken over beheersing van zowel de Nederlandse als Engelse taal aangezien je samen met de klant gaat werken. Bedrijfsprofiel Je komt te werken binnen een echt familiebedrijf dat al sinds 1925 actief is binnen de FMCG branche. Het bedrijf heeft 40 medewerkers en er heerst een platte communicatiestructuur waarbij

Bekijk vacature »

TypeScript developer (tot € 6.000, - bruto pe

Functie Om bovenstaande ambities waar te kunnen maken zijn ze op zoek naar een ervaren Typecript developer die niet alleen zichzelf verder ontwikkelt, maar het ook leuk vinden om op termijn meer junior collega’s op pad te helpen. Je zult aan de slag gaan met het migreren van hun bestaande UI in Angular. Maar ook het ontwikkelen van een mobiele app. Hierbij hechten ze veel waarde aan User Experience en kiezen ze duidelijk voor kwaliteit i.p.v. snelheid. Je krijgt dus de ruimte om vanuit gedegen onderzoek te werk te gaan en het borgen van kwaliteit staat hoog in het vaandel.

Bekijk vacature »

Microsoft Acess Developer

Functieomschrijving Wat ga je doen? Heb jij ongeveer 3 jaar ervaring als Software Developer, en komen de volgende kennisgebieden jou niet vreemd voor: MS Acces, C# & SQL? Vind jij het daarnaast leuk om maatwerk software te ontwikkelen voor klanten in een bijzondere branche? Lees dan snel verder! Als developer ben jij samen met een gemotiveerd team van 10 collega’s verantwoordelijk voor het creëren van aangemeten software voor klanten. Je bent klantvriendelijk en oplossingsgericht ingesteld, omdat het essentieel is om de klanten zo goed mogelijk te helpen met hun uitdagingen. Het is mogelijk om vanuit huis je werkzaamheden uit te

Bekijk vacature »

Oracle APEX developer

Wat je gaat doen: Als Oracle APEX ontwikkelaar bij DPA werk je samen met collega’s aan de meest interessante opdrachten. Je zult je ervaring met SQL, PL/SQL, JavaScript, HTML en CSS inzetten om wensen van opdrachtgevers te vertalen naar technische oplossingen. Je werk is heel afwisselend, omdat DPA zich niet beperkt tot een specifieke branche. Zo ben je de ene keer bezig binnen de zorgsector, de andere keer is dit bij de overheid. Wat we vragen: Klinkt goed? Voor deze functie breng je het volgende mee: Je hebt een hbo- of universitaire opleiding afgerond Je hebt 2 tot 5 jaar

Bekijk vacature »

Medior C# Developer

You'll build modern applications for Coolblue's back office. We have a lot of friends, and they crave well-structured data and user-friendly, task-focused applications. How do I become a Medior C# Developer at Coolblue? You regularly participate in brainstorm sessions about user experience, data, and task flow with the UX Designer, Product Owner, and Data Scientists in your team. Besides that you will create disconnected, highly congruent, and testable code that can easily be maintained and is future-proof. Want to become C# Developer at Coolblue? Read below if the job suits you. You enjoy doing this Working with various types of

Bekijk vacature »
Bas van de Ven

Bas van de Ven

06/02/2015 21:16:08
Quote Anchor link
Voordat ik mijn php code wil beveiligen op sql-injection wil ik eerst een injection uitvoeren zodat ik na de beveiliging het resultaat kan vergelijken. Ik ben niet van het klakkeloos overnemen van prepared statements. Zien is geloven en snappen.

Wat ik ook probeer, uit mijn tabel tbWeeg krijg ik binnen het eerste record (weegId = 1) het veld weegkg niet gewijzigd met ' update tblWeeg set weegkg = 44 where weegId = 1; //--
Niet in een textfield en niet binnen een url. Overigens nu heeft weegkg de waarde 14.

Na submitten van het textfield wordt de waarde uit dit textfield gestopt in een variabele dmv
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php $spgewicht = $_POST['txtspnkg']; ?>


de query ziet er vervolgens zo uit :
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$query_schaap_bijwerken
= "UPDATE tblschapen SET speendm ='$spdatum', speenkg = '$spgewicht'
                              WHERE schaapId = $schaapId "
or die (mysql_error());
                mysql_query($query_schaap_bijwerken); ?>

Als ik $query_schaap_bijwerken in het script aanpas wordt het update-statement wel uitgevoerd na submitten. Ook als ik het update statement in de variabele $spgewicht stop.

Als ik het update statement in het textveld plak zie ik niets gebeuren. Wat ik met puntkomma en enkele en/of dubbele quotes ook probeer.

Is dit een teken dat mijn code al is beveiligd of kan iemand mij vertellen wat ik niet goed doe ?
Gewijzigd op 06/02/2015 21:18:45 door Bas van de Ven
 
PHP hulp

PHP hulp

28/03/2024 14:38:46
 
Ivo P

Ivo P

06/02/2015 21:20:35
Quote Anchor link
ik kan je verhaal niet geheel volgen, maar ik neem aan dat je een post doet waarbij ook dat $schaapId wordt aangeleverd?

Klopt het dat er ergens in jouw code iets staat van

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<?php $schaapId = $_POST['schaapId']; ?>


?

Dan stel ik voor om de <input name="schaapId"> te voor zien van de value

0 or 1=1

(ja, ook als die input hidden is, kan dat eenvoudig, maar misschien moet je hem voor de test even niet-hidden maken.)

Toevoeging op 06/02/2015 21:22:25:

los van het bewust proberen om de query verkeerd uit te laten voeren:

aangezien er sprake is van een gewicht, zou er ook sprake kunnen zijn van een lengte.

50cm is dan niet raar, maar iemand kan ook in inch of foot willen werken, en dan 3' invullen....
 
Bas van de Ven

Bas van de Ven

06/02/2015 21:43:13
Quote Anchor link
Klopt wat je zegt m.b.t. de variable $schaapId. Ook is dit veld idd hidden.

Wat ik als sql-injection wilde bereiken was een willekeurig update statement onderbreken (zie $query_schaap_bijwerken) door een ander update statement uit te laten voeren op een heel andere tabel. Nl. update tblWeeg set weegkg = 44 where weegId = 1; //--
Met jou voorstel heb ik ook een sql-injection bereikt. 1 veld in de hele tabel tblSchapen is nu voorzien van één en dezelfde waarde. Nu dan herstellen en moeilijker zien te maken d.m.v. een beveiliging.

Bedankt voor de hulp.
 
Ivo P

Ivo P

06/02/2015 21:59:42
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
$query_schaap_bijwerken
= "
  UPDATE tblschapen
  SET speendm ='"
. mysql_real_escape_string($spdatum) ."',
      speenkg = '"
. mysql_real_escape_string($spgewicht) ."'
  WHERE schaapId = '"
. mysql_real_escape_string($schaapId) ."'
"
or die (mysql_error());
                mysql_query($query_schaap_bijwerken);
?>


of met prepared statements.
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 00:07:48
Quote Anchor link
_real_escape_string() functies doen NIETS als er niets te escapen valt.

_real_escape_string() functies zijn geen toverformule die alles ineens goed en veilig maakt.

Quotes rond numerieke velden zetten (in combinatie met _real_escape_string()) is imo de verkeerde manier om met numerieke velden om te gaan. Het "werkt" wel, in die zin dat je query wellicht syntactisch correct is en "veilig" is, maar als je voor een id-veld "aap" invult doet je query niets, en dat schiet het doel toch een beetje voorbij.

Als je wilt/verwacht dat een veld een numerieke waarde heeft controleer hier dan op, en als deze controle niets oplevert voer de query dan in zijn geheel niet uit maar klaag dat je niet-numerieke invoer niet het juiste formaat had. Vervolgens is het wellicht een beetje loos maar imo wel goed voor de bewustwording in die zin dat je met DATA te maken hebt, en niet met SQL, om deze waarde te escapen met _real_escape_string() (maar zoals gezegd, doet dat niets). Je hoeft er dan ook niet over na te denken of iets wel of niet geescaped hoeft te worden.

Escape alle DATA-delen gewoon altijd met _real_escape_string(), en filter je invoer als je numerieke waarden verwacht... Numerieke velden hebben dan geen quotes nodig.

Wanneer je wel quotes gebruikt levert dit soms ook onvoorspelbare resultaten op. Als je namelijk vergelijkingen doet tussen numerieke waarden, en je zet hier quotes omheen, dan geldt de alfabetische sortering, en niet de numerieke sortering:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
mysql> SELECT 213 > 35;
+----------+
| 213 > 35 |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT '213' > '35';
+--------------+
| '213' > '35' |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)


Als je deze vuistregels hanteert, dan zijn je queries veilig. En dit komt eigenlijk weer op de universele regel filter input, escape output neer.

En for the love of all that is good and holy, gebruik mysqli of PDO.

Tevens: voor de correcte werking van _real_escape_string() functies is het van cruciaal belang dat je (op de goede manier) de juiste character encoding selecteert. Dit doe je met een _set_charset() functie, bij voorkeur direct na het maken van een connectie met je database.

Daarnaast is het met normale "query" functies in MySQL niet mogelijk om meerdere queries tegelijkertijd uit te voeren met één functie-aanroep. Bij mijn weten levert dat te allen tijde een query fout op, maar het lijkt mij verstandig om dit ook even te testen.
Gewijzigd op 07/02/2015 00:26:20 door Thomas van den Heuvel
 
Ward van der Put
Moderator

Ward van der Put

07/02/2015 09:25:03
Quote Anchor link
>> Quotes rond numerieke velden zetten (in combinatie met _real_escape_string()) is imo de verkeerde manier om met numerieke velden om te gaan. Het "werkt" wel, in die zin dat je query wellicht syntactisch correct is en "veilig" is, maar als je voor een id-veld "aap" invult doet je query niets, en dat schiet het doel toch een beetje voorbij.

Een integer behandelen als een string is niet alleen onlogisch, maar ook nadelig voor de performance:

WHERE schaapId = '" . mysql_real_escape_string($schaapId) . "'"

De typeconversie van integers naar strings zit in de weg, vooral als je daarbij een JOIN krijgt op twee verschillende datatypen. Je kunt hier veel beter een cast naar een integer gebruiken:

WHERE schaapId = ' . (int)$schaapId
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 13:29:35
Quote Anchor link
Laten we het over types in PHP hebben :).

test.php?id=12

$_GET['id'] is ook een string... Alle data in $_GET en $_POST zijn strings.

Een typecast is ongewenst, omdat het een variabele probeert om te zetten naar een vorm die deze variabele mogelijk helemaal niet heeft.

test.php?id=aap

Jouw typecast zet $_GET['id'] om naar het cijfer 0.

In mijn aanpak moet je waarden waarbij je verwacht dat deze numeriek zijn controleren of deze ook daadwerkelijk numeriek zijn. Nog voordat je je query uberhaupt uitvoert. Een query die normaal resultaten geeft maar nooit iets oplevert is altijd een verspilling.

Een numerieke waarde hoeft niet per se van een numeriek type (bijvoorbeeld integer) te zijn. Daarnaast is deze eis nogal nutteloos als je deze pur sang integer vervolgens concateneert in een string... Zolang het format van de numerieke string maar klopt. En je hier vantevoren op controleert (input filtering).

Maar goed, dit werkt voor mij, is ondubbelzinnig, heeft heldere en eenvoudige regels, levert veilige queries op en respecteert in zekere zin de types van tabelkolommen (er worden immers geen quotes om getallen gezet). Het maakt mij niet zoveel uit wat je doet, zolang je maar begrijpt waarom.

Voor zover ik weet maken de types van variabelen pas echt uit als je gebruik maakt van prepared statements. Anders wordt je hele SQL-statement sowieso als string naar je database gestuurd.
 
Ward van der Put
Moderator

Ward van der Put

07/02/2015 13:50:05
Quote Anchor link
>> Laten we het over types in PHP hebben :).

Als je PHP gebruikt om SQL te formuleren, denk ik dat je het over types in SQL en MySQL moet hebben.

Je kunt in het Nederlands wel uitleggen hoe je iets in het Engels schrijft, maar niet zonder uit te gaan van de regels voor spelling en grammatica van het Engels natuurlijk.

Maar los daarvan: een JOIN op een miljoen schapen die links een nummer (integer) hebben en rechts een naam (string), is gewoon geen goed plan.
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 14:38:12
Quote Anchor link
Ik denk dat we langs elkaar heen aan het praten zijn. Gaat jouw reactie over de database-opzet van de topicstarter? Of over het beveiligen van queries?

Natuurlijk moet je de regels van het spel (van zowel PHP als MySQL) in beschouwing nemen, dat is wat ik doe in mijn opzet, waarin ik probeer uit te leggen wat ik doe (en ook vooral waarom) om queries veilig te maken.

En als je aan het joinen bent op een tekstuele kolom kun je wel stellen dat er iets mis is met je database-ontwerp, maar het gaat hier over de beveiliging van queries, niet over de database-opzet.

Mijn voorbeeld met SELECT-statements (als je het daar over had) was bedoeld als illustratie om te laten zien wat er kan gebeuren als je overal maar klakkeloos quotes omzet als een soort van toverformule om dingen veilig te maken. Je query is dan mogelijk veilig(er) maar het kan ook ongewenste gevolgen hebben omdat de informatie op een andere manier geïnterpreteerd wordt dan de bedoeling was... Voor de duidelijkheid: ik ben er juist voor om quotes uit te bannen op plaatsen waar deze echt niet thuishoren.

Het gebruik van _real_escape_string() functies op die plekken is enkel bedoeld als een soort van bewustwording (en markering) van DATA-delen in je query, om het onderscheid tussen SQL en DATA nogmaals te onderstrepen en de denkstap die je anders elke keer moet maken (moet ik dit nu wel of niet escapen?) te elimineren.
 
Ward van der Put
Moderator

Ward van der Put

07/02/2015 14:51:11
Quote Anchor link
>> Ik denk dat we langs elkaar heen aan het praten zijn. Gaat jouw reactie over de database-opzet van de topicstarter?

De topicstarter vraagt naar SQL-injectie. SQL-injectie is mogelijk met een string, maar vrijwel onmogelijk met een integer.

Je hebt voor SQL-injectie immers een SQL-expressie nodig. Met enkel een integer kom je er niet.

Het advies om een integer te behandelen als een string is in meerdere opzichten geen goed advies. Als je integers nodig hebt maar ruimere strings accepteert, ondermijnt dat de beveiliging. En, zoals gezegd, lever je dan ook nog performance in.

Verder ben ik het wel met je eens natuurlijk: je moet verder kijken dan naar alleen de SQL-expressie met wat escapes.
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 17:11:26
Quote Anchor link
Quote:
Met enkel een integer kom je er niet.

I see. Een string die een numeriek patroon heeft behandelen / gebruiken als getal is "not done", maar een niet-numerieke string typecasten naar een integer is a-ok. Okee dan :).

Quote:
Het advies om een integer te behandelen als een string is in meerdere opzichten geen goed advies.


Waar doe ik dit dan? Alles wat uit $_GET komt (of een ander superglobal array, for that matter) is al van het type string, zij het met een mogelijk numerieke waarde, waar je op moet controleren.

Quote:
Als je integers nodig hebt maar ruimere strings accepteert, ondermijnt dat de beveiliging.


Waar doe ik dit dan? Ik had al aangegeven dat er een controle *moet* plaatsvinden op de variabele als je een numerieke waarde verwacht. Deze controle doe je bijvoorbeeld met een regexp of filter_var(). Ik accepteer *precies* wat is toegestaan, en anders niets. Daarbij controleer ik het patroon, en niet zozeer het type. PHP is sowieso loosely typed dus ik snap niet dat er zo'n grote nadruk op het type moet worden gelegd als je een legitieme controle op het format doet.

Alleen als je PDO gebruikt maakt het type van je variabele echt iets uit.

Quote:
En, zoals gezegd, lever je dan ook nog performance in.

Het uitvoeren van een regexp / filter_var controle (input filtering) is nog altijd effficiënter dan het voor niets uitvoeren van een query die weliswaar syntactisch correct is, maar nooit een resultaat oplevert.
 
Ward van der Put
Moderator

Ward van der Put

07/02/2015 17:24:24
Quote Anchor link
Thomas van den Heuvel op 07/02/2015 13:29:35:
$_GET['id'] is ook een string... Alle data in $_GET en $_POST zijn strings.

Ja, nou en?
Is dat een voldongen feit?
Of ben je programmeur?
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 17:36:36
Quote Anchor link
Quote:
Is dat een voldongen feit?
Of ben je programmeur?


Allebei. Het een sluit het ander niet uit.

Een typecast is gewoon de verkeerde oplossing voor het probleem, omdat deze mogelijk niet-toegestane invoer (?id=aap) omvormt tot iets wat wel toegestaan is ((int)$_GET['id'] == 0) maar wat vervolgens niets bruikbaars oplevert.

Het is gewoon een luie oplossing voor mensen die hun invoer niet willen controleren.
 
Ward van der Put
Moderator

Ward van der Put

07/02/2015 17:45:44
Quote Anchor link
Eens.

Het ging me ook om dat einde van de rit: er moet uiteindelijk een integer in die query, dus de cast (int) ligt daar meer voor de hand dan een functie voor een string-escape die een string oplevert.

Dat je daaraan voorafgaand méér controles uitvoert, spreekt voor zich. Upperbound en lowerbound om een bufferoverflow te voorkomen bijvoorbeeld.

Alleen een string escapen geeft schijnveiligheid. Zo heel oneens zijn we het helemaal niet, integendeel ;-)
 
Thomas van den Heuvel

Thomas van den Heuvel

07/02/2015 19:38:56
Quote Anchor link
Quote:
Het ging me ook om dat einde van de rit: er moet uiteindelijk een integer in die query, dus de cast (int) ligt daar meer voor de hand dan een functie voor een string-escape die een string oplevert.

Ik snap ook wel dat dat niets doet, maar dat heeft een hele andere reden: dat doe ik om die invoer als DATA-deel (externe input) te markeren in je SQL-statement. Dit om het onderscheid DATA-SQL gewoon glashelder te houden en niet zozeer om veiligheidsredenen, de invoer zou met controles al veilig moeten zijn in dat geval.

Ook al is dat in dat specifieke geval dus niet nodig (je hebt je invoer al gecontroleerd of desnoods een typecast gedaan :)), je hoeft dan in ieder geval de overweging niet eens meer te maken of dat onderdeel wel of niet ge-escaped moet worden, je behandelt *alle* DATA-delen gewoon op één uniforme manier. Hiermee elimineer je een denkstap en kun je het ook nooit fout doen (een keer niet doen terwijl het toch verstandiger bleek te zijn om wel te escapen :)).

Ik heb er nog even over na zitten denken: SQL injectie is volgens mij vaak juist mogelijk omdat invoer onvolledig wordt gecontroleerd (gebrek aan input filtering). En andere security issues in PHP-applicaties vinden haar oorsprong mogelijk in het onvolledig of niet ontdoen van de speciale betekenis die bepaalde data in een bepaalde context kan hebben (gebrek aan output escaping).

Hypothetische stelling: als je je invoer goed en volledig zou filteren, zouden functies als _real_escape_string() niet eens nodig zijn :). (Discuss.... :S)

De oplossing met gebruikmaking van een typecast stuurt weg van het oorspronkelijke probleem waarbij bepaalde data een bepaald format zou moeten hebben (en daarbij heb ik het dus nog niet eens over het type van die data).

Bij mijn aanpak pas ik "filter input, escape output" zo vaak en zo volledig mogelijk toe, waarbij ik een groot bewustzijn voor mijzelf creeer van alles wat INPUT en OUTPUT is. Hierbij kan ik veel meer security-zaken samenvatten en op een uniforme manier tacklen. Dit gaat dus om een integrale aanpak, en voert verder dan het veilig(er) maken van mijn queries.

Quote:
Alleen een string escapen geeft schijnveiligheid.

Dat alleen is soms niet genoeg inderdaad. Een mooi voorbeeld daarvan (van hoe het niet moet) is PDO - ik ken developers die denken dat omdat ze van (gesimuleerde) prepared statements gebruik maken, ze daarom geen invoer meer hoeven te controleren. Sterker nog, ze zijn zich daarvan niet eens bewust dat ze dat niet doen... Ze snappen gewoon geen biet van de achterliggende materie. Je bent wat mij betreft dan niet veilig en netjes aan het programmeren, maar gewoon wat apentrucs aan het uitvoeren.

EDIT: dit dus:
Afbeelding
Gewijzigd op 07/02/2015 20:26:36 door Thomas van den Heuvel
 
Ivo P

Ivo P

08/02/2015 00:12:05
Quote Anchor link
Quote:
Hypothetische stelling: als je je invoer goed en volledig zou filteren, zouden functies als _real_escape_string() niet eens nodig zijn :). (Discuss.... :S)


Soms staat er heel legitiem een ' in een tekst.
Daar kan en mag je niet op filteren. Daar zul je dus altijd een escape op los moeten laten.

Het gaat daar dus niet eens om sql-injectie, maar gewoon om 'hoe voer ik een apostroph in'
 
Thomas van den Heuvel

Thomas van den Heuvel

08/02/2015 00:29:47
Quote Anchor link
Dat was niet het punt wat ik probeerde te maken. Wat ik bedoelde is, dat als er van tevoren een controle zou zijn, dat je dan vervolgens geen ongewenste karakters (die de controle/filter niet door zou moeten laten, obviously) hoeft te escapen of anderszins laat verdwijnen. Tis ook maar net wat je als "toegestaan" definieert he.

Deze stelling was ook min of meer als "grap" bedoeld, maar nu gaat er iemand serieus op in :(.

Damn...

Afbeelding
Gewijzigd op 08/02/2015 00:33:18 door Thomas van den Heuvel
 
Dos Moonen

Dos Moonen

08/02/2015 21:10:55
Quote Anchor link
"Is dit een teken dat mijn code al is beveiligd of kan iemand mij vertellen wat ik niet goed doe ?"
Je code is veilig van query stacking zolang je de MySQL extensie blijft gebruiken. Als je de MySQLi extensie gebruikt (wat je hoort te doen als je jezelf serieus wilt nemen) ben je veilig zolang je mysqli_multi_query() (of de OO versie) niet gebruikt.

Een andere tabel updaten gaat je niet lukken met, je kan wel $spgewicht injecteren en zo andere velden aanpassen.
Als $schaapId ook te beinvloeden is door de gebruiker kan hij/zij zorgen dat ALLES aangepast wordt.

Voorbeelden van SQL-injection zoals die strip zijn niet heel handig in combinatie met MySQL en het PHP-platform.

Interessant en gaat specifiek over MySQL:
https://www.blackhat.com/presentations/bh-usa-09/DZULFAKAR/BHUSA09-Dzulfakar-MySQLExploit-PAPER.pdf

Hopelijk is het nadat je dat allemaal verteerd hebt duidelijk waarom je de tabel tbWeeg niet aangepast krijgt.
 



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.