[PHP/MySQL] SQL injectie voorkomen

[cariolive23]

Voutloos schreef op dinsdag 15 november 2011 @ 22:51:

offtopic:
Het topic gaat over mysql, en je wist best van het bestaan van de mysqli functies af, maar toch moet je per se naar de goede set Postgres functies linken. Zo kan ik ook zeggen dat mysqli beter is dan pg_query, makkelijk scoren...

SQL injection is net zo generiek als SQL en maakt geen onderscheid tussen databases

[Anoniem: 28958]

Dit topic kun je net zo goed hernoemen naar: [Huis in bos met gemiddelde temperaturen van 50 graden] Hoe bosbrand te voorkomen?

PHP is een belabberde programmeertaal, zeker voor zoiets als applicaties die aan Internet hangen; doe het gewoon niet. Als je niets beters weet te verzinnen dan PHP, stop dan maar gewoon met ontwikkelen. Als je klanten hebt die om PHP vragen, leg ze dan uit dat het een heel slecht idee is.

Waarom? In PHP hangt de veiligheid van je applicatie af op hoe goed mensen opletten (en dat is nu net waar mensen niet zo goed in zijn). Ze kunnen misschien een week geconcentreerd ergens mee bezig zijn, misschien wel 1 jaar, maar er komt een dag, dat er iemand even niet oplet, en je hebt een probleem (en je weet niet dat je een probleem hebt). De verdere ellende met PHP is dat het ontwikkeld is door een onervaren iemand. Denk aan de meest hippe persoon bij je op de universiteit die voor de lol even een taaltje heeft bedacht (die lopen overal wel rond) tijdens zijn bachelor. Gedaan? Ok, dat is dus de ontwikkelaar van PHP. Ga je daar je bedrijf op bouwen? Nee, dat doe je niet.

Mocht je meer van statistiek houden: hoeveel grote websites zijn van taal X naar PHP overgestapt? En hoeveel andersom? Juist.

Dus conclusie: als je een veilig systeem wilt hebben, moet je het niet al onveilig maken door prutszooi van een of andere hippe gozer te gebruiken.

[NMe]

Ik hoop dat ik niet uit hoef te leggen waarom het volgende suggereert dat PostgreSQL veel veiliger zou zijn dan MySQL?

cariolive23 schreef op dinsdag 15 november 2011 @ 20:57:
Gebruik gewoon een andere database en de betere functies, hoe je het simpel en veilig.

Als je nou geen voorgeschiedenis had van continu schoppen tegen MySQL zou ik veel minder fel hebben gereageerd, maar nu wek je gewoon de indruk bewust appels met peren te vergelijken. Sowieso heeft bind_param maar één call nodig voor de hele query, dus meer dan een prepare, bind_param en execute-combinatie heb je niet nodig, en als je het per se in één commando wil doen dan heb je een mysql_query_params zo geschreven natuurlijk.

Anoniem: 28958 schreef op dinsdag 15 november 2011 @ 23:12:
PHP is een belabberde programmeertaal, zeker voor zoiets als applicaties die aan Internet hangen; doe het gewoon niet. Als je niets beters weet te verzinnen dan PHP, stop dan maar gewoon met ontwikkelen. Als je klanten hebt die om PHP vragen, leg ze dan uit dat het een heel slecht idee is.

Waarom? In PHP hangt de veiligheid van je applicatie af op hoe goed mensen opletten (en dat is nu net waar mensen niet zo goed in zijn).

Ja, en dat gebeurt natuurlijk alleen in PHP en kan nóóit gebeuren in een C-variant, in Java of in welke andere willekeurige taal dan ook. Als jij PHP afraadt puur omdat het PHP is hoop ik niet dat iemand je ooit serieus neemt.

[Cartman!]

De meeste van die grote sites draaien nog steeds grote delen op PHP hoor, maak je nou maar geen illusies. Feit blijft dat het van de developer afhangt of je een veilige app krijgt of niet, of je nu in PHP, C++, Python of Java werkt.

[Gomez12]

Anoniem: 28958 schreef op dinsdag 15 november 2011 @ 23:12:
Waarom? In PHP hangt de veiligheid van je applicatie af op hoe goed mensen opletten (en dat is nu net waar mensen niet zo goed in zijn).

Noem eens 1 taal waarbij dit niet zo is?

PHP heeft een lage leercurve, heeft extreme bagger tuts op het inet staan, heeft een slechte documentatie (imho zelfs rampzalig te noemen als je de comments meepakt, wat soms weer nodig is omdat dan de comments beter zijn dan de docs ) maar in de basis is het niet beter/slechter dan een andere taal.

[Olaf van der Spek]

NMe schreef op dinsdag 15 november 2011 @ 22:34:
Daar hoef je geen andere database voor te gebruiken, vergelijkbare functies zijn er ook voor MySQL. Hou nou eens op met dat eeuwige ongefundeerde geschop tegen MySQL, we weten het nou wel. Ik begin je kruistocht écht beu te worden nu.

Hij heeft gewoon een goed punt. Wanneer hou jij nou eens op met stellen dat prepared statements zo simpel zijn?

Is het ook een feit dat dat altijd komt door slecht programmeren?

Nee, niet altijd.

Is het ook een feit dat het aantal toeneemt zoals je hier suggereert? Heb je ook cijfers die dat ondersteunen?

Geen idee. Nope. Doet het er nou echt toe of het stijgt? Het komt gewoon (veel) te vaak voor.

Je roept al de hele tijd dat dingen een feit zijn, maar veel van de dingen die je roept zijn gewoon aannames gebaseerd op een volgens jou toenemend aantal hacks getuige de media. Niet alle hacks die de laatste tijd in de media zijn gekomen zijn per se SQL-injectiefouten, en niet alle SQL-injectiehacks zullen meteen de schuld zijn van de programmeur. Bovendien is de enige "oplossing" die je aandraagt het min of meer verplichten van een bepaald soort functies of het beter voorlichten van mensen. Die voorlichting is niet voor rekening van de taal, dat zou absurd zijn. Opel en Volvo geven ook geen rijles.

Alsof auto's geen veiligheidssystemen hebben om de bestuurder te beschermen... Weer zo'n zwak voorbeeld.

Ja, en dat gebeurt natuurlijk alleen in PHP en kan nóóit gebeuren in een C-variant, in Java of in welke andere willekeurige taal dan ook. Als jij PHP afraadt puur omdat het PHP is hoop ik niet dat iemand je ooit serieus neemt.

In talen / platformen met betere APIs komt het inderdaad minder voor. In C# heb je niet zo snel een buffer overrun als in C bijvoorbeeld.

[ Voor 10% gewijzigd door Olaf van der Spek op 16-11-2011 01:11 ]

[Gomez12]

Olaf van der Spek schreef op woensdag 16 november 2011 @ 01:08:
[...]
Hij heeft gewoon een goed punt. Wanneer hou jij nou eens op met stellen dat prepared statements zo simpel zijn?

Wou jij dan zeggen dat ze moeilijk zijn?

[...]
Geen idee. Nope. Doet het er nou echt toe of het stijgt? Het komt gewoon (veel) te vaak voor.

En dat heeft imho zo goed als niets te maken met de taal, maar meer en meer met de kennis en het budget en het wensenpakket en deadlines etc. etc.

[...]
In talen / platformen met betere APIs komt het inderdaad minder voor. In C# heb je niet zo snel een buffer overrun als in C bijvoorbeeld.

Nope, dat ligt niet aan de taal dat ligt aan de opvoeding. In C# kan je net zulke bagger code maken als in C.
Enkel komt dat niet vaak meer voor in de tuts / boeken voor C# en de tuts/boeken voor C kunnen rustig 10 of 20 jaar oud zijn.
Kijk maar eens naar hedendaagse betrouwbare tuts voor PHP, daar tref je niet snel meer iets in als mysql_query bij de beginnerstuts. Enkel zwerft er nog iets van tig jaar historie over het internet en wordt dat nog steeds eindeloos gerehashed door zolderkamerprogrammeurs die denken hulpvaardig te zijn en een tut te schrijven.

C# is geen magic wand tegen buffer overruns, enkel er worden andere technieken aangeleerd waardoor het minder vaak voorkomt. Die technieken kan je echter net zo goed toepassen op C.

[ Voor 6% gewijzigd door Gomez12 op 16-11-2011 01:44 ]

[_js_]

Hoe denkt men hier over strcat en aanverwanten in C? Die zijn ook een grote bron van veiligheidsfouten, en daarom geven sommige compilers tegenwoordig een warning op het gebruik ervan. Het heeft ook een hele tijd geduurt voordat men overstapte op veiligere varianten daarvoor, omdat er toch teveel fouten mee werden gemaakt, zelfs door ervaren programmeurs die best wel weten wat een buffer overflow is.

[Anoniem: 28958]

Gomez12 schreef op woensdag 16 november 2011 @ 00:01:
[...]

Noem eens 1 taal waarbij dit niet zo is?

http://opalang.org/

[dik_voormekaar]

Gomez12 schreef op woensdag 16 november 2011 @ 01:42:
[...]
Kijk maar eens naar hedendaagse betrouwbare tuts voor PHP, daar tref je niet snel meer iets in als mysql_query bij de beginnerstuts.
[...]

Heb je daar een goed voorbeeld van? Meestal kom ik inderdaad verouderde tutorials tegen.

[Cartman!]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 08:26:
[...]

http://opalang.org/

Goed voorbeeld, ziet er heel volwassen uit ja Hoeveel major websites draaien daar op?

Opa's built-in security checks guarantee that the application will resist most attacks

Most attacks, dus 100% veilig is het niet... verdorie, moet ik als developer toch nog gaan opletten.

@Olaf, als ik kijk op http://nl3.php.net/mysql_query dan is dat voorbeeld gewoon voorzien van prima escaping en wordt er in de bijhorende comment verwezen naar mysql_real_escape_string. Ik snap werkelijk waar niet wat nu je doel is in deze discussie.

PHP:

$code = 'DEU';
$language = 'Bavarian';
$official = "F";
$percent = 11.2;

$stmt = $mysqli->prepare("INSERT INTO CountryLanguage VALUES (?, ?, ?, ?)");
$stmt->bind_param('sssd', $code, $language, $official, $percent);
$stmt->execute();

of

PHP:

$calories = 150;
$colour = 'red';
$sth = $dbh->prepare('SELECT name, colour, calories
    FROM fruit
    WHERE calories < :calories AND colour = :colour');
$sth->bindParam(':calories', $calories, PDO::PARAM_INT);
$sth->bindParam(':colour', $colour, PDO::PARAM_STR, 12);
$sth->execute();

Als je dat niet eens begrijpt of te moeilijk vind, waarom zou je dan beginnen met programmeren.

[ Voor 52% gewijzigd door Cartman! op 16-11-2011 09:07 ]

[cariolive23]

NMe schreef op dinsdag 15 november 2011 @ 23:17:
Sowieso heeft bind_param maar één call nodig voor de hele query, dus meer dan een prepare, bind_param en execute-combinatie heb je niet nodig, en als je het per se in één commando wil doen dan heb je een mysql_query_params zo geschreven natuurlijk.

Je vergeet te fetchen, ook daar is ineens een andere functie voor gekomen. Fetchen van een resultaat dat je met mysql_query hebt verkregen, werkt anders dan een resultaat van mysqli_execute.

Het gebruik van prepared statements in MySQL is wezenlijk anders dan met bv. PostgreSQL en dat wordt mede veroorzaakt door de drivers die MySQL heeft gemaakt. En dat levert dus beperkingen op voor bv. PHP die van deze driver gebruik moet maken om met de database te kunnen werken. Eén van de issues is het zeer beperkte aantal datatypes dat er bij het binden wordt gebruikt, integer/double/string/blob, daar wordt dus geen enkele vergelijking gemaakt met het datatype zoals het in de database wordt gebruikt. Datatypes zijn al een zwak punt van MySQL en al helemaal wanneer je niet de sql_mode ANSI gebruikt. Een wijziging van de sql_mode kom je zeer zelden tegen in een stuk code (PHP, Java, .NET, etc.), het wordt nauwelijks gebruikt.

MySQL heeft de zaken complexer gemaakt dan noodzakelijk, het gebruik van 4 functies i.p.v. 1, om met prepared statements te kunnen werken, wat pg_query_params doet, dat is voor 9 van de 10 beginnende programmeurs al teveel. En wanneer men eenmaal iets heeft geleerd, blijft men daar aan vasthouden. Gevolg: onnodig risico met SQL injection.

Uiteraard kun je zelf functies gaan schrijven om e.e.a. te gaan wrappen, maar dat zie ik een beginnende programmeur al helemaal niet doen.

Kruistocht? Ik lach hard om de vele onnodige problemen van de programmeurs die met MySQL moeten werken, beetje leedvermaak. Sorry, slechte eigenschap.

[Cartman!]

cariolive23 schreef op woensdag 16 november 2011 @ 09:06:
[...]
MySQL heeft de zaken complexer gemaakt dan noodzakelijk, het gebruik van 4 functies i.p.v. 1, om met prepared statements te kunnen werken, wat pg_query_params doet, dat is voor 9 van de 10 beginnende programmeurs al teveel. En wanneer men eenmaal iets heeft geleerd, blijft men daar aan vasthouden. Gevolg: onnodig risico met SQL injection.

Een beetje programmeur blijft gewoon doorleren, dat is ook z'n meerwaarde. Ik werk met MySQL en ben nog nooit tegen limiet aangelopen. En als Facebook en (om het even dicht bij huis te halen) Hyves het ook op grote schaal gebruiken zal het heus niet zo slecht zijn als jij ons wil doen geloven.

Kruistocht? Ik lach hard om de vele onnodige problemen van de programmeurs die met MySQL moeten werken, beetje leedvermaak. Sorry, slechte eigenschap.

Hou je niet van de domme, in praktisch elk topic waar MySQL voorbij komt wil je iedereen overtuigen dat ze er vanaf moeten. Ik lach daar niet om, ik vind het sneu. Gelukkig heb je zelf al door dat het een slechte eigenschap is.

[NMe]

Olaf van der Spek schreef op woensdag 16 november 2011 @ 01:08:
[...]

Hij heeft gewoon een goed punt. Wanneer hou jij nou eens op met stellen dat prepared statements zo simpel zijn?

Waarom vind jij ze simpeler in pg_query_params dan in mysqli_bind_param? Waarom vind (of noem) je ze überhaupt lastig? Ik ga niet ophouden met stellen dat prepared statements zo simpel zijn, domweg omdat ze zo simpel zijn.

Geen idee. Nope. Doet het er nou echt toe of het stijgt? Het komt gewoon (veel) te vaak voor.

Komt het genoeg voor om de mensen die wel weten wat ze doen te limiteren? Want je suggereert zelf al dat de bedrijven voorlichten om betere keuzes te maken wanneer het over het ontwikkelen van software gaat er als oplossing niet in zit. Dan blijft alleen de toolset aanpassen over als oplossing, en dat kun je niet doen zonder bestaande software te breken.

Alsof auto's geen veiligheidssystemen hebben om de bestuurder te beschermen... Weer zo'n zwak voorbeeld.

Nee, een zwakke vergelijking van jou. Auto's hebben inderdaad veiligheidssystemen, maar een programmeertaal heeft die net zo goed. PHP heeft mysql_real_escape_string, open_basedir, en zo nog talloze andere beveiligingssystemen. Het is vervolgens aan de gebruiker om ze te gebruiken, net zoals het aan de gebruiker is om zijn gordel om te doen en zijn remvloeistof te controleren als er een lampje gaat branden.

In talen / platformen met betere APIs komt het inderdaad minder voor. In C# heb je niet zo snel een buffer overrun als in C bijvoorbeeld.

C# heeft zijn eigen set met problemen, net zoals Java dat zal hebben. Geen enkele mainstream taal is substantieel veiliger dan een andere.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 08:26:
[...]

http://opalang.org/

Gelukkig noem je daar een belangrijke taal die wereldwijd door miljoenen programmeurs wordt omarmd als dé oplossing voor alle gebreken in andere programmeertalen. Nog naast het feit dat ik niet geloof dat in deze taal niet ook dergelijke fouten gemaakt kunnen worden. Een programma is net zo goed als de programmeur en diens oplettendheid. Als je aanneemt dat je toolset al je problemen oplost voor je dan faal je als ontwikkelaar.

cariolive23 schreef op woensdag 16 november 2011 @ 09:06:
[...]

Je vergeet te fetchen, ook daar is ineens een andere functie voor gekomen. Fetchen van een resultaat dat je met mysql_query hebt verkregen, werkt anders dan een resultaat van mysqli_execute.

[...]

Uiteraard kun je zelf functies gaan schrijven om e.e.a. te gaan wrappen, maar dat zie ik een beginnende programmeur al helemaal niet doen.

Dat is een keuze van PHP, niet van MySQL. Er is geen enkele reden waarom PHP dat niet op dezelfde manier zou kunnen implementeren als de Postgre-variant. Waarom ze gekozen hebben om dat niet te doen durf ik niet te zeggen, al vermoed ik dat dat met geheugenmanagement te maken heeft, wat dan waarschijnlijk met je datatypenverhaal samenhangt. Tóch vind ik niet dat de manier van werken met prepared statements nou zo lastig is dat een beginner er niet uitkomt.

Kruistocht? Ik lach hard om de vele onnodige problemen van de programmeurs die met MySQL moeten werken, beetje leedvermaak. Sorry, slechte eigenschap.

Fijn dat je dat in elk geval inziet.

[cariolive23]

NMe schreef op woensdag 16 november 2011 @ 13:43:
[...]

Dat is een keuze van PHP, niet van MySQL.

Is dat zo? Ik krijg heel sterk de indruk dat dit iets is wat in de driver wordt geregeld en niet in de programmeertaal (PHP in dit geval). Als ik het goed begrijp, roept de PHP-functie een functie in de driver aan en dat is het dan. Maar goed, ik ken niet de broncode van PHP of van de verschillende databasedrivers.

Er is geen enkele reden waarom PHP dat niet op dezelfde manier zou kunnen implementeren als de Postgre-variant. Waarom ze gekozen hebben om dat niet te doen durf ik niet te zeggen, al vermoed ik dat dat met geheugenmanagement te maken heeft, wat dan waarschijnlijk met je datatypenverhaal samenhangt.

Zou kunnen, maar het zou mij ook verbazen: Waarom werkt het in PHP met PostgreSQL wél eenvoudig en zou men dit niet eenvoudig willen maken voor MySQL?

Tóch vind ik niet dat de manier van werken met prepared statements nou zo lastig is dat een beginner er niet uitkomt.

Dat ben ik direct met je eens, alleen weten we allebei dat de gemiddelde beginner geen idee heeft wat een queryplan is en dus ook geen idee heeft dat er bij een prepared statement éérst het queryplan wordt opgesteld en dan later (en dat kan een fractie van een seconde zijn) de parameters nog worden doorgestuurd en dat deze parameters onmogelijk de query nog kunnen aanpassen: Het queryplan ligt al vast. Wanneer je dit niet kent/begrijpt, zul je niet snel extra code gaan kloppen. Met pg_query_params() hoef je helemaal niet te begrijpen hoe het werkt, alleen dát het werkt en dat je geen extra functies nodig hebt om het te gebruiken.

[Cartman!]

Je vergeet gewoon dat iemand daar nog steeds vanaf moet weten. Een leek zou gewoon kijken naar pg_query net zoals ie kijkt naar mysql_query. Zelfde idee dus, je argument houdt gewoon geen stand.

[NMe]

cariolive23 schreef op woensdag 16 november 2011 @ 14:23:
[...]

Is dat zo? Ik krijg heel sterk de indruk dat dit iets is wat in de driver wordt geregeld en niet in de programmeertaal (PHP in dit geval). Als ik het goed begrijp, roept de PHP-functie een functie in de driver aan en dat is het dan. Maar goed, ik ken niet de broncode van PHP of van de verschillende databasedrivers.

Ik geloof meteen dat de driver die MySQL aanlevert deze functionaliteit ook in een vergelijkbare vorm aanbiedt. Maar dat betekent natuurlijk niet dat PHP dat dan één op één door moet geven via dezelfde API. Ze hadden ervoor kunnen kiezen om een functie te maken die onderwater al die calls afhandelt en vervolgens een interface biedt die lijkt op die van Postgre. Dat ze dat niet gedaan hebben lijkt me de "schuld" van PHP en niet van MySQL, in zoverre er überhaupt een schuldvraag is voor een designkeuze.

Zou kunnen, maar het zou mij ook verbazen: Waarom werkt het in PHP met PostgreSQL wél eenvoudig en zou men dit niet eenvoudig willen maken voor MySQL?

Ik vermoed dat dat hiermee te maken heeft:

quote: http://www.php.net/manual/en/mysqli-stmt.execute.php#57562

If you select LOBs use the following order of execution or you risk mysqli allocating more memory that actually used

1)prepare()
2)execute()
3)store_result()
4)bind_result()

If you skip 3) or exchange 3) and 4) then mysqli will allocate memory for the maximal length of the column which is 255 for tinyblob, 64k for blob(still ok), 16MByte for MEDIUMBLOB - quite a lot and 4G for LONGBLOB (good if you have so much memory). Queries which use this order a bit slower when there is a LOB but this is the price of not having memory exhaustion in seconds.

Dat ben ik direct met je eens, alleen weten we allebei dat de gemiddelde beginner geen idee heeft wat een queryplan is en dus ook geen idee heeft dat er bij een prepared statement éérst het queryplan wordt opgesteld en dan later (en dat kan een fractie van een seconde zijn) de parameters nog worden doorgestuurd en dat deze parameters onmogelijk de query nog kunnen aanpassen: Het queryplan ligt al vast. Wanneer je dit niet kent/begrijpt, zul je niet snel extra code gaan kloppen. Met pg_query_params() hoef je helemaal niet te begrijpen hoe het werkt, alleen dát het werkt en dat je geen extra functies nodig hebt om het te gebruiken.

Ik denk dat dat wel meevalt. De meeste mensen die prepared statements gebruiken, doen dat vanwege het bijkomende voordeel dat het SQL-injectie voorkomt. Ik durf te stellen dat de meest voorkomende antwoorden op de vraag "Waarom gebruik je prepared statements?" zouden zijn "Ik gebruik geen prepared statements" en "Om SQL-injectie tegen te gaan" als ik deze vraag in Programming zou stellen. Juist omdat mensen het doen om SQL-injectie te voorkomen zal het veel bekender zijn dan je denkt.

[cariolive23]

NMe schreef op woensdag 16 november 2011 @ 14:44:
Ik durf te stellen dat de meest voorkomende antwoorden op de vraag "Waarom gebruik je prepared statements?" zouden zijn "Ik gebruik geen prepared statements" en "Om SQL-injectie tegen te gaan" als ik deze vraag in Programming zou stellen. Juist omdat mensen het doen om SQL-injectie te voorkomen zal het veel bekender zijn dan je denkt.

Dat zou best kunnen, maar is wel een totaal ander beeld dan wat ik in mijn dagelijkse praktijk tegenkom. Wanneer ik bij een klant voor het eerst binnenkom en vraag of ze prepared statements gebruiken, kijken ze mij 9 van de 10 keer appelig aan omdat ze geen idee hebben waar ik het over heb. En dat kom ik tegen bij Java, .NET en PHP mensen, zit geen onderscheid in.

De Java en .NET mensen gebruiken vaak een ORM die wel prepared statements gebruikt, maar de uitzonderingen (zelf geschreven SQL) zijn regelmatig lek. PHP code die ik check, is nog vaker lek, al komt dit ook doordat ik regelmatig bij uit de hand gelopen successen over de vloer kom. Daar kom je de grootste uitdagingen tegen door het ontbreken van een structuur. (wat niet de schuld is van PHP, maar van de hobbyist die er ooit mee is begonnen). Ik heb de indruk dat men vaak "per ongeluk" prepared statements gebruikt, dankzij de tooling die men gebruikt.

[.oisyn]

Maar het is niet alsof prepared statements nou de heilige graal is. Op een gegeven moment moet je gewoon dynamisch een query bouwen. Denk aan een zoekfunctie waarbij velden optioneel zijn waardoor je dus wel of niet hoeft te filteren op een kolom, of nog ingewikkelder, wel of geen join hoeft te doen met een andere tabel. Daar gaat geen enkele prepared statement je bij helpen, en zul je dus alsnog een query op moeten gaan bouwen.

Wat ik eerder al zei, het enige wat daar echt bij helpt is een LINQ achtige API waarin je de hele query gewoon opbouwt door midden van functies.

[cariolive23]

.oisyn schreef op woensdag 16 november 2011 @ 15:30:
Maar het is niet alsof prepared statements nou de heilige graal is.

+1

Het lost zeg maar 80% van de problemen op, niet 100%

Op een gegeven moment moet je gewoon dynamisch een query bouwen. Denk aan een zoekfunctie waarbij velden optioneel zijn waardoor je dus wel of niet hoeft te filteren op een kolom, of nog ingewikkelder, wel of geen join hoeft te doen met een andere tabel. Daar gaat geen enkele prepared statement je bij helpen, en zul je dus alsnog een query op moeten gaan bouwen.

Een dynamische query sluit een prepared statement niet uit. Het gaat om het scheiden van de query en de userinput voor deze query. Placeholders en kolomnamen kun je dynamisch in een stuk SQL zetten, geen enkel probleem.

Hiermee kun je tot 99,9% van de queries met een prepared statement aanpakken. Dan hou je alleen nog de uitzonderingen over waarbij een prepared statement een totaal verkeerd queryplan opstelt door het ontbreken van de parameters. Wanneer je zover bent, mag ik hopen dat je snapt wat SQL injection is en hoe je dat moet voorkomen.

[Cartman!]

cariolive23 schreef op woensdag 16 november 2011 @ 15:21:
[...]

Dat zou best kunnen, maar is wel een totaal ander beeld dan wat ik in mijn dagelijkse praktijk tegenkom. Wanneer ik bij een klant voor het eerst binnenkom en vraag of ze prepared statements gebruiken, kijken ze mij 9 van de 10 keer appelig aan omdat ze geen idee hebben waar ik het over heb. En dat kom ik tegen bij Java, .NET en PHP mensen, zit geen onderscheid in.

Maar waarom denk je dat iemand die pg_* gebruikt ineens wel met prepared statements zou werken en niet als iemand mysql_* gebruikt? Iemand die van het bestaan af weet en niet lui is zal ze toch wel gebruiken of het nu een paar regels meer tikwerk is of niet.

De discussie is behoorlijk loos imo

[cariolive23]

Cartman! schreef op woensdag 16 november 2011 @ 16:04:
[...]

Maar waarom denk je dat iemand die pg_* gebruikt ineens wel met prepared statements zou werken en niet als iemand mysql_* gebruikt?

Omdat je met pg_query_params() niet eens hoeft te weten wat een prepared statement is en wat het doet, alles werkt hetzelfde.

KISS

[Cartman!]

Maar hoe gaat iemand die functie ooit vinden als pg_query() ook voldoet, dat bedoel ik.

[.oisyn]

cariolive23 schreef op woensdag 16 november 2011 @ 15:40:
Een dynamische query sluit een prepared statement niet uit.

Ik beweer ook niet anders, maar je kan er donder op zeggen dat het uiteindelijk wel fout gaat omdat mensen alsnog hun userdata direct in de query gaan stoppen, omdat het nou eenmaal irritant is om eerst de query op te bouwen en achteraf de variabelen eraan te binden op basis van index waarbij die index dus variabel is omdat je query dynamisch is.

[cariolive23]

Cartman! schreef op woensdag 16 november 2011 @ 16:51:
Maar hoe gaat iemand die functie ooit vinden als pg_query() ook voldoet, dat bedoel ik.

Hoe vind je pg_query? Via de PHP-handleiding? Dan staat pg_query_params hier boven (zie de lijst met functies aan de linkerzijde) en op de vorige pagina.

En uiteraard via topics zoals deze :-)

[NMe]

.oisyn schreef op woensdag 16 november 2011 @ 17:08:
[...]

Ik beweer ook niet anders, maar je kan er donder op zeggen dat het uiteindelijk wel fout gaat omdat mensen alsnog hun userdata direct in de query gaan stoppen, omdat het nou eenmaal irritant is om eerst de query op te bouwen en achteraf de variabelen eraan te binden op basis van index waarbij die index dus variabel is omdat je query dynamisch is.

Waarmee we dus terugkomen op het punt dat alles staat of valt met de discipline van de individuele programmeur.

cariolive23 schreef op woensdag 16 november 2011 @ 17:10:
[...]

Hoe vind je pg_query? Via de PHP-handleiding? Dan staat pg_query_params hier boven (zie de lijst met functies aan de linkerzijde) en op de vorige pagina.

En uiteraard via topics zoals deze :-)

Ik denk dat zijn punt is dat je op dezelfde manier ook bij de MySQL-variant uitkomt.

[cariolive23]

.oisyn schreef op woensdag 16 november 2011 @ 17:08:
[...]

Ik beweer ook niet anders, maar je kan er donder op zeggen dat het uiteindelijk wel fout gaat omdat mensen alsnog hun userdata direct in de query gaan stoppen,

Zolang er geen medicijn is tegen domheid, zul je dit houden. In het querylog van de database kun je dit soort fouten overigens nog wel achterhalen, het verschil tussen een prepared statement en een "normale" query is wel zichtbaar. Zeker tijdens de ontwikkel- en testfase zul je hierop moeten loggen, kun je dit snel de kop indrukken.

Hopelijk worden bedrijven/instellingen (en dus de programmeurs) nog eens financieel aansprakelijk gesteld voor dit soort blunders, dan wordt de motivatie om goed werk af te leveren misschien wat groter. Zo moeilijk is het niet.

[.oisyn]

Het is alleen jammer dat mijn suggestie waarmee je het wél volledig af kunt vangen keer op keer genegeerd wordt, en er op prepared statements gehamerd blijft worden.

[RobIII]

Ik snap echt heel de discussie niet. Met elke taal, met elk platform, met elk systeem kun je met voldoende onkunde jezelf in de voet schieten. Of dat nou PHP, C++, Java, Erlang, Brainfuck is of MySQL, SQL Server, PostGres, Mongo of Windows, Linux, MacOS of you_name_it. Who effin' cares. Los van de sporadische bug in taal/platform/whatever ligt het probleem altijd in de onkunde => "gebruiker". Basta.

[Cartman!]

NMe schreef op woensdag 16 november 2011 @ 17:12:
[...]
Ik denk dat zijn punt is dat je op dezelfde manier ook bij de MySQL-variant uitkomt.

Gelukkig dat iemand het begrijpt

[NMe]

.oisyn schreef op woensdag 16 november 2011 @ 17:23:
Het is alleen jammer dat mijn suggestie waarmee je het wél volledig af kunt vangen keer op keer genegeerd wordt, en er op prepared statements gehamerd blijft worden.

LINQ (en aanverwanten) bedoel je? Dat is op zich een leuke oplossing voor nieuwe projecten, maar bestaande projecten aanpassen om daar gebruik van te maken zal niet altijd even makkelijk zijn. Ik vind zelf LINQ niet echt handig uitzien, maar dat zeg ik als iemand die er nooit mee gewerkt heeft. Edit: ik heb het nog eens opgezocht en beter gekeken, dat ziet er wél verdomd handig uit. Ik zie er wel de voordelen van in. Maar uiteindelijk is ook LINQ weer een kwestie van waar de programmeur voor kiest. Een programmeur die niet bewust voor prepared statements kiest zal ook niet ineens voor LINQ gaan kiezen zonder de juiste incentive.

[ Voor 7% gewijzigd door NMe op 16-11-2011 17:47 ]

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 13:43:
Gelukkig noem je daar een belangrijke taal die wereldwijd door miljoenen programmeurs wordt omarmd als dé oplossing voor alle gebreken in andere programmeertalen.

Moet ik hier nu serieus een discussie mee gaan voeren? Het lijkt me zeer onwaarschijnlijk dat je ook maar het kleinste idee hebt van wat die techniek inhoudt. Die miljoenen programmeurs waar je het over hebt (en die je blijkbaar als autoriteit ziet), zullen allemaal dan wel het IQ van een aap hebben.

Als je nergens iets van weet, reageer dan gewoon niet.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 20:41:
[...]

quote: http://opalang.org/faq.xmlt

Is Opa invulnerable?
No, no language is, as ultimately application security is in the hands of the programmer.

Verder is OPA iets wat pas sinds halverwege dit jaar verschenen is; juist ja. Ik zeg niet dat 't geen serieuze kandidaat zou (kunnen) zijn voor het één-of-ander maar ik zou me toch zeker 2 keer bedenken als ik er zakelijk mee aan de slag moest. En heel OPA's "DB" staat nog in de kinderschoenen; ik mag hopen dat je dat niet serieus neemt als we dan toch zo aan de gang gaan.

[ Voor 45% gewijzigd door RobIII op 16-11-2011 21:01 ]

[Anoniem: 28958]

.oisyn schreef op woensdag 16 november 2011 @ 17:23:
Het is alleen jammer dat mijn suggestie waarmee je het wél volledig af kunt vangen keer op keer genegeerd wordt, en er op prepared statements gehamerd blijft worden.

Dit bestaat al jaren. Dat je er nog nooit van gehoord hebt, komt omdat het niet door 'miljoenen programmeurs' gebruikt wordt.

Ik denk overigens dat het volledig nutteloos is om met de gemiddelde persoon op GoT over dit soort onderwerpen te praten; ze snappen het niet en ze zullen het nooit begrijpen.

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 20:50:
Verder is OPA iets wat pas sinds halverwege dit jaar verschenen is; juist ja. Ik zeg niet dat 't geen serieuze kandidaat zou (kunnen) zijn voor het één-of-ander maar ik zou me toch zeker 2 keer bedenken als ik er zakelijk mee aan de slag moest.

Ik heb niet gezegd dat ik het meteen voor zakelijke doeleinden ga gebruiken. Het is ook niet 'invulnerable', want je kunt nl. altijd de geheimen van je organisatie in de broncode van je code zetten en die lekker op Internet zetten. Een buffer-overflow zal echter nooit gebeuren. Als je wilt dat bepaalde informatie die ergens in je datastructuren staat alleen voor bepaalde gebruikers toegankelijk moet zijn, dan kun je daar compile-time zekerheid over verkrijgen.

In PHP mag je blij zijn dat de velden die je uit je database leest ook daadwerkelijk aanwezig zijn.

Ik vind het redelijk irritant dat er alleen maar naar details van mijn opmerkingen gekeken wordt, waar het overduidelijk is dat Opa daadwerkelijk 'engineering' achter zich heeft en PHP dit in zijn geheel niet.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:04:
Ik heb niet gezegd dat ik het meteen voor zakelijke doeleinden ga gebruiken.

Nee, je zei namelijk helemaal niets. Je postte enkel een link.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:04:
Een buffer-overflow zal echter nooit gebeuren.

Jeej OPA!
Oh wacht. Er zijn nog ongeveer een half miljard andere talen waarin dat ook niet (of verdomd moeilijk) voorkomt. En dan nog even de 2418 andere soorten vulnerabilities zien af te dichten die je in veel gevallen niet eens kunt oplossen in een taal/specificatie/whatever om-dat men-sen fou-ten ma-ken en daar geen taal te-gen op-ge-was-sen is.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:04:
Ik vind het redelijk irritant dat er alleen maar naar details van mijn opmerkingen gekeken wordt

Welke details? Je postte een link.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:04:
het overduidelijk is dat Opa daadwerkelijk 'engineering' achter zich heeft en PHP dit in zijn geheel niet.

PHP is veel organischer gegroeid en ik zal de laatste zijn die PHP verdedigt (en dat ga ik dan ook niet doen) maar er zijn zat talen waar "engineering achter zit" en stuk-voor-stuk kun je er fouten in maken als je er onkundige mensen mee aan 't werk zet. En nee, dan bedoel ik met 'onkundig' niet iedereen die geen universitaire graad heeft.

[ Voor 25% gewijzigd door RobIII op 16-11-2011 21:15 ]

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 21:11:
Nee, je zei namelijk helemaal niets. Je postte enkel een link.

Nee, hoor je zei dat je het niet voor zakelijke doeleinden wilde inzetten, met daarmee dus als suggestie dat ik het tegenovergestelde zou hebben gezegd, maar zoals je correct opmerkt, heb ik dus niet zo veel gezegd.

Jeej OPA!
Oh wacht. Er zijn nog ongeveer een half miljard andere talen waarin dat ook niet (of verdomd moeilijk) voorkomt. En dan nog even de 2418 andere soorten vulnerabilities zien af te dichten die je in veel gevallen niet eens kunt oplossen in een taal/specificatie/whatever om-dat men-sen fou-ten ma-ken en daar geen taal te-gen op-ge-was-sen is.

Je hebt nu dus precies mijn voorbeeld over de database genegeerd. Ik kan me zo voorstellen dat er wel eens verwezen wordt naar een database veld dat niet bestaat waardoor op een willekeurig moment je website niet werkt, of je verwijst naar een veld dat niet bestaat. Ik bezoek elke week wel een website waar ik null pointer exceptions zie of dit soort fouten. Dus dat zijn geen ingebeelde problemen.

Stel je hebt een wisselend team van ontwikkelaars met allerlei complexe tabellen en je wilt als nieuwe ontwikkelaar een veld toevoegen. Hoe weet je dan waar in de codebase je dit moet doen zonder dit te testen of dit aan een andere ontwikkelaar te vragen (die dan ook maar een perfect geheugen moet hebben)? Hoe weet je wanneer je genoeg getest hebt en dus klaar bent? Dat weet je niet.

Ik ben trouwens van mening dat je wel degelijk elke gewenste eigenschap kunt encoderen. Dus als jij statisch wilt programmeren dat de duizendste bezoeker van je website een 'Welkom je bent de 1000ste bezoeker bericht krijgt' zonder dit te testen, dan kan dat. Niet in Opa, maar dat kan wel degelijk met andere systemen.

Aangezien elk 'veiligheidsprobleem' als een wiskundig probleem valt te modelleren, kun je dus ook een programma schrijven dat bewijst dat al die problemen niet voorkomen. De enige beperking die er is, is er een die je jezelf oplegt.

[RobIII]

Je hebt alleen geen f*ck aan je wiskundig bewijs als de implementatie flawed is en omdat mensen implementaties doen zijn deze vatbaar voor fouten. Maar goed, terwijl jij lekker met je wiskundige modellen aan 't spelen bent zijn "wij in the trenches" bezig met getting stuff done Het zou je niet misstaan om eens met wat minder minachting voor anderen te reageren en wat meer in lijn met realiteit te denken.

[ Voor 18% gewijzigd door RobIII op 16-11-2011 21:42 ]

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 20:55:
[...]

Ik denk overigens dat het volledig nutteloos is om met de gemiddelde persoon op GoT over dit soort onderwerpen te praten; ze snappen het niet en ze zullen het nooit begrijpen.

Praat nog een keer zo generaliserend en denigrerend over ons gebruikersbestand en ik schop je hoogstpersoonlijk van deze site af. Dit is nou al het zoveelste topic waarin je de sfeer verziekt met je autoritaire houding die nergens op gebaseerd is, en ik heb er meer dan genoeg van.

Op je "argumenten" ga ik niet eens in, want die slaan echt als een tang op een varken. Je werd gevraagd om een taal die geen gaten openlaat voor programmeurs om fouten te maken en je postte alleen deze link waarvan RobIII meteen al citeert dat zelfs de makers zeggen dat het niet allemaal waterdicht is. Deze taal laat óók gaten open en je hele voorbeeld staat dus op losse schroeven. Of ligt het aan mij en ben ik een gemiddelde persoon op GoT en begrijp ik het dus niet?

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 21:39:
Je hebt alleen geen f*ck aan je wiskundig bewijs als de implementatie flawed is en omdat mensen implementaties doen zijn deze vatbaar voor fouten. Maar goed, terwijl jij lekker met je wiskundige modellen aan 't spelen bent zijn "wij in the trenches" bezig met getting stuff done Het zou je niet misstaan om eens met wat minder minachting voor anderen te reageren en wat meer in lijn met realiteit te denken.

De implementatie is niet flawed, omdat deze maar 500 regels code is en hiermee al miljoenen regels code mee zijn gecontroleerd. Je kunt hoogstens een fout maken in de specificatie van een veiligheidseigenschap, maar ja, als je niet eens op kunt schrijven wat je wilt (dus niet hoe!), dan kun je maar beter stoppen.

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:04:
[...]
In PHP mag je blij zijn dat de velden die je uit je database leest ook daadwerkelijk aanwezig zijn.

PHP connect met een database server en is dus niet de eigenaar en/of beheerder van deze database server. Met een simpel ALTER TABLE statement kun je in de database een kolom weggooien, ondanks dat er ergens nog scripts of andere programma's bestaan die hier graag gebruik van willen maken.

Als ik het zo snel goed heb begrepen, kan OPA niet eens een verbinding opzetten met een database server (DB2, Firebird, MySQL, Oracle, PostgreSQL, whatever), het heeft alleen een eigen interne database. Dat kun je onmogelijk met elkaar vergelijken.

[Anoniem: 28958]

cariolive23 schreef op woensdag 16 november 2011 @ 21:46:
PHP connect met een database server en is dus niet de eigenaar en/of beheerder van deze database server. Met een simpel ALTER TABLE statement kun je in de database een kolom weggooien, ondanks dat er ergens nog scripts of andere programma's bestaan die hier graag gebruik van willen maken.

Als ik het zo snel goed heb begrepen, kan OPA niet eens een verbinding opzetten met een database server (DB2, Firebird, MySQL, Oracle, PostgreSQL, whatever), het heeft alleen een eigen interne database. Dat kun je onmogelijk met elkaar vergelijken.

Dat is een technisch detail. Als ze willen implementeren ze SQL support in een maand of zo.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:48:
[...]

Dat is een technisch detail. Als ze willen implementeren ze SQL support in een maand of zo.

Feit is dat ze dat niet gedaan hebben. Deze hele thread gaat over SQL-injectie en als grote oplossing voor dat probleem noem je een taal zonder ANSI SQL-support of zelfs maar support voor een andere databasevendor dan hun eigen proprietary product. Hoe is dat precies relevant in deze thread, in welke vorm dan ook?

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:48:
Dat is een technisch detail.

Ja nu gaan we 't opeens afdoen als detail... Zoals ik al zei:

RobIII schreef op woensdag 16 november 2011 @ 20:50:
En heel OPA's "DB" staat nog in de kinderschoenen; ik mag hopen dat je dat niet serieus neemt als we dan toch zo aan de gang gaan.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:48:
Als ze willen implementeren ze SQL support in een maand of zo.

Ja joh... Zien = geloven. Lees dat linkje dan nog maar eens goed want zelf zeggen ze er bar weinig over en zijn ze er behoorlijk vaag over.

Daarbij: zolang dat niet gebeurd is ben ik toch wel erg benieuwd hoe ze dat willen gaan oplossen met, om je eigen voorbeeld aan te halen, velden die bijv. spontaan verdwenen zijn. Of leuker; velden die opeens een ander type zijn. Veel meer dan een exception gooien (goh, waar gebeurt dat ook al weer nog meer? Oh ja! In zowat élke taal) kunnen ze dan niet doen.

[ Voor 15% gewijzigd door RobIII op 16-11-2011 21:55 ]

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 21:42:
Praat nog een keer zo generaliserend en denigrerend over ons gebruikersbestand en ik schop je hoogstpersoonlijk van deze site af. Dit is nou al het zoveelste topic waarin je de sfeer verziekt met je autoritaire houding die nergens op gebaseerd is, en ik heb er meer dan genoeg van.

Volgens mij is het meer dat je het zelf niet aankan, dat ik je impliciet het IQ van hoogstens een aap heb toegekend.

Op je "argumenten" ga ik niet eens in, want die slaan echt als een tang op een varken. Je werd gevraagd om een taal die geen gaten openlaat voor programmeurs om fouten te maken en je postte alleen deze link waarvan RobIII meteen al citeert dat zelfs de makers zeggen dat het niet allemaal waterdicht is. Deze taal laat óók gaten open en je hele voorbeeld staat dus op losse schroeven. Of ligt het aan mij en ben ik een gemiddelde persoon op GoT en begrijp ik het dus niet?

Goed, een taal die geen gaten (op 500 regels code die je met de hand moet controleren na) openlaat: Coq.

Opa is een praktische taal. In Opa bewijs je op een hele goedkope manier dat je niet een field access hebt op een veld dat niet bestaat (zoals in PHP, Ruby, etc.). Je kunt ook aan typed meta programming doen, maar ook dat ontgaat jullie geloof ik nog steeds.

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 21:52:
Daarbij: zolang dat niet gebeurd is ben ik toch wel erg benieuwd hoe ze dat willen gaan oplossen met, om je eigen voorbeeld aan te halen, velden die bijv. spontaan verdwenen zijn. Of leuker; velden die opeens een ander type zijn. Veel meer dan een exception gooien (goh, waar gebeurt dat ook al weer nog meer? Oh ja! In zowat élke taal) kunnen ze dan niet doen.

Nee, dit gebeurt compile time. Je hebt er helemaal niets van begrepen.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:57:
[...]

Nee, dit gebeurt compile time. Je hebt er helemaal niets van begrepen.

Ik begrijp 't donders goed. Alleen, als je applicatie ondertussen compiled en wel vrolijk draait en ik duik MySQL in met m'n phpMyAdmin en flikker een veld weg dan ga je nét zo goed met je applicatie op je gaffel. En hoe is dat anders dan, ik noem maar wat, LINQ of EF, wat ook compiletime aan typesafety e.d. doet?

[ Voor 11% gewijzigd door RobIII op 16-11-2011 22:00 ]

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 21:58:
[...]

Ik begrijp 't donders goed. Alleen, als je applicatie ondertussen compiled en wel vrolijk draait en ik duik MySQL in met m'n phpMyAdmin en flikker een veld weg dan ga je nét zo goed met je applicatie op je gaffel. En hoe is dat anders dan, ik noem maar wat, LINQ of EF?

Ja, als je er een baksteen tegen aangooit, doet hij het ook niet meer. Gek he?

Daarom compile je natuurlijk je management tools op hetzelfde moment als je applicatie, waardoor phpMyAdmin achtige toestanden achterwege blijven.

[Cartman!]

Maar 100% waterdicht krijgen ze het ook niet tot nu toe (zoals ik heb geciteerd) dus wie garandeert mij dat hun implementatie van SQL dat wel gaat zijn?

Feit is dus dat het voorbeeld wat je aanhaalde niet klopt, het voldoet namelijk niet aan de eis die gesteld is: een 100% veilige taal. Ik vraag me alleen sterk af wat jij op GoT doet als je ons behandelt als een stel beginners.

edit: eerst posten, dan tv kijken... ik loop achter

[ Voor 6% gewijzigd door Cartman! op 16-11-2011 22:02 ]

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:48:
[...]


[...]

Dat is een technisch detail. Als ze willen implementeren ze SQL support in een maand of zo.

Vandaag nog niet zo'n goede grap gehoord, kan er smakelijk om lachen.

Maar, hoe wil je nu (nadruk op nu) SQL injection voorkomen op een SQL database? Want daar gaat het topic over. Dat in de toekomst alles beter zal worden, dat weten we wel maar hebben we nu alleen niets aan.

En helaas, mijn OPA ligt al op het kerkhof

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:56:
Goed, een taal die geen gaten (op 500 regels code die je met de hand moet controleren na) openlaat: Coq.

http://coq.inria.fr/

Ja, dat is een mooi voorbeeld van een breed ondersteund platform Je beseft toch wel dat 't idee is dat er uiteindelijk ook een product opgeleverd moet worden voor de klant hé? En als 't effe kan gisteren.

[Cartman!]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:57:
Je hebt er helemaal niets van begrepen.

De enige die de discussie niet begrijpt ben je zelf volgens mij. We gaan al behoorlijk offtopic momenteel maar als je Rob z'n voorbeeld van een veld wegmikken die dan de app stuk maakt afdoet met "dat moet je ook niet doen" dan geldt dat weer net zo goed voor elke taal.

[Anoniem: 28958]

cariolive23 schreef op woensdag 16 november 2011 @ 22:02:
[...]

Vandaag nog niet zo'n goede grap gehoord, kan er smakelijk om lachen.

Maar, hoe wil je nu (nadruk op nu) SQL injection voorkomen op een SQL database? Want daar gaat het topic over. Dat in de toekomst alles beter zal worden, dat weten we wel maar hebben we nu alleen niets aan.

En helaas, mijn OPA ligt al op het kerkhof

Het punt is dat als je een beetje een fatsoenlijke ontwikkelaar bent, dat je dan dus zelf een SQL backend kunt bouwen voor Opa. Waarom kan dit in Opa en niet in PHP? Dat komt, omdat het row variables (uit de type theorie) heeft. Dat ik dit allemaal al moet voorkauwen geeft aan dat niemand er serieus naar heeft gekeken.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:07:
[...]

Het punt is dat als je een beetje een fatsoenlijke ontwikkelaar bent, dat je dan dus zelf een SQL backend kunt bouwen voor Opa.

En zoals ik al zei, maar waar je steeds maar niet op in gaat: het staat nog in de kinderschoenen, is niets meer dan een key-value store, schaalt niet, interopereert totaal niet met andere systemen en ga zo maar door. Wat heb je er dan in de praktijk aan? Precies: he-le-maal niets.

quote: http://blog.opalang.org/2...nd-where-its-heading.html

On our drawing boards we did extensively talk about support for sets: storing records that can be efficiently queried by a subset of its fields without the need to manually maintain indexes, as is the case now (in relational DB terms: think of multiple indexes on your tables). We also extensively talked about links, which is a way for expressing, well, links to structures stored at other parts of the DB (again, in relational terms, that would correspond to foreign indexes).

Ze lullen wel leuk en zijn dan wel lekker bezig op hun drawing board maar de praktijk is dus dat er nog helemaal niets van dit alles is.

[ Voor 43% gewijzigd door RobIII op 16-11-2011 22:12 ]

[Cartman!]

Als het allemaal zo makkelijk is, waarom heb jij nog geen SQL backend uitgebracht ervoor? Dan heb je toch meteen je punt gemaakt?

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:07:
[...]

Het punt is dat als je een beetje een fatsoenlijke ontwikkelaar bent, dat je dan dus zelf een SQL backend kunt bouwen voor Opa. Waarom kan dit in Opa en niet in PHP? Dat komt, omdat het row variables (uit de type theorie) heeft. Dat ik dit allemaal al moet voorkauwen geeft aan dat niemand er serieus naar heeft gekeken.

Maar hoe gaat OPA dan voorkomen dat iemand met een ALTER TABLE statement een kolom gaat weggooien of van datatype veranderen wanneer jouw applicatie (en een tiental andere applicaties) nog gebruiken? Dat kan, en mag, OPA niet voorkomen. Databases veranderen, net zoals de rest van de wereld. Dat moet gecontroleerd gebeuren, dat klopt, maar het gaat zeker gebeuren. En dus is het ook zeker dat een OPA applicatie hier keurig mee op zijn bek gaat. Niks bijzonders, kun je nu al voorspellen. En dus kun je daar een foutafhandeling voor bouwen.

Maar voorlopig spreekt OPA nog geen SQL, laat ze daar eerst maar voor zorgen.

[Anoniem: 28958]

Cartman! schreef op woensdag 16 november 2011 @ 22:07:
[...]

De enige die de discussie niet begrijpt ben je zelf volgens mij. We gaan al behoorlijk offtopic momenteel maar als je Rob z'n voorbeeld van een veld wegmikken die dan de app stuk maakt afdoet met "dat moet je ook niet doen" dan geldt dat weer net zo goed voor elke taal.

Ik zie niet waarom een ontwikkelaar in staat zou moeten zijn om een database veld te verwijderen. In een goed bedrijfsproces kan dat ook helemaal niet. Je hebt hooguit releases waarbij er velden bij kunnen komen of kunnen worden verwijderd en functies die tussen twee database versies transformeren (allemaal met de juiste types). Dus, het is helemaal niet nodig om dat soort toegang te hebben.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:12:
[...]

Ik zie niet waarom een ontwikkelaar in staat zou moeten zijn om een database veld te verwijderen. In een goed bedrijfsproces kan dat ook helemaal niet. Je hebt hooguit releases waarbij er velden bij kunnen komen of kunnen worden verwijderd en functies die tussen twee database versies transformeren (allemaal met de juiste types). Dus, het is helemaal niet nodig om dat soort toegang te hebben.

En trek die parallel nu eens door naar je eerdere opmerking over PHP en MySQL (of weet ik het)? Daar geldt toch exact hetzelfde voor?

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 22:13:
[...]

En trek die parallel nu eens door naar je eerdere opmerking over PHP en MySQL (of weet ik het)? Daar geldt toch exact hetzelfde voor?

Nee, want er zitten geen types in die transformaties.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:07:
[...]

Het punt is dat als je een beetje een fatsoenlijke ontwikkelaar bent, dat je dan dus zelf een SQL backend kunt bouwen voor Opa. Waarom kan dit in Opa en niet in PHP? Dat komt, omdat het row variables (uit de type theorie) heeft. Dat ik dit allemaal al moet voorkauwen geeft aan dat niemand er serieus naar heeft gekeken.

Ik hoef geen uren te spenderen om naar die taal te kijken om te weten dat hij niet het waterdichte wonder is dat jij ons wil laten geloven. Ik verwijs nogmaals naar de post waar jij op reageerde met enkel een link naar OPA...

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:56:
[...]

Volgens mij is het meer dat je het zelf niet aankan, dat ik je impliciet het IQ van hoogstens een aap heb toegekend.

Al doe je het expliciet (dat doe je hier ook) en in mijn gezicht. Ik kan er niet tegen dat jij structureel iedereen behalve jezelf uitmaakt voor een idioot die "het niet begrijpt." Maar goed, genoeg offtopic geblaat, ik heb gezegd wat ik moest zeggen. Doe ermee wat je wil.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:12:
[...]

Ik zie niet waarom een ontwikkelaar in staat zou moeten zijn om een database veld te verwijderen. In een goed bedrijfsproces kan dat ook helemaal niet. Je hebt hooguit releases waarbij er velden bij kunnen komen of kunnen worden verwijderd en functies die tussen twee database versies transformeren (allemaal met de juiste types). Dus, het is helemaal niet nodig om dat soort toegang te hebben.

Alsof een ontwikkelaar de enige is die door het verwijderen van een veld de software stuk kan maken? Een DBA kan dat net zo goed. Iets dat at compile time perfect werkt hoeft dus later niet meer te werken omdat er aan de DB geklooid is, en daarmee is het net zo gestoeld op mensenlijke fouten als elke andere programmeertaal. En dát was nou net het hele punt waarmee we deze discussie inschoten.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:14:
[...]

Nee, want er zitten geen types in die transformaties.

Hebben ze ook niet nodig want PHP is loose typed. Zolang het veld blijft bestaan gaat je software niet kapot. Sterker nog, dat is robuuster dan jouw OPA, want dat gaat stuk als je het type van je databaseveld verandert.

[ Voor 8% gewijzigd door NMe op 16-11-2011 22:16 ]

[Anoniem: 28958]

Cartman! schreef op woensdag 16 november 2011 @ 22:10:
Als het allemaal zo makkelijk is, waarom heb jij nog geen SQL backend uitgebracht ervoor? Dan heb je toch meteen je punt gemaakt?

Ik heb wel wat beters te doen.

En als je dan vraagt waarom ik op zo'n forum zit? Ik moet toch proberen wat van mijn kennis op wat van die arme ontwikkelaars over te brengen. Misschien leren jullie er nog een keer iets van.

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:16:
[...]

Ik heb wel wat beters te doen.

En als je dan vraagt waarom ik op zo'n forum zit? Ik moet toch proberen wat van mijn kennis op wat van die arme ontwikkelaars over te brengen. Misschien leren jullie er nog een keer iets van.

Hoe het niet moet?

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 22:14:
Alsof een ontwikkelaar de enige is die door het verwijderen van een veld de software stuk kan maken? Een DBA kan dat net zo goed. Iets dat at compile time perfect werkt hoeft dus later niet meer te werken omdat er aan de DB geklooid is, en daarmee is het net zo gestoeld op mensenlijke fouten als elke andere programmeertaal. En dát was nou net het hele punt waarmee we deze discussie inschoten.

Geef de DBA alleen toegang tot operaties die de applicatie niet kunnen slopen. Mocht je van mening zijn dat je geen DBA meer nodig hebt dan kun je ook je DBA ontslaan. Lijkt me wel handig.

Hebben ze ook niet nodig want PHP is loose typed. Zolang het veld blijft bestaan gaat je software niet kapot. Sterker nog, dat is robuuster dan jouw OPA, want dat gaat stuk als je het type van je databaseveld verandert.

Het probleem is dat de transitie van database versie X naar database versie Y zo is dat de nieuwe applicatie versie Y verwacht. Dat kun je niet doen in PHP.

[Cartman!]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:16:
[...]
En als je dan vraagt waarom ik op zo'n forum zit? Ik moet toch proberen wat van mijn kennis op wat van die arme ontwikkelaars over te brengen. Misschien leren jullie er nog een keer iets van.

Met nog geen 1000 posts in 10 jaar heb je behoorlijk wat toegevoegd aan GoT, chapeau Als je echt zo goed bent als je zelf beweert bouw je die 100% veilige taal toch zelf wel even? Dan kunnen we hier echt iets leren.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:20:
[...]

Geef de DBA alleen toegang tot operaties die de applicatie niet kunnen slopen. Mocht je van mening zijn dat je geen DBA meer nodig hebt dan kun je ook je DBA ontslaan. Lijkt me wel handig.

Dus je hebt een programmeur die geen rechten heeft om de database aan te passen, en geen DBA die dat voor de programmeur kan doen. Wie mag dat dan wel nog? Het maakt niet uit wie het doet, maar iemand moet die rechten hebben, en die ene persoon kan de zaak verknallen.

Het probleem is dat de transitie van database versie X naar database versie Y zo is dat de nieuwe applicatie versie Y verwacht. Dat kun je niet doen in PHP.

Wou je wedden? Als ik in PHP een veld aanspreek dat er niet meer is, dan krijg ik een dikke error. Jij krijgt die error in OPA terwijl je compileert, ik pas terwijl ik run. Maar dat is gewoon de aard van het beestje. Als er geen compile time is dan kun je dan ook geen fouten opgooien. Maakt de taal nog niet inferieur.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:16:
[...]

En als je dan vraagt waarom ik op zo'n forum zit? Ik moet toch proberen wat van mijn kennis op wat van die arme ontwikkelaars over te brengen. Misschien leren jullie er nog een keer iets van.

Gelukkig blijf je er bescheiden onder.

[ Voor 14% gewijzigd door NMe op 16-11-2011 22:27 ]

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:20:
Het probleem is...

Nee, het probleem is je totale gebrek aan realiteitszin en daar ga ik het in ieder geval bij laten.

NMe schreef op woensdag 16 november 2011 @ 22:26:
Jij krijgt die error in OPA terwijl je compileert

Ook alleen als je OPA's (poor excuse for a) "DB" gebruikt. Omdat de "DB" mee-compiled in het project Zo kan ik 't ook. Als je OPA aan een bestaand RDBMS zou koppelen (eender welk) heb je exact hetzelfde probleem. En daar gaat compile-time of niet geen zak aan helpen. Compile je project, draai 't vrolijk en wijzig dan een veld van type: *boem*. Maar nee, dat gebeurt natuurlijk nooit want niemand kan een veldtype veranderen
Ik denk dat 't hoofdstuk "The database" boekdelen spreekt. Of euh... nou, toch wel zeker 3 A4-tjes

[ Voor 93% gewijzigd door RobIII op 17-11-2011 02:54 ]

[Anoniem: 28958]

Cartman! schreef op woensdag 16 november 2011 @ 22:21:
[...]

Met nog geen 1000 posts in 10 jaar heb je behoorlijk wat toegevoegd aan GoT, chapeau Als je echt zo goed bent als je zelf beweert bouw je die 100% veilige taal toch zelf wel even? Dan kunnen we hier echt iets leren.

Er bestaan al meerdere van dit soort 100% veilige talen waarvan Coq het verste is ontwikkeld.

Er is voor zover ik weet geen 'Rails voor Coq', maar dat wil niet zeggen dat het niet mogelijk is om dit te doen.

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 22:26:
Dus je hebt een programmeur die geen rechten heeft om de database aan te passen, en geen DBA die dat voor de programmeur kan doen. Wie mag dat dan wel nog? Het maakt niet uit wie het doet, maar iemand moet die rechten hebben, en die ene persoon kan de zaak verknallen.

Dat heb ik al uitgelegd.

Wou je wedden? Als ik in PHP een veld aanspreek dat er niet meer is, dan krijg ik een dikke error. Jij krijgt die error in OPA terwijl je compileert, ik pas terwijl ik run. Maar dat is gewoon de aard van het beestje. Als er geen compile time is dan kun je dan ook geen fouten opgooien. Maakt de taal nog niet inferieur.

Het hele punt is dat je bij wijze van spreken tijdens compile time (dus voor deployment) weet dat er een SQL injectie mogelijk is. Met PHP heb je op je live website een SQL injectie. Ik snap niet dat je het verschil niet ziet.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:31:
[...]

Er bestaan al meerdere van dit soort 100% veilige talen waarvan Coq het verste is ontwikkeld.

Coq is dan ook geen traditionele programmeertaal maar een taal die voor één bepaald doel is ontwikkeld. Ook hier zit weer geen verbinding naar databaseservers in (voor zover ik kan zien) en al die andere "kleine" features die een andere omgeving zijn kwetsbaarheden geven. Als ik PHP als taal bekijk in plaats van als framework dan is het óók ineens 100% veilig, en meteen ook 100% onbruikbaar voor het doel waar het nu voor gebruikt wordt...

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:34:
[...]

Dat heb ik al uitgelegd.

Nee hoor. Iemand moet de database kunnen aanpassen. Je zegt zelf dat de programmeur dat niet mag zijn, en een DBA is volgens jou ook obsolete. Er moet iemand zijn om de "database" aan te passen na voortschrijdend inzicht, en die ene persoon kan de zaak verknallen. Als je dat niet inziet heb je echt een van de meest fundamentele principes van software development niet begrepen.

Het hele punt is dat je bij wijze van spreken tijdens compile time (dus voor deployment) weet dat er een SQL injectie mogelijk is. Met PHP heb je op je live website een SQL injectie. Ik snap niet dat je het verschil niet ziet.

Er is geen verschil. Jij krijgt een warning/error van je compiler, ik van mijn IDE. Het enige verschil is dat ik mijn warning kan negeren als ik daarvoor kies en jij niet.

[ Voor 41% gewijzigd door NMe op 16-11-2011 22:38 ]

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:20:
[...]

Geef de DBA alleen toegang tot operaties die de applicatie niet kunnen slopen. Mocht je van mening zijn dat je geen DBA meer nodig hebt dan kun je ook je DBA ontslaan. Lijkt me wel handig.

Iemand heeft de rol van DBA nodig en dus is er altijd iemand die iets kan doen waardoor jouw applicatie niet meer werkt. Daarnaast is er nog altijd minimaal 1 backup van deze persoon, heb je in jouw wereld al twee problemen te pakken die je zeker niet kunt oplossen door ze te ontslaan.

Een DBA kan altijd iets slopen, hij/zij is juist diegene die deze risico's moet verkleinen. En jij wil deze persoon ontslaan? Geen idee in welke wereld jij leeft, maar dit gaat nergens meer over. Ik heb hier 500 applicaties staan die met één database kletsen, daar gaat met enige regelmaat iets fout. Voornamelijk in de testomgeving, maar het gaat wel fout. En dat kan de fout van de applicatie zijn, maar ook van de database. Fouten worden nu eenmaal gemaakt, je hebt er maar mee te leven en dus te accepteren dat op een dag jouw applicatie onderuit gaat.

[.oisyn]

NMe schreef op woensdag 16 november 2011 @ 17:33:
Maar uiteindelijk is ook LINQ weer een kwestie van waar de programmeur voor kiest. Een programmeur die niet bewust voor prepared statements kiest zal ook niet ineens voor LINQ gaan kiezen zonder de juiste incentive.

Hij zal wel moeten als een dergelijke API de enige is waarmee ie kan interfacen met z'n database.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 20:55:
[...]

Dit bestaat al jaren.

Klopt, what's your friggin point? Ik breng het ook niet als iets nieuws ofzo. Ik zeg hoe een API kan werken die je simpelweg verbiedt foute queries te maken.

Dat je er nog nooit van gehoord hebt

Doe niet van die domme aannames en reageer on topic.

Ik denk overigens dat het volledig nutteloos is om met de gemiddelde persoon op GoT over dit soort onderwerpen te praten; ze snappen het niet en ze zullen het nooit begrijpen.

En ze doen domme aannames

[ Voor 6% gewijzigd door .oisyn op 16-11-2011 22:37 ]

[RobIII]

quote: http://doc.opalang.org/index.html#_the_database

Opa uses it at launch-time to verify that the database stored to the disk is compatible with the application. If the database schema has changed, Opa will offer the choice between proceeding to an automated database migration or leaving the application.

Wat nou "compile-time"?

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 22:27:
[...]

Nee, het probleem is je totale gebrek aan realiteitszin en daar ga ik het in ieder geval bij laten.

[...]

Ook alleen als je OPA's (poor excuse for a) "DB" gebruikt. Omdat de "DB" mee-compiled in het project Zo kan ik 't ook. Als je OPA aan een bestaand RDBMS zou koppelen (eender welk) heb je exact hetzelfde probleem. En daar gaat compile-time of niet geen zak aan helpen. Compile je project, draai 't vrolijk en wijzig dan een veld van type: *boem*. Maar nee, dat gebeurt natuurlijk ooit want niemand kan een veldtype veranderen
Ik denk dat 't hoofdstuk "The database" boekdelen spreekt. Of euh... nou, toch wel zeker 3 A4-tjes


[...]

Wat nou "compile-time"?

Een methode is om een compiler te schrijven van een live database naar Opa record types waardoor ook dat probleem is verholpen waarin je dan in Opa gebruik maakt van een of andere abstractielaag.

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 22:36:
[...]

Wat nou "compile-time"?

Technisch gezien is dat compile time.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:37:
[...]

Technisch gezien is dat compile time.

* NMe proest. Dat is bijna sig-waardig. Launch time en compile time zijn twee substantieel verschillende dingen. De enige reden dat je daar in dit geval geen verschil in ziet is omdat de database meegecompileerd wordt en dus in de goede vorm aanwezig is. Bouw MySQL-support (of een ander DBMS) in en je loopt ineens tegen exact dezelfde problemen aan die PHP heeft.

.oisyn schreef op woensdag 16 november 2011 @ 22:36:
[...]

Hij zal wel moeten als een dergelijke API de enige is waarmee ie kan interfacen met z'n database.

Klopt, maar een dergelijke stap moet door de hele industrie in één keer gezet worden om écht effectief te zijn. Zie ik niet op korte termijn gebeuren, maar als ik LINQ zo zie dan heeft dat wel de toekomst.

[ Voor 28% gewijzigd door NMe op 16-11-2011 22:44 ]

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 22:34:
Coq is dan ook geen traditionele programmeertaal maar een taal die voor één bepaald doel is ontwikkeld. Ook hier zit weer geen verbinding naar databaseservers in (voor zover ik kan zien) en al die andere "kleine" features die een andere omgeving zijn kwetsbaarheden geven. Als ik PHP als taal bekijk in plaats van als framework dan is het óók ineens 100% veilig, en meteen ook 100% onbruikbaar voor het doel waar het nu voor gebruikt wordt...

Coq kun je voor elke berekening gebruiken, dus inclusief het praten met een database. Dat je daarvoor wat axioma's moet introduceren als je niet zelf een database implementeert betekent niet dat het niet kan.

Nee hoor. Iemand moet de database kunnen aanpassen. Je zegt zelf dat de programmeur dat niet mag zijn, en een DBA is volgens jou ook obsolete. Er moet iemand zijn om de "database" aan te passen na voortschrijdend inzicht, en die ene persoon kan de zaak verknallen. Als je dat niet inziet heb je echt een van de meest fundamentele principes van software development niet begrepen.

Ja, een proces die checkt dat de types tussen de vorige versie en de nieuwe versie kloppen en dat iemand akkoord heeft gegeven voor de nieuwe applicatie (in het geval van Opa) of als er aan de nieuwe specificatie is voldaan(in het geval van Coq). Dus, geen 'release-manager' meer nodig of wat dan ook.

Er is geen verschil. Jij krijgt een warning/error van je compiler, ik van mijn IDE. Het enige verschil is dat ik mijn warning kan negeren als ik daarvoor kies en jij niet.

Dit punt is al uitgelegd.

[Cartman!]

Dus PHP is ook ineens een compiled taal omdat ie elke keer tijdens een request gaat compilen, ik leer zoveel vanavond.

offtopic:
HPHP (hiphop) is overigens wel compiled PHP...

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:44:
[...]

Coq kun je voor elke berekening gebruiken, dus inclusief het praten met een database. Dat je daarvoor wat axioma's moet introduceren als je niet zelf een database implementeert betekent niet dat het niet kan.

Ik zeg niet dat het niet kan. Ik zeg dat het dezelfde beveiligingsproblemen met zich meebrengt die elke andere taal heeft.

Ja, een proces die checkt dat de types tussen de vorige versie en de nieuwe versie kloppen en dat iemand akkoord heeft gegeven voor de nieuwe applicatie (in het geval van Opa) of als er aan de nieuwe specificatie is voldaan(in het geval van Coq). Dus, geen 'release-manager' meer nodig of wat dan ook.

Er moet iemand zijn die akkoord heeft gegeven. Zwakke schakel right there.

Dit punt is al uitgelegd.

Dat is de tweede of derde keer dat ik je dat zie zeggen in de afgelopen paar posts, maar die uitleg mis ik toch echt.

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:36:
[...]

Een methode is om een compiler te schrijven van een live database naar Opa record types waardoor ook dat probleem is verholpen waarin je dan in Opa gebruik maakt van een of andere abstractielaag.

In een paar posts heb je al aangedragen om :

• Wiskundige modellen te maken om te bewijzen dat je applicatie 100% veilig is
• Specificaties te verwachten eisen die foutloos zijn
• Alle hoop te vestigen op iets dat er nog niet eens is
• Zelf managementtools te schrijven
• DBA's maar buiten te mikkeren; overbodige ballast
• Een compiler te schrijven
• Een taal te gebruiken die al helemaal niet interfaced met bestaande zaken (wat je met "wat axioma's" wel effe implementeert natuurlijk, daar draai je je hand toch niet voor om?!?)

In welke wereld leef jij? Welke klanten betalen hiervoor? Ik ken er namelijk geen één.
En dan heb ik 't nog niet eens gehad over dat je bij de meeste van bovenstaande punten alleen maar méér risico's introduceert op fouten dan wanneer je bouwt op bestaande, reeds "proven", technieken/platformen/talen. Los van 't feit dat je waarschijnlijk het tien- tot honderdvoudige tijdsbestek nodig hebt om een werkend product af te leveren.

[ Voor 8% gewijzigd door RobIII op 16-11-2011 22:50 ]

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 22:46:
Ik zeg niet dat het niet kan. Ik zeg dat het dezelfde beveiligingsproblemen met zich meebrengt die elke andere taal heeft.

Dat heb je dan alleen wel mis.

Er moet iemand zijn die akkoord heeft gegeven. Zwakke schakel right there.

Het akkoord is voor wat de applicatie moet doen. Niet of er een inconsistentie tussen de DB en de applicatie is (waar SQL injecties o.a. om draaien).

[Voutloos]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:44:
Coq kun je voor elke berekening gebruiken, dus inclusief het praten met een database. Dat je daarvoor wat axioma's moet introduceren als je niet zelf een database implementeert betekent niet dat het niet kan.

"Wat axioma's"
Alles wat een huidig rdbms (mysql, postgres, oracle, mssql whatever) kan 100% theoretisch beschrijven en valideren is al meer werk dan wat jij in je lifetime kan bereiken. En dan wil ik nog best ruimdenkend doen en er vanuit gaan dat de medische vooruitgang er voor zorgt dat jij minstens de 200 jaar bereikt.

[Anoniem: 28958]

RobIII schreef op woensdag 16 november 2011 @ 22:50:
In welke wereld leef jij? Welke klanten betalen hiervoor? Ik ken er namelijk geen één.

In een betere wereld dan jij blijkbaar

[RobIII]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:51:
In een betere wereld dan jij blijkbaar

Nee hoor; ik kom daar iedere nacht ook Alleen word ik 's ochtends wakker en jij klaarblijkelijk niet

[ Voor 13% gewijzigd door RobIII op 16-11-2011 22:52 ]

[Anoniem: 28958]

Voutloos schreef op woensdag 16 november 2011 @ 22:51:
[...]
"Wat axioma's"
Alles wat een huidig rdbms (mysql, postgres, oracle, mssql whatever) kan 100% theoretisch beschrijven en valideren is al meer werk dan wat jij in je lifetime kan bereiken. En dan wil ik nog best ruimdenkend doen en er vanuit gaan dat de medische vooruitgang er voor zorgt dat jij minstens de 200 jaar bereikt.

Ik weet niet hoelang de implementatie precies duurt. Het ging erom dat het wel mogelijk was. Ik denk overigens ook wel dat het in de categorie 'pokke veel werk' valt.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:50:
[...]

Dat heb je dan alleen wel mis.

Gelukkig onderbouw je dat zo goed.

Het akkoord is voor wat de applicatie moet doen. Niet of er een inconsistentie tussen de DB en de applicatie is (waar SQL injecties o.a. om draaien).

Dan is er nog steeds iemand die die wijziging in het systeem moet zetten.

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:51:
[...]

In een betere wereld dan jij blijkbaar

Laat me raden: je doet academisch werk of werkt voor de overheid, waar niet het eindresultaat telt maar het feit dat er aan een project gewerkt wordt? Wij worden in de echte wereld allemaal door onze klanten uitgekauwd als we niet onze deadlines halen of als we twee keer duurder zijn dan onze PHP-gebruikende concurrent.

[Voutloos]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:52:
[...]

Ik weet niet hoelang de implementatie precies duurt. Het ging erom dat het wel mogelijk was. Ik denk overigens ook wel dat het in de categorie 'pokke veel werk' valt.

Goed, dat is al een hele nuance. Het kost dus 'pokke veel werk' en in die tijd:
1 Moet de klant jou betalen
2 Moet de klant wachten op het product
3 Gaat de rest van de wereld ook vooruit, ik noemde expres 'huidig rdbms'.
4 Ben je enkel bezig met de problemen in de sql injection hoek, en nog niet de andere tig security issues
5 Ben je vooral niet bezig met de applicatie zelf.

[Anoniem: 28958]

NMe schreef op woensdag 16 november 2011 @ 22:53:
Dan is er nog steeds iemand die die wijziging in het systeem moet zetten.

Ik had al eerder gezegd dat je dit ook door een computer programma kunt laten doen. Ik noemde het toen een proces.

waar niet het eindresultaat telt maar het feit dat er aan een project gewerkt wordt?

Het eindresultaat, zoals de reeks van hacks bij weet ik niet hoeveel websites en organisaties? Prachtig eindresultaat.

[cariolive23]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:52:
[...]

Ik weet niet hoelang de implementatie precies duurt. Het ging erom dat het wel mogelijk was. Ik denk overigens ook wel dat het in de categorie 'pokke veel werk' valt.

Bijzonder, nu is het ineens pokke veel werk? Een paar minuten geleden was het nog een maandje werk:

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:48:
[...]


[...]

Als ze willen implementeren ze SQL support in een maand of zo.

Kortom, luchtfietserij. OPA voorkomt geen SQL injection, het spreekt geen SQL en op korte termijn komt dat er ook niet. Dat is niet erg, maar ga niet roepen dat wij domme apen zijn en dat OPA even alle wereldproblemen oplost.

[NMe]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:57:
[...]

Ik had al eerder gezegd dat je dit ook door een computer programma kunt laten doen. Ik noemde het toen een proces.

Dus dat computerprogramma verzint even voor mij dat er een extra veld in de database moet komen omdat ik graag tóch ook de meisjesnaam van een gebruiker wil opslaan? Vind ik bijzonder knap, ik wist niet dat software tegenwoordig al gedachten kon lezen.

Het eindresultaat, zoals de reeks van hacks bij weet ik niet hoeveel websites en organisaties? Prachtig eindresultaat.

Intussen wordt er wel geld mee verdiend, en dat gaat je met jouw voorgestelde werkwijzen niet lukken.

[RobIII]

cariolive23 schreef op woensdag 16 november 2011 @ 22:58:
en dat OPA even alle wereldproblemen oplost.

Nee, dat zie je verkeerd:

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 22:52:
Het ging erom dat het wel mogelijk was

Het is mogelijk met OPA/CoQ. Dat 't niet zo is schuiven we gewoon even onder de mat en hebben we 't niet over. Dat dat argument voor elke andere taal/platform/whatever geldt is al helemáál irrelevant. Dat je er dan pokke veel werk in moet steken negeren we dan maar; klanten schokken toch wel voor alle uren die we bezig zijn met onze tenen te spelen.

/sarcasm

[ Voor 4% gewijzigd door RobIII op 16-11-2011 23:05 ]

[Anoniem: 26306]

cariolive23 schreef op woensdag 16 november 2011 @ 22:58:

Kortom, luchtfietserij. OPA voorkomt geen SQL injection, het spreekt geen SQL en op korte termijn komt dat er ook niet.

Zonder SQL support ook geen SQL injection toch?

Dat is niet erg, maar ga niet roepen dat wij domme apen zijn...

Nou, ik denk dat veel mensen hier van mening zijn dat het merendeel van de vakgenoten beter pinda's hadden kunnen gaan doppen.
Maar het is natuurlijk iets anders als je dat gaat roepen tegen de vakgenoten die het spelletje wel aardig doorhebben.
Volgens mij zijn we hier trouwens gewoon een troll aan het voeren

[YopY]

* YopY springt op de bandwagon

quote: gang-ster

Ik had al eerder gezegd dat je dit ook door een computer programma kunt laten doen. Ik noemde het toen een proces.

En computerprogramma's worden gemaakt door wie ook maar weer? Juist, mensen, en mensen maken een programma. Een typo in een programma is even snel gemaakt als een typo in een SQL query.

@hele discussie, een bakkes tools en talen op een probleem gooien lost het probleem niet op, het verstopt het alleen als je niet al te diep kijkt.

@topic, de beste manier om SQL injection te voorkomen is om geen SQL of RDBMSen te gebruiken. Als je toch al een PHP-maar-dan-zonder-sql-injectie gebruikt, pak dan liever een bewezen NoSQL technologie als Mongo of Couch of rakel er nog maar eens een bakkes op.

Of: "The only way to win is not to play"

[.oisyn]

Bedankt voor die Wargames quote

[GateKeaper]

offtopic:
Nooit geweten dat er ook 's avonds nog zoveel leven op GoT is.

[curry684]

Anoniem: 28958 schreef op woensdag 16 november 2011 @ 21:56:
[...]

Volgens mij is het meer dat je het zelf niet aankan, dat ik je impliciet het IQ van hoogstens een aap heb toegekend.

Als z'n werkgever moet ik hierbij dan wel aantekenen dat ie een verdomd goeie code monkey is die in verkoopbare tijd mooie werkende projecten kan afleveren. En hij in tegenstelling tot iemand die het verschil tussen runtime, launchtime en compiletime niet weet dus wel door de sollicitatieprocedure is gekomen.

[Anoniem: 296939]

RobIII schreef op woensdag 16 november 2011 @ 17:25:
Ik snap echt heel de discussie niet. Met elke taal, met elk platform, met elk systeem kun je met voldoende onkunde jezelf in de voet schieten. Of dat nou PHP, C++, Java, Erlang, Brainfuck is of MySQL, SQL Server, PostGres, Mongo of Windows, Linux, MacOS of you_name_it. Who effin' cares. Los van de sporadische bug in taal/platform/whatever ligt het probleem altijd in de onkunde => "gebruiker". Basta.

Amen.

[Anoniem: 27535]

Heren, heren...

We kunnen er een heel gevecht van maken, maar uiteindelijk heeft eenieder zijn rol in organisatie, het creëren van software of de maatschappij, en zo ook gang-ster.

Voor bepaalde zaken moet je met mensen om kunnen gaan, voor andere moet je all-rounder zijn, tig andere rollen, en soms heb je iemand nodig die zich kan begraven in iets waar anderen dan weer de voor- en nadelen uit kunnen halen - mensen die dat stukje afstand kunnen nemen.

Ja, er zijn er die het nodig hebben digitaal te denken, en dus alles te invalideren wat niet in het denkpatroon past. Zie ook hier: Autisme heeft ook voordelen

Dat wil niet zeggen dat dat geen waardevolle bijdrage kan leveren, en ik denk dat we dat ook zo moeten zien. Niet een discussie heeft zin, maar wel eventueel aangedragen informatie om af te wegen. Gang-ster krijgt een aai over de bol, krijgt in zijn taal te horen dat hij een nieuwe wereld geschapen heeft, en de rest van de wereld gaat door met het leven waarbij misschien sommige elementen of opmerkingen iets bijgedragen hebben. Iedereen blij.

*DE* waarheid bestaat niet, en het heeft zeker geen zin om iemand zijn waarheid af te nemen. Bewaar discussie voor waar het zin heeft

[Anoniem: 28958]

curry684 schreef op woensdag 16 november 2011 @ 23:36:
[...]

Als z'n werkgever moet ik hierbij dan wel aantekenen dat ie een verdomd goeie code monkey is die in verkoopbare tijd mooie werkende projecten kan afleveren. En hij in tegenstelling tot iemand die het verschil tussen runtime, launchtime en compiletime niet weet dus wel door de sollicitatieprocedure is gekomen.

Ik weet dat verschil wel hoor. Mensen halen hier alleen alles door elkaar.

Dus bijv. de maand tijd die ik heb genoemd was voor Opa, niet voor Coq (waar de pokke hoeveelheid werk op sloeg).

Als je ontwikkelaar bent in Opa op een of andere server, kun je natuurlijk Opa zo aanpassen dat een of ander 'compilescript' de normale compilatie procedure doet en het eerste gedeelte van de de launch uitvoert en je noemt dat dan 'compile time'. Compile time betekent iets algemeners dan dat jij in je hoofd hebt.

Ik zou je ook aanraden om niet op threads te reageren over zaken waar je toch geen kaas van hebt gegeten.

[Anoniem: 28958]

Anoniem: 27535 schreef op donderdag 17 november 2011 @ 02:01:
Autisme heeft ook voordelen

Ga je nu ook al voor dokter spelen en diagnoses stellen?

Ik hoef geen aai over mijn bol te hebben overigens; de beloning van de echte markt, en niet een of ander forum zegt voor mij genoeg.

[Woy]

Zo is het wel weer leuk geweest.