testen sql-injection

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Junior Developer C#

Je maakt een vliegende start van je carrière bij Coolblue, door meteen mee te werken in een team. Wat doe je als Junior Developer C# bij Coolblue? Als Junior Developer ben je meteen vanaf de start onderdeel van een van de development teams. Omdat je jezelf graag nog verder wilt ontwikkelen, kijk je veel met je collega’s mee en volg je verschillende trainingen. Maar in de sprints pak je ook je eigen stories op, om meteen Coolblue iedere dag een beetje beter te kunnen maken. Ook junior developer C# worden bij Coolblue? Lees hieronder of het bij je past. Dit

Bekijk vacature »

Senior C# Developer

UPS Nederland zoekt een Senior Developer C# * Remote werken mogelijk Wil jij werken aan complexe IT-systemen bij een van de grootste logistieke werkgevers ter wereld? Als ontwikkelaar bij UPS werk je aan opkomende technologieën en DevOps processen om ervoor te zorgen dat onze logistieke processen zo soepel en efficiënt mogelijk verlopen. Dit ga je doen Je bent betrokken bij alle facetten van applicatieontwikkeling. Je bent betrokken bij alle facetten van applicatieontwikkeling: van ontwerpen en bouwen tot testen en implementeren. Je levert ontwerpen die passen bij de onderliggende frameworks en concepten, bouwt efficiënte en testbare code, identificeert en integreert modulaire

Bekijk vacature »

Dynamics NAV / 365 BC Developer

Bedrijfsomschrijving Als Dynamics Business Central Developer kom je te werken bij een organisatie in regio Ede die gespecialiseerd is in het ontwikkelen en implementeren van software. Zo hebben ze een eigen ontwikkelde applicatie in de markt gezet voor de agrarische sector die internationaal zeer succesvol is en waar grote vraag naar is. Door deze software worden klanten op een slimme manier ondersteund bij voorraden, administratie, het maken van planningen, het tonen van real time informatie en nog veel meer. Dit platform is ontwikkeld op basis van Dynamics 365 Business Central, waar bovenop applicaties middels .NET Core, React en Azure worden

Bekijk vacature »

Senior C#.Net Developer - Logistieke (zeevaart) se

Voor een hechte, informele en jonge club gespecialiseerd in Transport Management Systemen voor de vracht en havensector zijn wij op zoek naar een Senior .Net C# Developer. Een goede, sociale communicator die samenwerking en passie voor het vak key vindt. En die durft te sparren, dromen en pionieren! Deze organisatie van 150 man (waarvan 9 IT-toppers) zorgen er al 30 jaar voor dat internationale transport tot in de details kunnen worden berekend, ingepland en gemanaged, bijvoorbeeld in de Rotterdamse haven. Hierdoor worden kosten, materialen, arbeid, ontwerpen en oplevering perfect en just-in-time op elkaar afgestemd. Ze zijn marktleider én pionier in

Bekijk vacature »

Cloud Engineer

Senior Cloud Engineer Welkomstbonus van € 5.000,- Bij T2 zorgen we goed voor elkaar en doen wij leuke dingen met leuke mensen. We zorgen voor uitdagende opdrachten zodat jij jezelf onbeperkt kan blijven ontwikkelen. Ben jij een ervaren Cloud Engineer en wil je het beste uit jezelf halen? Dan ben je van harte welkom bij T2 en ontvang je onze welkomstbonus ter waarde van € 5.000,-. Wat mag je nog meer verwachten? Als je met ons de uitdaging aangaat dan bieden we je het volgende: Dienstverband voor onbepaalde tijd Salaris tussen de € 4.000,- en € 4.500,- bruto per maand

Bekijk vacature »

C/C++ Developer

Bedrijfsomschrijving Als Software ontwikkelaar C/C++ kom je te werken bij een toonaangevende organisatie in de mobiliteitsbranche die door het produceren van slimme producten Nederland steeds leefbaarder maakt! Ze ontwikkelen innovatieve producten die er onder andere voor zorgen dat de infrastructuur in Nederland op de snelste en meeste efficiënte manier kan worden geregeld. Als C/C++ ontwikkelaar kom je te werken op een afdeling met 40 collega's, bestaande uit Engineers, deskundigen en ontwikkelaars. Hiervoor werk je nauw samen in een team met ongeveer tien andere ontwikkelaars. Samen met het team pak je zelfstandig projecten op die doorgaans een doorlooptijd hebben van 4

Bekijk vacature »

Applicatiebeheerder (ervaren)

NWO-I zoekt een ervaren functioneel applicatiebeheerder financieel systeem (minimaal 32 uur per week) Voor het beheren, optimaliseren en (door)ontwikkelen van de aanwezige financiële applicaties, teneinde het gebruiksgemak en beschikbaarheid te waarborgen en processen adequaat te ondersteunen. Functioneel Applicatiebeheerder financieel systeem U4ERP Ben jij onze nieuwe, enthousiaste en ervaren, professionele collega, die bij ons als meewerkend voorman/vrouw, zijn/haar kennis en ervaring in wil brengen en het vak van functioneel applicatiebeheerder wil uitoefenen en affiniteit heeft met financiën? Als meewerkend voorman/vrouw ben je de vooruitgeschoven post naar de organisatie van het team van applicatiebeheerders. Het team wordt met jouw komst uitgebreid en

Bekijk vacature »

Java Developer / Webservices / Overheid

Bedrijfsomschrijving De organisatie waar je komt te werken is een semi-overheidsinstelling die zorgt voor een goede samenwerking tussen verschillende overheidsinstanties. Het is een familiaire club die gaat voor kwaliteit en langdurige relaties. Het bedrijf is gevestigd in hartje Utrecht met het Centraal Station op loopafstand en een parkeergarage naast het pand. Bij deze stabiele organisatie gaat men uit van kwaliteit hoogwaardige softwarediensten. Je zal hier als Java Ontwikkelaar geen projecten tegenkomen waar je uit commercieel oogpunt jouw werk zo snel mogelijk af moet leveren. Uiteraard zal je hier wel het beste uit jezelf moeten halen, maar hierbij ligt het zwaartepunt

Bekijk vacature »

GIS Developer

Bedrijfsomschrijving Als GIS Developer kom je te werken bij een high-tech ingenieursbureau in de regio van Utrecht. Al ruim 15 jaar werken ze aan de eigen ontwikkeling van innovatieve applicaties op het gebied van mobiliteit en infrastructuur. Met al hun jaren ervaring bedenken en ontwikkelen ze geografische oplossingen voor grote en bekende organisaties in Nederland. Momenteel maken duizenden gebruikers gebruik van hun applicaties en proberen ze constant vernieuwend te zijn in hun aanbod naar klanten. Je komt te werken in een informeel Agile minded team van 25 collega's, waarvan 6 andere (GIS) developers. Als Developer ben je in teamverband verantwoordelijk

Bekijk vacature »

Fullstack Java Developer

Functieomschrijving Met jouw expertise zorg je als fullstack java developer voor de meest plezierige en efficiënte klant ervaring. Met jouw state-of-the-art-systemen verbeter je onze business en maak je echt impact! Want als je in ons tech team werkt, houd je jezelf en Nederland in beweging. Wij zijn continu bezig onze business en processen te optimaliseren, zodat we onze klanten en kandidaten meer gemak, snelheid en transparantie kunnen bieden. Impactvolle tech, daar doen we het voor. wat ga je doen? Samen met het team ontwikkelen van user stories op de backlog; Begeleiden van (meer junior) collega’s; Samenwerken met andere online teams;

Bekijk vacature »

Front-End Developer

Als Front-End Developer bij Coolblue verbeter je de gebruiksvriendelijkheid van onze webshop voor miljoenen klanten. Wat doe je als Front-End Developer bij Coolblue? Als Front-end Developer werk je aan de gebruiksvriendelijkheid van onze webshop voor miljoenen klanten. Je vindt het leuk om samen te werken met de UX designer om stories op te pakken. Je krijgt energie van het bedenken van creatieve oplossingen en presenteert dit graag binnen het team. Ook ben je trots op je werk en verwelkomt alle feedback. Ook Front-end Developer worden bij Coolblue? Lees hieronder of het bij je past. Dit vind je leuk om te

Bekijk vacature »

Developer DataPower & Message Queiuing

Bedrijfsomschrijving Je komt als DataPower developer te werken in de regio Deventer/Apeldoorn bij een van de meest complexe IT omgevingen van Nederland. De organisatie is constant in beweging en bezig met de nieuwste tools en technieken, het is een platform waar immers miljoenen (!) gebruikers van afhankelijk zijn. De organisatie werkt met grote hoeveelheden data, zij richten zich zowel op de B2B als B2C markten en zijn pionier binnen hun gebied van expertise. Je komt te werken in een team met de beste DataPower specialisten die Nederland kent. Je zal bezig zijn met het ontwerpen, bouwen en testen op het

Bekijk vacature »

Lead Developer / C#.NET / coördinatie / meewe

Bedrijfsomschrijving Bij dit innovatieve productiebedrijf met 1000+ medewerkers wordt maatwerksoftware gemaakt, van het totale ERP pakket tot applicaties waar externe klanten gebruik van maken. Deze software wordt ontwikkeld met technieken als C#, .NET Core, ASP.NET, JSON en webservices met een front-end van Javascript / Angular. De nadruk ligt op de back-end. Als Lead Developer ben jij degene die het overzicht houdt op het ontwikkelproces van begin tot eind, je bepaalt de architectuur en stuurt het team van zo'n 5 ontwikkelaars aan. Wanneer er vanuit de business verzoeken komen voor nieuwe features of aanpassingen, ben jij degene die prioriteiten bepaalt. Je

Bekijk vacature »

Ervaren C#/Azure developer werkt mee aan backend p

Voor een innovatieve bouwonderneming die al meer dan 113 jaar bestaat, zijn wij op zoek naar ervaren .Net/C#/Azure developers. Het bedrijf bouwt een (pre-fab) huizenfabriek die 4000 woningen per jaar kan produceren. Deze woningen worden dan modulair op de bouwplaats in elkaar gezet en worden met duurzame (recyclebare) materialen gemaakt en geplaatst. Dit zonder PFAS en zeer weinig NOX. Als .Net developer maak je deel uit van een multidisciplinair team met andere .net developers, BI consultant, systeem- en applicatiebeheerders. Je gaat meebouwen aan de middleware-laag waar 30+ applicaties (waaronder erp systemen) gekoppeld kunnen worden. Deze integraties komen samen op het

Bekijk vacature »

Senior C# Developer

We’re Hiring! A UPS Senior C# Developer *REMOTE WORK POSSIBLE FOR THIS ROLE* UPS is the world's largest package delivery company – with a strong and recognizable brand, and a legendary reputation for great service. We are looking for an enthusiastic Senior C# Developer to join our IT Team, As a Senior Developer at UPS you work on delivering functionality for highly complex IT systems. You collaborate in agile teams and participate in emerging technologies and processes like CI/CD and DevOps to ensure that we meet our objectives effectively and efficiently. Your primary role is to perform full system life

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

11/04/2021 23:10:25
 
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:
http://imgs.xkcd.com/comics/exploits_of_a_mom.png
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...

http://images.sodahead.com/blogs/000328093/picard_facepalm_xlarge.jpeg
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.