[PHP] SQL injection?

vrijdag 14 oktober 2005 21:02

Acties:

0 Henk 'm!

me Robtimus no like you

Topicstarter

Ik heb wel vaker gelezen over het gevaar van SQL injection, dus ik ben het maar even wezen testen.

Zowel met GET als met POST, de GET zowel met een form als in de browser adresbalk. Alle 3 de situaties een variabele met naam query de waarde '; delete from table; select * from table where field=' gegeven. Met de gebruikte query (zie onder) zou dit zonder escaping het volgende opleveren:
SELECT * FROM table WHERE field=''; delete from table; select * from table where field=''

Behoorlijk link dus.
Alleen, in alle drie de gevallen worden de $postquery en $getquery variabelen netjes automatisch escaped, zowel onder mijn lokale installatie op het werk (test bak, IIS4 + PHP4.3.10) als bij mijn hosting provider (Apache, PHP 4.3.2). Doe ik hetzelfde in ASP dan is er geen auto escaping en dus wel degelijk groot gevaar.

Is dit gevaar voor PHP inderdaad zo overdreven, of zie ik iets over het hoofd?

Test code:

PHP:

<html>
<body>
<form action="" method="post">
<input type="text" name="query">
<input type="submit">
</form>
<form action="" method="get">
<input type="text" name="query">
<input type="submit">
</form>
<p>
<?
    $postquery = $_POST["query"];
    $getquery = $_GET["query"];
    $postquery = "SELECT * FROM table WHERE field='$postquery'";
    $getquery = "SELECT * FROM table WHERE field='$getquery'";
    print "$postquery<br>$getquery";
?>
</p>
</body>
</html>

[ Voor 15% gewijzigd door Robtimus op 14-10-2005 21:03 ]

More than meets the eye
There is no I in TEAM... but there is ME
system specs

vrijdag 14 oktober 2005 21:05

Acties:

0 Henk 'm!

curry684

left part of the evil twins

Als je even je phpinfo() checkt zul je daar magic_quotes_gpc aan zien staan, welke automatisch escapet voor MySQL. Groot risico is dus dat je brakke code goed lijkt te werken omdat die functie aan staat, en je op een dag migreert naar een server waar het uit staat..... of een andere DB gebruikt..... en dan heb je enorme problemen

Dus ja je ziet wat over het hoofd, en nee het risico van SQL injection kun je niet overdrijven

[ Voor 14% gewijzigd door curry684 op 14-10-2005 21:06 ]

Professionele website nodig?

vrijdag 14 oktober 2005 21:05

Acties:

0 Henk 'm!

Voutloos

Volgens mij heb je stiekem magic quotes aanstaan.

edit:
Curry

. Korte versie: vertrouw nooit zomaar op magische dingen.

[ Voor 45% gewijzigd door Voutloos op 14-10-2005 21:06 ]

{signature}

vrijdag 14 oktober 2005 21:06

Acties:

0 Henk 'm!

Y0ur1

zoek eens op magic_quotes.

vrijdag 14 oktober 2005 21:07

Acties:

0 Henk 'm!

Robtimus

me Robtimus no like you

Topicstarter

Ah kijk, dus het gevaar kan inderdaad door PHP (gedeeltelijk) opgelost worden - zolang je dat maar zelf enabled.
Ik vroeg het me gewoon af omdat die test het goed leek te doen.

More than meets the eye
There is no I in TEAM... but there is ME
system specs

zaterdag 15 oktober 2005 00:06

Acties:

0 Henk 'm!

Thralas

Let op dat je om ELKE variabele quotes gebruikt, dus óók bij integers (nog beter is het om waardes die een int zouden moeten zijn, te checken met is_int().

PHP:

1	$query = "SELECT * FROM foo WHERE id = ".$_GET['var'];

magic_quotes_gpc = true helpt hier niet, vervolgens kunnen er met een UNION en LOAD_FILE() érg vervelende dingen gebeuren.

zaterdag 15 oktober 2005 01:02

Acties:

0 Henk 'm!

Jurgle

100% Compatible

magic_quotes_gpc is toch niet alleen voor MySQL? De GPC staat toch juist voor GET, POST en COOKIE? Kortom, voordat variabelen van de client je code inkomen (dus get, post en cookie data) worden ze ge-addslashes()-ed als m_q_gpc aanstaat?

[ Voor 5% gewijzigd door Jurgle op 15-10-2005 01:03 ]

My opinions may have changed but not the fact that I am right ― Ashleigh Brilliant

zaterdag 15 oktober 2005 01:05

Acties:

0 Henk 'm!

crisp

Devver

Pixelated

Php

Jurgle schreef op zaterdag 15 oktober 2005 @ 01:02:
magic_quotes_gpc is toch niet alleen voor MySQL? De GPC staat toch juist voor GET, POST en COOKIE? Kortom, voordat variabelen van de client je code inkomen (dus get, post en cookie data) worden ze ge-addslashes()-ed als m_q_gpc aanstaat?

Ja, en dat maakt het ook een nutteloze feature want in veel gevallen wil je die slashes helemaal niet...
Overigens worden ook sommige $_SERVER variabelen ongevraagd van slashes voorzien met deze 'feature'

Intentionally left blank

zaterdag 15 oktober 2005 01:06

Acties:

0 Henk 'm!

Voutloos

Het is inderdaad niet alleen tegen SQL injection. Dingen als addslashes en/of mysql_real_escape_string zou je altijd moeten gebruiken. Ook het checken of iets inderdaad het type variabele is (met isInteger etc) is bij elke taal welke input accepteert good practice.

Je moet gewoon zelf begrijpen wat er gebeurt en zelf dingen afvangen in plaats van vertrouwen op een trucje welke ook nog mogelijk ongewenste neveneffecten heeft.

edit:
Nav Glowmouse hieronder:

Je hebt helemaal gelijk, maar adhv mijn 2e alinea zoul duidelijk moeten zijn dat ik magic quotes niet wil gebruiken. Ik wil op mijn eigen code kunnen vertrouwen en niet op een parameter of mogelijk wisselende feature van de server of PHP.

[ Voor 50% gewijzigd door Voutloos op 15-10-2005 12:36 ]

{signature}

zaterdag 15 oktober 2005 01:16

Acties:

0 Henk 'm!

GlowMouse

Voutloos schreef op zaterdag 15 oktober 2005 @ 01:06:
Dingen als addslashes en/of mysql_real_escape_string zou je altijd moeten gebruiken.

.....tenzij magic_quotes_gpc aanstaat. Anders krijg je dingen dubbel geëscaped.

zaterdag 15 oktober 2005 01:26

Acties:

0 Henk 'm!

killingdjef

Is dit SQL-Injectie probleem alleen aanwezig bij PHP? Of hebben "serieuzere talen" er ook mee te maken? (.ASP, JSP etc.)?

TS zei wel dat er een zwak in .ASP zat als ik het goed begreep maar ik vraag me dus af of zo iets het kaf van het koren scheidt.. oftwel.. het ASP van het PHP

[ Voor 3% gewijzigd door killingdjef op 15-10-2005 01:27 ]

zaterdag 15 oktober 2005 01:28

Acties:

0 Henk 'm!

disjfa

be

killingdjef schreef op zaterdag 15 oktober 2005 @ 01:26:
Is dit SQL-Injectie probleem alleen aanwezig bij PHP? Of hebben "serieuzere talen" er ook mee te maken? (.ASP, JSP etc.)?

Alle script talen hebben er last van. Ik wil niet meer zeggen dan duh

disjfa - disj·fa (meneer)
disjfa.nl

zaterdag 15 oktober 2005 01:35

Acties:

0 Henk 'm!

McKaamos

Master of the Edit-button

killingdjef schreef op zaterdag 15 oktober 2005 @ 01:26:
Is dit SQL-Injectie probleem alleen aanwezig bij PHP? Of hebben "serieuzere talen" er ook mee te maken? (.ASP, JSP etc.)?

TS zei wel dat er een zwak in .ASP zat als ik het goed begreep maar ik vraag me dus af of zo iets het kaf van het koren scheidt.. oftwel.. het ASP van het PHP

sinds wanneer is PHP geen serieuze taal dan? omdat het uit de opensource community komt? omdat het je niks kost?
en jah, andere talen hebben netzogoed last van sql-injectie problemen. je scripts zijn net zo veilig als jij ze kan programmeren (afgezien van mogelijke ongepatchte lekken op je server natuurlijk).
als jij zomaar user-ingevoerde code gaat lopen uitvoeren zonder te controleren, loop je natuurlijk dikke kans om slachtoffer te worden.

Iemand een Tina2 in de aanbieding?

zaterdag 15 oktober 2005 01:37

Acties:

0 Henk 'm!

PowerSp00n

There is no spoon

Misschien gelijk een mooi topic om het volgende voor te leggen; wat vinden we van de prepared statements van onder andere de Database class in PEAR of PDO nu in de nieuwere PHP versies? En dan doel ik dus op de mogelijkheid om placeholders aan te geven en hier vervolgens gegevens aan te binden die dan op de correcte manier in de SQL query worden 'verwerkt'.

Ik zag eerder al dat dit een mogelijkheid is van de genoemde PEAR classes, maar nu met PDO ben ik er eens wat mee gaan testen. Wil natuurlijk niet zeggen dat je helemaal niet meer op input hoeft te checken maar SQL injections onderschept het toch wel?

zaterdag 15 oktober 2005 03:57

Acties:

0 Henk 'm!

T-MOB

PowerSp00n schreef op zaterdag 15 oktober 2005 @ 01:37:
Misschien gelijk een mooi topic om het volgende voor te leggen; wat vinden we van de prepared statements van onder andere de Database class in PEAR of PDO nu in de nieuwere PHP versies? En dan doel ik dus op de mogelijkheid om placeholders aan te geven en hier vervolgens gegevens aan te binden die dan op de correcte manier in de SQL query worden 'verwerkt'.

Persoonlijk zie ik het nut niet van een extra laag tussen applicatie en database, anders dan de mogelijkheid om meerdere DBMSen te ondersteunen. Voor het reduceren van mogelijke injectiefouten lijkt het me sowieso geen geslaagd plan. Meer lagen code leidt logischerwijs tot meer kans op fouten. Daarnaast moet je zo'n klasse kunnen doorgronden om potentiële veiligheidsproblemen te voorzien. Als je dat kunt, kun je ook wel op eigen kracht veilige queries genereren. Vanuit veiligheidsperspectief verwacht ik aldus weinig van zo'n klasse, het zijn imho andere kwaliteiten waarvoor je voor zoiets zou moeten kiezen.

Regeren is vooruitschuiven

zaterdag 15 oktober 2005 08:56

Acties:

0 Henk 'm!

Grijze Vos

wat je ook redelijk vaak ziet bovenaan iemands' code is iets als

PHP:

if(!m_q_gpc)
{
  doe_zelf_maar_even_addslashen_op_gpc()
}

Kan niet zeggen dat ik tot nu toe problemen heb gehad met magische $_SERVER dingetjes, zoals sommigen hier aangeven..

(Er is overigens nog een andere "magische" protectie in PHP, hij voert geen 2 queries uit in 1 mysql_query statement.)

T-MOB schreef op zaterdag 15 oktober 2005 @ 03:57:
Meer lagen code leidt logischerwijs tot meer kans op fouten.

Daar ben ik het niet mee eens. Laeyering pas je juist toe om je code helder en overzichtelijk te houden.

[ Voor 51% gewijzigd door Grijze Vos op 15-10-2005 09:02 ]

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zaterdag 15 oktober 2005 09:12

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Grijze Vos schreef op zaterdag 15 oktober 2005 @ 08:56:
wat je ook redelijk vaak ziet bovenaan iemands' code is iets als
PHP:
1
2
3
4
if(!m_q_gpc)
{
  doe_zelf_maar_even_addslashen_op_gpc()
}
Kan niet zeggen dat ik tot nu toe problemen heb gehad met magische $_SERVER dingetjes, zoals sommigen hier aangeven..

Ik doe het meestal andersom, als die magische meuk aanstaat verwijder ik die slashes weer, hoewel ik tegenwoordig gewoon een error trigger en stop met de verdere uitvoer. Alleen als je zelf de variabelen verwerkt kan je echt veilig werken en hoef je niet te klooien met removeslashes als je een input var ergens anders voor wilt gebruiken.
mysql_real_escape_string() doet zijn werk veel beter

(Er is overigens nog een andere "magische" protectie in PHP, hij voert geen 2 queries uit in 1 mysql_query statement.)

Dat is nu zo, maar deze werking is niet gegarandeerd voor de toekomst en/of andere database connecties.

Daar ben ik het niet mee eens. Laeyering pas je juist toe om je code helder en overzichtelijk te houden.

mee eens, door een extra laag hou je je code schoon en overzichtelijk, althans als je het goed toepast natuurlijk

zaterdag 15 oktober 2005 09:44

Acties:

0 Henk 'm!

Wacky

Dr. Lektroluv \o/

Purechaos schreef op zaterdag 15 oktober 2005 @ 00:06:
Let op dat je om ELKE variabele quotes gebruikt, dus óók bij integers (nog beter is het om waardes die een int zouden moeten zijn, te checken met is_int().

is_int gaat niet werken, aangezien GET en POST variabelen altijd strings zijn. Hiervoor hebben ze is_numeric uitgevonden

Nu ook met Flickr account

zaterdag 15 oktober 2005 10:16

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Ik cast meestal direct naar een integer, als het iets onbekends is dan is de waarde 0, waar ik vrede mee heb.

zaterdag 15 oktober 2005 11:53

Acties:

0 Henk 'm!

ShadowLord

Ik gebruik zelf altijd een eigengemaakte sprintf-alike functie, zodat ik kan doen:

PHP:

1	$db->query("SELECT id, name FROM mylist WHERE status=%d AND type='%s'", $_REQUEST["status"], addslashes($_REQUEST["type"]));

Dit filtert automatisch de ints (ze worden 0 als het invalid data is) en de string wordt correct geescaped met addslashes. Ik gebruik nu toevallig een MSSQL server waarbij je dus addslashes moet gebruiken EN je de Sybase optie (zie php manual) aanzetten zodat ie single quotes escaped met nog een single quote ipv. een backslash.

You see things; and you say, "Why?" But I dream things that never were; and I say, "Why not?"

zaterdag 15 oktober 2005 12:13

Acties:

0 Henk 'm!

frickY

Purechaos schreef op zaterdag 15 oktober 2005 @ 00:06:
Let op dat je om ELKE variabele quotes gebruikt, dus óók bij integers (nog beter is het om waardes die een int zouden moeten zijn, te checken met is_int().
PHP:
1
$query = "SELECT * FROM foo WHERE id = ".$_GET['var'];
magic_quotes_gpc = true helpt hier niet, vervolgens kunnen er met een UNION en LOAD_FILE() érg vervelende dingen gebeuren.

Daarmee help je dus direct een deel van je MySQL performance omzeep.
Gebruik liever, zoals je zelf al aanhaalt, of de waarde numeriek is met is_numeric()

[ Voor 7% gewijzigd door frickY op 15-10-2005 12:14 ]

zaterdag 15 oktober 2005 12:33

Acties:

0 Henk 'm!

matthijsln

Je hoeft helemaal niet aan escapen te denken als je gewoon query parameters gebruikt.

zaterdag 15 oktober 2005 14:26

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

killingdjef schreef op zaterdag 15 oktober 2005 @ 01:26:
Is dit SQL-Injectie probleem alleen aanwezig bij PHP? Of hebben "serieuzere talen" er ook mee te maken? (.ASP, JSP etc.)?

TS zei wel dat er een zwak in .ASP zat als ik het goed begreep maar ik vraag me dus af of zo iets het kaf van het koren scheidt.. oftwel.. het ASP van het PHP

Het komt overal voor waar queries on-the-fly aangemaakt worden en er daarbij gebruik gemaakt wordt van externe variabelen. Als je je queries dus zelf voorziet van parameters ("select ...." + var + " ...", maar ook query.replace("%iets%", varIets).
Een paar jaar geleden had ik een practicum webapplicatie programmeren en daarbij waren veel van de ASP-apps van de medestudenten kwetsbaar voor allerlei foutjes (integer overflow, sql-injection, e.a.). Gelukkig deed ik in het kader van dat practicum juist onderzoek naar kwetsbaarheden van applicaties van (beginnende) webprogrammeurs dus had ik een aantal praktische voorbeelden

Bij de strong-typed talen ben je een beetje in het voordeel als je netjes de goede types voor variabelen hanteert (ints/longs voor gehele getallen enzo), maar ook daar loop je zat risico als je klakkeloos variabelen in queries stopt.
Bij weak-typed talen heb je zelfs die bescherming van de verplichte typen niet eens.

Je zal in elke omgeving moeten controleren of de ingevoerde variabelen aan de verwachte eisen voldoen. Bij PHP domweg casten naar een integer is trouwens ook niet erg handig, want je kan daarna niet meer controleren of er nou foute invoer was of gewoon een 0.

Overigens is addslashes niet helemaal compatible met MySQL en helemaal niet compatible met de meeste andere databases. En hoewel het heel nobel van de php-ontwikkelaar is om ons te beschermen tegen gemene gebruikers, zie ik niet in waarom dan de addslashes-functionaliteit uitgevoerd zou moeten worden om de single quotes te escapen. Die escaped voor vrijwel elke toepassing van php die ik kan bedenken net niet de goede karakters: voor javascript te veel, voor html heb je er sowieso niks aan, voor MySQL niet alle karakters waar MySQL graag escaping voor ziet en andere juist weer overbodig, voor de meeste andere databases is het helemaal nutteloos.

In tegenstelling tot wat hier gesuggereerd wordt heb ik dan ook een voorkeur om juist de toegevoegde slashes te verwijderen en later voor het type uitvoer waar ik de strings voor wil gebruiken pas weer in het goede formaat te escapen...

matthijsln schreef op zaterdag 15 oktober 2005 @ 12:33:
Je hoeft helemaal niet aan escapen te denken als je gewoon query parameters gebruikt.

Ik geloof dat de term "parametrische queries" is, waar je dus aangeeft dat er iets op een bepaalde plek moet komen en je de database-driver ervoor laat zorgen dat het dan ook correct ingevuld wordt. Escaping komt dan voor de rekening van de database-driver en je hoeft je er zelf idd niet druk om te maken.
Wel is het verstandig dat je weet dat het gebeurt en hoe het gebeurt, je kan namelijk niet altijd parametrische queries gebruiken. Zeker niet zolang er geen ondersteuning is voor dynamische aantallen waarden in een IN()-clause en variabele filtering in de queries...

[ Voor 14% gewijzigd door ACM op 15-10-2005 14:29 ]

zaterdag 15 oktober 2005 14:48

Acties:

0 Henk 'm!

flowerp

T-MOB schreef op zaterdag 15 oktober 2005 @ 03:57:
[over prepared statements]
Persoonlijk zie ik het nut niet van een extra laag tussen applicatie en database, anders dan de mogelijkheid om meerdere DBMSen te ondersteunen.

Wat is dat nou weer voor een onzin? Voor prepared statements is helemaal geen extra laag nodig! Dat zit gewoon standaard in de low-level DB interface. Check de JDBC specificaties maar eens. In ASP.NET heb je dezelfde functionaliteit.

Je kunt met JDBC en ODBC zowieso al meerdere DBMSen ondersteunen, dus daar is al helemaal geen extra laag voor nodig. De drivers van alle moderne DBMSen implementeren gewoon direct de JDBC en/of ODBC interface, zodat het absoluut niet nodig is om de eigen specificieke interface van een driver te gebruiken.

Voor het reduceren van mogelijke injectiefouten lijkt het me sowieso geen geslaagd plan.

Care to explain?

Met prepared statements controlleerd de DB zelf of de parameter wel een value is en -kan- deze geen clauses/expressies bevatten.

Als je iets hebt als: "Select * from B where id = ?", en je voert dan een prepStatemen.setInt( aInt ); uit, dan krijg je hier domweg niet iets in als "5 OR ( 1 = 1 )". Voor strings geldt dit ook. De DB bouwt namelijk al de hele syntax tree van de query op (dat heet het preparen van het statement) en KAN dan alleen nog maar value's invullen.

Meer lagen code leidt logischerwijs tot meer kans op fouten.

Dit vind ik een dermate generaliserende uitspraak dat ik me sterk afvraag hoeveel ervaring jij eigenlijk hebt met het bouwen van systemen?

Gelaagdheid maakt code juist beter beheersbaar en reduceerd de kans op fouten. Wat denk jij dat er zou gebeuren als je bijvoorbeeld een operating systeem zou schrijven als 1 grote monolitische laag?

De geschiedenis verteld ons dan al wat er dan gebeurd: totale ellende! Vroeger, voordat het procuderele, OO, en layered denken was uitgevonden heeft men dit inderdaad geprobeerd. Google maar eens naar termen als "software crisis" in de jaren 70.

Zelfs dichter bij huis zie je het al. In mijn werk kom ik web applicaties tegen waar men dus ook geen gelaagdheid gebruikt. Het zijn JSP pagina's die in PHP style zijn gebouwd: ALLES staat door elkaar op de pagina zelf: de controller (verwerken van commando's), business logic (java code, sql code), en code voor de view (de opmaak) en dat dan allemaal door elkaar heen.

Ik kan je vertellen dat dergelijke pagina's gewoon niet te onderhouden zijn, en dat de code erop gewoon niet te hergebruiken is. Je ziet gewoon niet meer wat bij wat hoort. Er gaan bv wel 20 mogelijke flows of execution door de page. Wil je een stukje busines logic eruit halen omdat je dit elders nodig hebt, dan ben je een hele dag bezig om te ontrafelen welke code business logic is, welke controller, en welke interface.

Een hele simpele aanpak zet de controller in een aparte classe, de business logic in weer andere classes en op de pagina staat alleen HTML, web components en een minimum aan script (dus eigenlijk nooit meer dan 1 regel script na elkaar, alleen kleine conditie expressies in de attributen van de components).

Daarnaast moet je zo'n klasse kunnen doorgronden om potentiële veiligheidsproblemen te voorzien.

Beetje onzin. Ga jij ook je DB driver zelf doorgronden om potentiële veiligheidsproblemen te voorzien? Pluis je elke library functie van J2EE, ASP.NET, of PHP na voordat je deze gebruikt?

Als je dat kunt, kun je ook wel op eigen kracht veilige queries genereren.

Niet waar. Zelfs als zou je die code eerst gaan napluizen, dan doe je dit 1 malig. Je her-gebruikt deze eenmalige investering voor elke toekomstige querie die je bouwt. Op jouw manier moet je bij ELKE querie controleren of je niet per ongeluk een foutje hebt gemaakt.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 15 oktober 2005 14:51

Acties:

0 Henk 'm!

Daos

Het is in SQL toch zo dat je elke ' moet vervangen door twee van die dingen?

code:

' --> ''

zaterdag 15 oktober 2005 14:52

Acties:

0 Henk 'm!

curry684

left part of the evil twins

FireWurX schreef op zaterdag 15 oktober 2005 @ 01:35:
[...]

sinds wanneer is PHP geen serieuze taal dan? omdat het uit de opensource community komt? omdat het je niks kost?

Nee, omdat het bagger opgezet is, een rukparser heeft, en bij iedere major release alle compatibiliteit breekt. Maar dat is offtopic hier

Professionele website nodig?

zaterdag 15 oktober 2005 14:56

Acties:

0 Henk 'm!

Voutloos

Daos schreef op zaterdag 15 oktober 2005 @ 14:51:
Het is in SQL toch zo dat je elke ' moet vervangen door twee van die dingen?
code:
1
' --> ''

Nee, dat is niet zo. Je moet gewoon weten (en liefst ook begrijpen waarom

) wat, hoe en wanneer je iets moet escapen. In een SQL query kan je best iets met enkele quotes doen.

[ Voor 38% gewijzigd door Voutloos op 15-10-2005 14:57 ]

{signature}

zaterdag 15 oktober 2005 15:10

Acties:

0 Henk 'm!

PierreAronnax

Is het gebruik van mysql_escape_string om je $_POST input voldoende om SQL injection tegen te gaan?

Pierre - Motormedia.nl - Motor-Forum.nl - Motorshopper.nl - Motormeuk.nl - Motorstek.nl

zaterdag 15 oktober 2005 15:37

Acties:

0 Henk 'm!

Erkens

Fotograaf

Php

Elke string die ik met PHP naar MySQL sleur gaat via mysql_real_escape_string, dat is dus niet alle input die via $_POST/$_GET/$_COOKIE etc binnen komt.

zaterdag 15 oktober 2005 16:11

Acties:

0 Henk 'm!

ShadowLord

Daos schreef op zaterdag 15 oktober 2005 @ 14:51:
Het is in SQL toch zo dat je elke ' moet vervangen door twee van die dingen?
code:
1
' --> ''

Niet voor alle SQL servers. MySQL heeft bijvoorbeeld backslashes nodig. MSSQL (en Sybase gebaseerde databases) hebben wel dat soort single quote escaping nodig.

You see things; and you say, "Why?" But I dream things that never were; and I say, "Why not?"

zaterdag 15 oktober 2005 16:11

Acties:

0 Henk 'm!

Y0ur1

curry684 schreef op zaterdag 15 oktober 2005 @ 14:52:
[...]

Nee, omdat het bagger opgezet is, een rukparser heeft, en bij iedere major release alle compatibiliteit breekt. Maar dat is offtopic hier

Kun je dit eens nader toelichten? Dit is wel erg kort door de bocht en zonder argumenten.

zaterdag 15 oktober 2005 16:48

Acties:

0 Henk 'm!

flowerp

Y0ur1 schreef op zaterdag 15 oktober 2005 @ 16:11:
[...]

Kun je dit eens nader toelichten? Dit is wel erg kort door de bocht en zonder argumenten.

@cury licht maar liever niet toe.

@ Y0ur1 zie 1 van de andere topics die hier over liep.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zaterdag 15 oktober 2005 17:11

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

ShadowLord schreef op zaterdag 15 oktober 2005 @ 16:11:
Niet voor alle SQL servers. MySQL heeft bijvoorbeeld backslashes nodig. MSSQL (en Sybase gebaseerde databases) hebben wel dat soort single quote escaping nodig.

Recente versies van MySQL kunnen ook prima met de '' werken hoor.

De SQL-specificatie stelt overigens dat een ' met '' geescaped moet worden, dus vandaar dat het gros van de databases het zo doet

flowerp schreef op zaterdag 15 oktober 2005 @ 16:48:
@cury licht maar liever niet toe.
@ Y0ur1 zie 1 van de andere topics die hier over liep.

Ach, Curry kan gewoon nog herinneren dat toen de parser van versie (toen het nog PHP/FI heette) 2 naar 3 ging, dat de nodige gevolgen had. En toen men van 3 naar 4 ging brak ook op sommige punten de backwards-compatibility. Straks van 4 naar 5 zijn o.a. een paar dingen die eigenlijk gewoon fout waren, maar wel gebruikt (misbruikt dus eigenlijk) werden verwijdert en ook dan zal de backwardscompatibility niet helemaal overeind blijven.

Dus dat zal ie wel bedoelen met "alle compatibiliteit breekt". Ik geloof dat .NET 1.0 apps ook niet in .NET 1.1 werkten oid? Dus het is iig niet iets dat alleen bij slecht opgezette omgevingen als PHP voorkomt

[ Voor 48% gewijzigd door ACM op 15-10-2005 17:15 ]

zaterdag 15 oktober 2005 17:41

Acties:

0 Henk 'm!

matthijsln

ACM schreef op zaterdag 15 oktober 2005 @ 14:26:
[...]

Ik geloof dat de term "parametrische queries" is, waar je dus aangeeft dat er iets op een bepaalde plek moet komen en je de database-driver ervoor laat zorgen dat het dan ook correct ingevuld wordt. Escaping komt dan voor de rekening van de database-driver en je hoeft je er zelf idd niet druk om te maken.
Wel is het verstandig dat je weet dat het gebeurt en hoe het gebeurt, je kan namelijk niet altijd parametrische queries gebruiken. Zeker niet zolang er geen ondersteuning is voor dynamische aantallen waarden in een IN()-clause en variabele filtering in de queries...

Met Hibernate is het bijvoorbeeld wel mogelijk om een lijst met parameters van variabele lengte aan een query parameter te binden, maar dat is indd niet overal mogelijk.

zaterdag 15 oktober 2005 17:45

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

matthijsln schreef op zaterdag 15 oktober 2005 @ 17:41:
Met Hibernate is het bijvoorbeeld wel mogelijk om een lijst met parameters van variabele lengte aan een query parameter te binden, maar dat is indd niet overal mogelijk.

Een tijd terug ben ik daar naar op zoek geweest in Hibernate3, is dat er al sinds lang dan?? Maar ook dan heb je nog geen ondersteuning voor conditionele parameters, waarbij je ofwel elke mogelijke versie zou moeten opstellen of gewoon maar on-the-fly een query voor moet genereren - desnoods in een aparte sql-dialect (hibernates query taal ofzo).

Maar idd, JDBC en daarmee het server-side deel van het preparen hebben er iig geen ondersteuning voor.

zaterdag 15 oktober 2005 17:47

Acties:

0 Henk 'm!

Grijze Vos

PHP Bashen is al bijna zo oud als MS bashen.

Overigens, foei foei ACM, dat onderschrift van jou...

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zaterdag 15 oktober 2005 19:18

Acties:

0 Henk 'm!

ACM

Software Architect

Werkt hier

Php

Grijze Vos schreef op zaterdag 15 oktober 2005 @ 17:47:
PHP Bashen is al bijna zo oud als MS bashen.

Ach, aangezien ze toch wel een beetje zich proberen te meten met Java en .NET op het gebied van webapplicaties, is het ook wel terecht om kritiek te uitten natuurlijk. Ongefundeerde of zwaar overdreven opmerkingen zijn inderdaad vooral bashen.
MySQL is net zo trouwens, want die proberen zich met Oracle te vergelijken, terwijl ze tot voor kort toch op "details" niet zo goed te vergelijken zijn.

Overigens, foei foei ACM, dat onderschrift van jou...

Euh, wat is daar mis mee?

zaterdag 15 oktober 2005 20:36

Acties:

0 Henk 'm!

Grijze Vos

ACM schreef op zaterdag 15 oktober 2005 @ 19:18:
Euh, wat is daar mis mee?

Je hebt recht op beide titels, maar je mag maar 1 tegelijkertijd voeren.

(Dat andere verhaal ben ik het mee eens, overigens.)

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info

zaterdag 15 oktober 2005 20:37

Acties:

0 Henk 'm!

curry684

left part of the evil twins

ACM schreef op zaterdag 15 oktober 2005 @ 17:11:
[...]

Dus dat zal ie wel bedoelen met "alle compatibiliteit breekt". Ik geloof dat .NET 1.0 apps ook niet in .NET 1.1 werkten oid? Dus het is iig niet iets dat alleen bij slecht opgezette omgevingen als PHP voorkomt

Afaik kun je een .NET 1.0 app blind met 1.1 inzetten, en is dat met 2.0 wederom het geval

Als er al incompatibilities zijn wordt dat in de interfaces opgelost, of zou je in het slechtste geval een compiler warning krijgen doordat een methode getagd is met het ObsoleteAttribute of DeprecatedAttribute.

En toelichten waarom PHP brak is... tja zoals gezegd is het offtopic en reageerde ik enkel op de opmerking dat PHP geen serieuze taal is. Ik gebruik het zelf ook regelmatig en het is een leuke taal voor de dingen waar het voor bedoeld is. Maar net als MySQL moet je de grenzen goed kennen als je er serieus voor grote projecten mee aan de slag wil.

Professionele website nodig?

Onderwerpen