Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 83 reacties

De veelgebruikte databasemodule dbi van Perl laat ruimte voor sql-injecties, door de onvoorspelbare manier waarop Perl met lists omgaat. Dat zorgde er onder meer voor dat het cms Movable Type kwetsbaar was voor sql-injecties.

Perl, Perl, PerlHet beveiligingsprobleem wordt volgens beveiligingsonderzoeker Netanel Rubin van Check Point veroorzaakt door de niet altijd even intuïtieve manier waarop Perl omgaat met lists in combinatie met gebruikersinvoer. Rubin deed zijn bevindingen uit de doeken op de CCC-beveiligingsconferentie in Hamburg.

Als een gebruiker handmatig meerdere parameters ingeeft maakt Perl er een list van. Wanneer de invoer van de gebruiker al wordt verwerkt in een list, worden de extra parameters toegevoegd aan de list, wat onverwachte situaties en zelfs beveiligingsproblemen kan opleveren.

In het geval van de veelgebruikte database-module dbi van Perl betekent dit dat quote, een functie die kan worden aangeroepen om sql-injecties te voorkomen door gebruikersinvoer te strippen van aanhalingstekens, niet meer goed werkt als een gebruiker meerdere parameters toevoegt aan een request. Aanhalingstekens worden dan soms namelijk niet meer gestript, waardoor een gebruiker eigen code in sql-commando's kan verstoppen.

Onder meer het veelgebruikte cms Movable Type, dat door veel grote websites wordt gebruikt, was daardoor kwetsbaar voor sql-injecties. Imiddels is dat specifieke beveiligingsprobleem opgelost, maar nog veel sites met Perl zijn kwetsbaar. "Zoek maar eens op Github naar Perl-scripts met 'quote'", aldus Rubin. Sites die op Perl en dbi leunen kunnen beter de prepare-functie gebruiken om sql-injectie te voorkomen.

Eerder bleek al dat de tegenintuïtieve manier waarop Perl met lists omgaat ervoor zorgde dat gebruikers zichzelf toegang konden verschaffen tot Bugzilla, de bugtracker-tool die onder meer door het Linux-kernelproject en Mozilla zelf wordt gebruikt. Dat beveiligingsprobleem is inmiddels opgelost. In de opensource-wiki-software Twiki konden aanvallers door hetzelfde probleem eigen code injecteren.

De werking van de lists-functie is weliswaar vastgelegd in de documentatie, maar is niet intuïtief, aldus Rubin. "Het is de schuld van de programmeur", erkent Rubin. 'Iedereen' doet het echter verkeerd, tekent hij aan. Rubin riep aanwezige programmeurs op de hackersconferentie, die tot dinsdag duurt, op om te stoppen met het gebruik van Perl. Volgens de beveiligingsonderzoeker is Perl onveilig en sterk verouderd.

Update, 11:36: Volgens Perl-ontwikkelaar Juerd Waalboer ligt het probleem niet aan Perl of dbi, maar aan de cgi-module van Perl, een manier om Perl aan een webserver te knopen. "De fout is dat de CGI-module een interface heeft die op een bijzonder onhandige manier gebruik maakt van die fundamentele feature in Perl", aldus Waalboer. Dat levert in de praktijk een flink aantal kwetsbaarheden op, waaronder in dbi.

Moderatie-faq Wijzig weergave

Reacties (83)

Dus de bug hier gaat over het feit dat in Perl een @array uitpakt en niet een verwijzing naar die array maakt? Sorry, maar dat is zó bekend bij Perl-developers dat dit niet echt een vulnerability is...

my @array= ('a', 'b');
push @array, ('c', 'd');
# array is nu a,b,c,d

my @array= ('a', 'b');
push @array, ['c', 'd'];
# array is nu a,b,[c,d]

Dit is gewoon hoe Perl werkt, er is inderdaad een verschil tussen arrayrefs (dus de square brackets) en arrays (normale haakjes). Niks overwachts aan en als dit voor bugs zorgt moeten ze maar teruggaan naar PHP.

De "bug" in DBI is dat een tweede argument aan 'quote' ervoor kan zorgen dat de manier van quoten wordt aangepast.

Bijbehorende afbeelding uit de betreffende 31c3 talk die aangeeft dat de onderzoeker de taal gewoon niet snapt: https://pbs.twimg.com/media/B6Di9CBCQAEMLQT.png

[Reactie gewijzigd door TvdW op 29 december 2014 23:15]

Het gegeven voorbeeld is precies volgens de specificaties van Perl. Geef je parameters niet door 'by reference' dan maakt Perl er een 'platte' lijst van. RTFM zou ik zeggen!
Tja, treffende nick zal ik maar zeggen...

Op het moment dat de specificatie zo onduidelijk is dat grote projecten dit fout doen heb ik eerder zoiets van : Fix the F*cking language and then change the specs.
De specificatie is niet onduidelijk. De werking van Perl is al zo zolang ik Perl gebruik (versie: 4.036, jaar: 1995). Ik blijf erbij: wil je een programmeertaal gebruiken dan zal je je moeten verdiepen in de documentatie of een goed boek moeten lezen. Zeker als je een 'groot' project met een bepaalde programmeertaal wilt doen.

Perl is behoorlijk goed gedocumenteerd (mag ook wel zie: perlhist). Al heel lang bestaat er op menig platform: 'man perlsub' of perldoc tegenwoordig.

On topic: perlsub 2e alinea:

The Perl model for function call and return values is simple: all functions are passed as parameters one single flat list of scalars, and all functions likewise return to their caller one single flat list of scalars.

Je moet het alleen weten te vinden ;-)
Natuurlijk, documentatie is belangrijk. Maar een logische, consistente API die resulteert in leesbare code is m.i. belangrijker. Developers zijn net gebruikers: die lezen niet, of alleen als ze het echt, echt niet kunnen vermijden. De ontwerper van een taal of API hoort daar m.i. rekening mee te houden: het moet uit de code zelf duidelijk zijn wat die code doet. Als je daar uitgebreide documentatie bij nodig hebt, dan is je ontwerp m.i. niet goed. Net zoals je geen uitgebreide documentatie nodig wil hebben om in de basis je smartphone en de apps daarop te gebruiken. En het gebruik van een lijst lijkt me toch wel een basiselement waarvan je mag verwachten dat het intuïtief werkt.
Maar een logische, consistente API die resulteert in leesbare code is m.i. belangrijker.
tja, daar heb je dus een HEEL groot probleem, want wat IS logisch en consistent? wat voor jou logisch kan zijn, kan voor een ander compleet onlogisch zijn. Ikzelf vind een hoop zooi van het .NET framework dus absolute verre van logisch, maar anderen vinden dat wel logisch..
'Logisch' is in the eye of the beholder, en vaak is 'logisch' ook een kwestie van hoeveel men van de materie afweet..
Ik hoop dat de mensen niet te veel gaan afknappen op je nick want je hebt volkomen gelijk.
Ik leer graag wat bij Nha. Daarvoor heb ik ooit bewust voor perlboy en niet voor perlman, perlguru, etc. etc. gekozen. Kijkend naar de Perl 'core' members zal ik altijd grotere goden boven me hebben.
Tsja, het leven van minder grote goden gaat nu eenmaal niet over rozen...
Want grote projecten betekenen meteen dat iedereen daar alles weet en het dan nog eens op de juiste manier doet? Een groot project heeft ook een grote kans op faalsituaties zoals bijvoorbeeld deze. En wat dacht je dan van mensen die liever blijven bij wat ze kennen en dus bijvoorbeeld oude, onveilige, inefficiënte methodes blijven gebruiken.

De taal heeft er blijkbaar al een oplossing voor, en de oude methode moet je min of meer behouden voor backwards compatibility. Dus wat wou je nou gefixed zien? Dat iedereen die meteen update met gebroken scripts zit, of dat die scripters eens leren van de juiste of betere methodes te gebruiken?

Aangezien de fix er al is, neem ik aan dat jij liever gebroken scripts ziet? Deprecated functies blijven geregeld wel nog een aantal versies in de taal zodat scripters/programmeurs ook de tijd hebben om zich er aan aan te passen. Helaas ligt het probleem zo goed als altijd bij de programmeurs die zich ofwel niet inlichten ofwel weigeren aan te passen. In beide gevallen is dat een goed teken van een "slechte" programmeur... Ze mogen dan nog snelle of werkende code afleveren, als ze bij ouderwetse en slechte methodes zijn heb je er evengoed problemen mee.

Specificaties/documentatie is bij een stuk andere talen toch al heel wat minder of moeilijker te vinden.
Helemaal mee eens :)
Kan zijn. De security researcher heeft een punt, immers de bugs zijn widespread. Het gaat hier om gedrag van ontwikkelaars. Hoe verklaar je anders een fout in de login van BugZilla voor 7 jaar.

De spreker snapt het goed. Perl is broken omdat het niet goed omgaat met fout gedrag van ontwikkelaars.

Blame the developer. Not the guys that breaks the news.
De spreker snapt het dus niet. Perl is niet 'broken', de ontwikkelaar deugt niet.

zoals je zelf zelgtL
Blame the developer. Not the language...
Perl is geen taal die je aan je handje vasthoudt...
Helaas zijn er in Perl een aantal dingen inderdaad niet erg intuitief, en er zijn ook dingen die alleen maar werken omdat iedereen net doet alsof. (OO, multidimensionale arrays)

Zonder een goede zelfdiscipline wordt je code dan al gauw een zooitje.

Gelukkig zijn er erg veel modules te vinden (CPAN), maar als de programmeur van zo'n module slordig is, dan merk je dat pas als iemand anders een exploit verzint aan de hand van die module. Want wie gaat alle CPAN modules die je gebruikt lopen checken?
Helaas zijn er in Perl een aantal dingen inderdaad niet erg intuitief
tja, je kunt het ook zo zien, wat voor de 1 intuitief is, kan voor de ander onhandig zijn.. Zoveel mensen zoveel wensen/meningen.. Een goed voorbeeld vind ik zelf bv het .NET framework, daar zitten genoeg dingen in waarvan ik nog steeds denk WTF were they thinking, of zelfs maar dat simpele dingen die je uit andere 'oudere' talen/frameworks gewend bent gewoonweg missen.

tja, en het gedeelte wat je zegt over die CPAN modules, geldt natuurlijk niet alleen voor bv Perl, maar voor ALLE!!! talen/frameworks..
Ach, weet je wat het is, veel huidige developers zijn gewoon zo lui als het maar zijn kan, en zouden zich geen raad weten als ze ineens zelf wat moeten doen. Nee, alles moet afgevangen worden door de 'taal'....
Probleem komt ook nog eens om de hoek kijken dat er veel HEEL VEEL verschillende inzichten zijn, wat de ene developer wel goed vindt, kan de ander bagger vinden. Ook denken sommige developers dat de manier waarop zij coderen DE standaard is en dat hun manier DE enige algemene manier van developpen is, want ja zo hebben zij dat geleerd.
Ik weet niet precies hoe DBI in elkaar steekt aangezien ik geen Perl developer ben, maar waarom zet je "bug" tussen aanhalingstekens? Ben je van mening dat het geen bug is? Hoort een database-module als DBI je niet te beschermen tegen SQL injectie?
De "bug" hier is dat DBI::quote twee argumenten neemt: 1 waarde om te quoten, en 1 hint om te helpen met quoten. Wat het in dit geval onhandig maakt is dat CGI::param een array terug geeft en een beginnende developer dat misschien niet door heeft. Daardoor kan je inderdaad SQL injecties krijgen.

Dit treft echter alleen ontwikkelaars die héél nieuw zijn met de taal - en inderdaad hier en daar software die geschreven is door die mensen. Het gaat dan ook specifiek om het geval "DBI::quote(CGI::param('user'))" waarbij de uitvoer van param() direct aan quote() wordt gegeven. Dit is niet een heel realistische situatie, aangezien code als deze sowieso waarschuwingen veroorzaakt in Perl als 'user' niet in de URL wordt gegeven. Simpele manieren om die waarschuwingen te voorkomen lossen ook direct deze 'bug' op.
Dit treft echter alleen ontwikkelaars die héél nieuw zijn met de taal - en inderdaad hier en daar software die geschreven is door die mensen.
Movable Type, Bugzilla..
Yep, perfecte voorbeelden van software die nooit door derden bekeken wordt met een developer instelling...

Ik denk dat je het dagelijkse gebruik van dit soort code zwaar onderschat...
Tja, waarom zou je een prepare gebruiken voor 1 enkele variabele?
Het is veel meer werk, en die ene variabele kan je met quote() ook ontdoen van gevaarlijke dingen...
De verkeerde mindset, maar niet ongebruikelijk, helaas.

Perl wordt veel gebruikt om 'even snel' wat te schrijven, wat vervolgens in productie wordt genomen, en zolang het werkt wordt er niet meer kritisch naar gekeken.
Niet per sé de verkeerde mindset. Prepared statements geven een overhead in het proces en leveren dus inefficiëntie op. Nu is dat natuurlijk niet heel significant en nooit een reden om het niet te gebruiken als je werkt met externe input voor die queries, maar in performance-kritieke toepassingen kan het hier en daar nuttig zijn om prepared statements te vermijden. Net als ORM-frameworks overigens; voor dagelijkse dingen is dat heel fijn maar bij zware toepassingen gaan ze hoe dan ook performance bottlenecks vormen waarbij je bepaalde zaken uiteindelijk beter zelf in SQL kunt uitwerken.
Niet noodzakelijk

Bij verschillende database systemen worden de sql statements (en bijhorende execution plans) gecached in memory.
Om dit te laten werken moeten de variablen in het statement wel variablen zijn en niet hard coded (via string concatination).
Als je dus een statement hebt als: select x,y,z from users where username = 'FDH' ga je met een prepared statement iets hebben als: select x,y,z from users where username = :01
en wordt het geparste statement in memory teruggevonden, ook bij andere values voor user.

Op die manier heb je niet enkel bescherming tegen sql injection (en veel beter dan met je quote() hebt), maar ga je ook performantere code hebben (statement moet niet meer geparsed worden aan db kant)
En ook dat is niet per sé waar. Als je wél een waarde geeft voor een parameter in een query kan het query plan daarop geoptimaliseerd worden. Door kennis over de gegevens in de tabel is het mogelijk om het query plan te optimaliseren. Aangezien bij een prepared statement het query plan daarbij vastgelegd is bieden prepared statements deze flexibiliteit niet.

Nu zal dit in de meeste gevallen geen performance winst opleveren maar in bepaalde gevallen kan dat wel aanzienlijk schelen.
Inderdaad.
Dat zal voornamelijk zijn wanneer een bepaalde waarde(n) veel meer voorkomen dan andere en bij data warehouse omgevingen zal je meestal ook de effectieve waarden gebruiken omdat de sql statements toch lang zullen duren (en niet herhaald worden).

Maar bij Oracle heb je dan bv ook bind variable peeking en adaptive cursurs om te helpen om (bij OLTP omgevingen) de skewed values op te vangen.
Een vulnerabiltiy is een vulnerability. Mensen die dus niet onder de experts vallen, kunnen deze fouten dus wel maken en dus zorgen voor een SQL injectie. Je kan het dus beter niet gebruiken of zorgen dat je het probleem dicht.
tja, probleem is dat bijna alle frameworks wel een vulnerability hebben als er een dummy developer mee werkt.........
juist,

Zelf programmeer ik ook in perl.

Hoewel ik meestal daarna de variabele laat dumpen om te zien of ik geen onzin heb getyped.

Hiernaast als je een subroutine aanroept gebruik ik meestal geen directe array maar meestal een object of je verwijst naar je array.

Hiernaast heeft het weinig zin om de variable direct te printen daarom heb ik bij mijn voorbeeld mijn data gedumped.

use Data::Dumper;
my @list = ("b","c");
#test your structure
warn(Dumper(["a",\@list,"d"]));

test(["a",\@list,"d"]);
sub test {
my @array = @{$_[0]};
my ($a, $b, $c) = @array;
print(Dumper([$a, $b, $c]));
}

dit geeft 2x:
$VAR1 = [
'a',
[
'b',
'c'
],
'd'
];
Niks overwachts aan en als dit voor bugs zorgt moeten ze maar teruggaan naar PHP.

Hoewel ik zelf geen serieuze ervaring heb met Perl, valt het me aan het voorbeeld wel op dat je kennelijk functies/stukjes codes kant schrijven die zowel een ljist met vier elementen van hetzelfde type (string), als een lijst met drie elementen met verschillende types (string en een lijst van strings) kunnen accepteren of teruggeven. Het schrijven van een functie die zoiets toestaat is in een sterk getypeerde taal (zoals Java, C# of Haskell) een stuk omslachtiger, want de programmeur van de module moet dit vrij expliciet aangeven. Daardoor wordt de programmeur die de module gebruikt automatisch gedwongen code te schrijven voor de twee verschillende situaties (anders gaat de compiler zeuren). Voor mij suggereert dat dat het hier misschien meer om de eeuwenoude discussie tussen zwakke en sterke typesystemen gaat en dan is het flauw om Perl verouderd te noemen. Zwak getypeerde talen leggen nu eenmaal een stuk meer verantwoordelijkheid bij de programmeur met als voordeel dat je minder syntactische overhead hebt. Overigens is teruggaan naar PHP (wat een zwak typesysteem heeft waarin allerlei 'automatische' conversies plaatsvinden) voor iemand die die verantwoordelijkheden niet aankan misschien ook niet helemaal aan te raden.
> Sites die op Perl en dbi leunen kunnen beter de prepare-functie gebruiken om sql-injectie te voorkomen.

Het is best schrijnend dat prepared statements nog steeds niet zó gemeengoed zijn. De gangbare scripttalen ondersteunen het al jaren, maar grote open source-projecten blijven toch aan stringmanipulatie doen in hun eigen DBA's, onder het mom van compatibiliteit. Heel jammer.

[Reactie gewijzigd door TimeVortex op 29 december 2014 22:54]

Ik zie dat als gemakzucht en kopieer gedrag van bad-practises. Ik heb in 1999-2002 geprogrammeerd in Delphi en dat wat me geleerd werd was om om prepare statements te maken en de data als parameters door te geven. Jaren later geniet ik nog van dit goede gedrag in PHP met PDO, Python, unixodbc/iodbc gebruik of wat dan ook. Succes met SQL injections! Wat daarna nog wel gedaan moet worden is het checken of filteren op de mogelijke bagger invoer en of je niet via de database elders genaaid wordt op een site of in een programma :-)
Ik zie dat als gemakzucht en kopieer gedrag van bad-practises.
Als de veilige interface eenvoudiger te gebruiken is dan de onveilge interface is er iets mis met die interfaces.. Kun je wel leuk alle programmeurs de schuld gaan geven maar daar schieten we niks mee op.
Ik zie het ook bij collega's wel, queries aanelkaar plakken met waarden erin. Als ik daar over val is het antwoord "maar met die vraagtekens vind ik het niet meer leesbaar". Nee, een "INSERT INTO test (a, b) VALUES ('".$a."','".$b."')" is lekker duidelijk met al die quotes, al helemaal als je dan in die query nog quotes gaat zitten vervangen met replace functies.
Die vraagtekens zijn ook niet duidelijk. Ik gebruik dan ook altijd named parameters icm prepared statements. Dit in veel talen niet standaard mogelijk maar met een eenvoudige search/replace alsnog toe te voegen.

INSERT INTO test (a, b) VALUES (:a, :b)

leest toch een stuk prettiger wat mij betreft.
Daar dient abstractie net voor.
Een van de oorzaken dat zij dit in hun DBA's zo oplossen is omdat ze evengoed geen DBA'ers hebben/er naar laten kijken.

Evengoed lijken stored procedures ook nog echt een no-go binnen de open-source (web scripts) wereld. Waarom een website-sql user met DELETE, DROP en ALTER rechten, iemand?
Het is schrijnend te noemen dat SQL-injecties mogelijk zijn dankzij slechte code die meent SQL-injectie te voorkomen maar zich niet aan de specificaties van de taal houdt. Het is net zo denkbaar dat er een fout in de implementatie van prepared statements zit dan dat er een fout in de DBI-module zit. In dit specifieke geval had het dus geholpen om prepared statements te gebruiken, maar omgekeerd had het net zo goed fout kunnen gaan.

Je had het pas schrijnend kunnen noemen als de genoemde projecten hun eigen geklopte database-code zouden gebruiken in plaats van een bekende en veel gebruikte module zouden gebruiken. In dit geval is het gewoon een flinke oversight van de ontwikkelaars achter DBI, en hun onkunde met betrekking tot Perl (Niet dat ik het beter zou kunnen overigens, na enkele maanden met Perl gestoeid te hebben heb ik besloten het nooit meer te gebruiken :+ ).
Om dit soort code veilig te programmeren moet je de compiler internaliseren, je moet in je hoofd alle mogelijke manieren nagaan hoe de code uitgevoerd gaat worden met alle mogelijke input.

Dit is met perl inherent moeilijker dan met een taal met een simpeler en voorspelbaarder type systeem (en php ook zoals de drupal exploit laat zien).

Bepaalde soort bugs zijn gewoonweg makkelijker te maken met bepaalde talen en alle programmeurs creëren bugs.

[Reactie gewijzigd door Pinkys Brain op 30 december 2014 13:42]

"Rubin riep aanwezige programmeurs op de hackersconferentie, die tot dinsdag duurt, op om te stoppen met het gebruik van Perl. Volgens de beveiligingsonderzoeker is Perl onveilig en sterk verouderd."

Wat een onzin. Perl is verouderd noch onveilig. Het is een moderne programmeertaal die continue in ontwikkeling is. Het probleem zit hem hier - zoals eigenlijk altijd - niet bij de gebruikte taal, maar bij de kwaliteit - of beter het gebrek daaraan - van de programmeur(s). Helaas wordt er nog steeds te makkelijk teveel rommel gemaakt, wat vervolgens aan de taal geweten wordt...
Ik vind dat je gelijk hebt maar nog wel een opmerking over Perl, de taal biedt mogelijkheden om er een onleesbare brei van te maken waarbij het gebruik van impliciete variabelen een hele nare is. Ik was maar wat blij toen ik met reeds geschreven code moest werken de programmeur voor mij alles uitgeschreven had. Niet voor niets is op Perl code wel eens het predicaat WORN (write once read never) van toepassing. Maar leuke krachtige taal is het wel, vooral voor het verwerken van data en de reguliere expressies zijn mooi. Maar ok, ik zeg niets, ik ben een K..programmer en een Kl....beheerder.
Dit is toch wel flink gehyped. Als er iets toelaat om het veilig te doen is het volgens mij perl.

Als je in een webpagina de gebruiker wil laten kiezen uit zeg maar 5 views, dan kun de feitelijke SQL query als parameter terug laten komen. En iedereen kan dat dan idd wijzigen.
Als ik zoiets programmeer is dat een no go.
De value 5 wordt bij mij, serverside, om gezet naar de 5de query.

Als er andere id's clientside worden doorgegeven dan check ik of die id's voldoen aan criteria als bestaande uit [0-9,a-z] en ook bestaan alvorens de feitelijke query uit te voeren.

Ik gebruik prepare alleen als het snelheids-winst oplevert, maar dan nog met eigen serveside validatie van de parameters.

Daarnaast krijgt de webserver alleen die rechten op de database en op de tabellen die hij nodig heeft. Het aantal webservers dat als root@localhost zonder password in logt, wil ik niet weten. Bij mij komt dat niet voor.

Ik geloof dus wel dat je copy-paste voorbeelden kan vinden van perl die niet veilig zijn. Maar das een ander verhaal, en geld natuurlijk voor meer talen als perl.
Dat lijkt redelijk, maar houd er rekening mee dat jouw regex [0-9a-z] minder specifiek is dan de check die SQL voor je doet (namelijk dat de ID echt bestaat). Dat soort checks levert daarom een schijnveiligheid op. Bovendien is jouw code een stuk minder getest dan de gemiddelde SQL server. Die prepared query functionaliteit wordt door miljoenen programma's en sites gebruikt. Snelheid is maar een neveneffect. Hergebruik van goed geteste code is de belangrijkste reden.
Daarnaast krijgt de webserver alleen die rechten op de database en op de tabellen die hij nodig heeft. Het aantal webservers dat als root@localhost zonder password in logt, wil ik niet weten. Bij mij komt dat niet voor.
Het probleem is dat jouw manier (op webserver nivo) zo ongeveer nul waarde heeft.
Elke behoorlijke applicatie heeft een administrator login en die benadert het ook via de webserver, dus als je enkel de rechten aan de webserver geeft dan is voor jouw database iedereen eigenlijk administrator.

In wezen zou je aan de webserver-user rechten moeten geven, maar dat gaat weer moeilijk met RDBMS'en want je kan veelal weer niet met rechten op rijen werken waardoor als iemand zijn wachtwoord kan veranderen hij in wezen iedereens wachtwoord kan veranderen die in dezelfde tabel staat
In wezen zou je aan de webserver-user rechten moeten geven, maar dat gaat weer moeilijk met RDBMS'en want je kan veelal weer niet met rechten op rijen werken waardoor als iemand zijn wachtwoord kan veranderen hij in wezen iedereens wachtwoord kan veranderen die in dezelfde tabel staat
Row Level Security (RLS) wordt door diverse databases ondersteund, is op zich geen probleem. Maar, dan moet je dus ook voor iedere user in je webapplicatie ook een database user aanmaken en voor iedere activiteit van deze web user ook de bijbehorende database user gebruiken. Vrijwel iedere applicatie gebruikt echter maar één (of hooguit enkele) generieke database user(-s) om voor alle applicatie users een database connectie te maken. En dan werkt RLS niet meer, de database weet niet beter dan dat deze ene database user de eigenaar is van alle records...

Oplossing: Werk netjes en zorg voor duidelijke requirements waar ook testgevallen voor worden gemaakt. En niet alleen de happy flow testen, maar ook de not so happy flow...
Ik wil best geloven dat Perl niet veilig is, maar is SQL zelf ook niet onveilig?
SQL is niet van deze tijd. De taal is in de basis al bijna 50 jaar oud. Veiligheid was toen geen issue, want computers stonden in afgesloten ruimtes en waren natuurlijk disconnected.

Een goede ORM (Object Relational Mapper) maakt grote delen van SQL in je code onzichtbaar. Als programmeur moet je wel weten hoe SQL werkt, zodat je kunt bekijken of bepaalde statements wel efficiënt zijn. Deze ORM's zorgen er ook voor dat je zelf geen SQL statements meer schrijft en voorkomen dus ook dit soort 'prepare' achtige constructies. Als je handmatig de SQL statements moet preparen, dan is het al foutgevoelig. Je vergeet het makkelijk en dan werkt alles wel, maar is het niet veilig.

Maar SQL is op meer vlakken outdated. De uitkomst van een SQL statement is altijd een platgeslagen lijst. Als je hierarchische queries hebt (joins), dan zou een hierarchische resultset ook prettig zijn (kan prima in XML of JSON), maar een SQL resultset is altijd platgeslagen en dat is erg onhandig.
Een goede ORM (Object Relational Mapper) maakt grote delen van SQL in je code onzichtbaar.
Dat je het niet ziet of er niet mee in aanraking komt, betekent niet dat het 'niet van deze tijd' is.
Maar SQL is op meer vlakken outdated. De uitkomst van een SQL statement is altijd een platgeslagen lijst. Als je hierarchische queries hebt (joins), dan zou een hierarchische resultset ook prettig zijn (kan prima in XML of JSON), maar een SQL resultset is altijd platgeslagen en dat is erg onhandig.
Je hebt het hier over een tradeoff waar bewust voor gekozen is. SQL is gebaseerd op relationele wiskunde en die basis maakt dat het een heleboel (complexe) queries ontzettend snel en efficient kan uitvoeren. Dat jij de resultset onhandig vindt, is geen argument. Je zult moeten aantonen dat er een beter werkend alternatief voor SQL is om SQL 'outdated' te mogen noemen.
Het probleem met de "relationele wiskunde" achtergrond is dat implementatie-details naar de voorgrond komen. SELECT COUNT(*) FROM x WHERE y is zo'n voorbeeld. Daar komt een set uit met altijd 1 rij met 1 element.

Je kunt je ook voorstellen dat dezelfde functie aangeroepen zou kunnen worden als COUNT x WHERE y. Dat is korter, duidelijker en tegelijkertijd hoef je niet meer de hack van een resultset met 1 rij, 1 kolom te gebruiken.

En in dit geval is het fundamentele probleem dat SQL code en data mengt. SQL injectie is concreet het uitvoeren van data (argumenten) als SQL code fragmenten. Ook dat is een taalprobleem.
Je kunt je ook voorstellen dat dezelfde functie aangeroepen zou kunnen worden als COUNT x WHERE y. Dat is korter, duidelijker en tegelijkertijd hoef je niet meer de hack van een resultset met 1 rij, 1 kolom te gebruiken.
1. Je haalt syntax en output door elkaar. Dat SQL een opvallende (en soms licht tergende) syntax heeft, staat los van de output die bepaalde queries opleveren.
In dit geval geldt overigens ook dat de COUNT-functie genoeg interessante extra opties ondersteunt om de huidige syntax aan te houden:
SELECT COUNT(DISTINCT y.id) AS ysForX FROM x LEFT JOIN y ON x.y_id = y.id GROUP by x.id.

2. Ik ben het wel met je eens dat er een grijs gebied is van uit snelheidsoverwegingen aan SQL toegevoegde functionaliteit welke op zich hacky genoemd kan worden. In de databasewereld geldt echter dat snelheid en efficiency erg belangrijk zijn en bezwaren omtrent de cleanness van de output makkelijk de deur uit kunnen worden gedaan.
En in dit geval is het fundamentele probleem dat SQL code en data mengt. SQL injectie is concreet het uitvoeren van data (argumenten) als SQL code fragmenten. Ook dat is een taalprobleem.
Vrijwel alle talen mengen code en data en van een 'taalprobleem' is dan ook geen sprake. Het probleem met SQL injections is dat, door gebrekkige sanitization, end users effectief stukken uit te voeren code mogen schrijven en in die zin is het een specifieke vorm van:
https://www.owasp.org/index.php/Code_Injection

Het credo is heel simpel, altijd en overal: input is gevaarlijk en dient zo behandeld te worden.
Ik haal syntax en output zeker niet door elkaar. SELECT geeft een resultset en SELECT COUNT(*) dus ook. Beide gebruiken dezelfde syntax en hebben daarom hetzelfde output type; dat wil niet zeggen dat syntax gelijk is aan output type.

Jouw voorbeeld van een complexe COUNT verandert niets aan het fundamentele concept. Met mijn hypothetische syntax zou je iets als COUNT DISTINCT y.iD FROM x LEFT JOIN x_y_id=y.id GROUP BY x.id krijgen; het deel van de syntax wat je resultset filtert voordat je COUNT uitvoert blijft hetzelfde. Maar fundamenteel is COUNT een operatie die een resultset als input heeft, en een scalar als output.

En je voorkeur voor snelheid is misplaatst; de snelheid wordt bepaald door het executieplan. Elke syntax die hetzelfde executieplan oplevert is even snel, maar niet elke denkbare syntax is even leesbaar.
Sorry, maar nee. Dit was je originele stelling die toch echt op basis van syntax iets over de output impliceert.
Je kunt je ook voorstellen dat dezelfde functie aangeroepen zou kunnen worden als COUNT x WHERE y. Dat is korter, duidelijker en tegelijkertijd hoef je niet meer de hack van een resultset met 1 rij, 1 kolom te gebruiken.
Het laatste is dus een non sequitur. De output is onafhankelijk van de syntax.
Maar fundamenteel is COUNT een operatie die een resultset als input heeft, en een scalar als output.
Nope. In de gegeven query krijg je een resultset met meerdere rijen counts van y gekoppeld aan bepaalde x-en. Je kunt een hele set rijen met meerdere kolommen met COUNTs, SUMs en AVGs e.d. genereren.

Het misleidende aan COUNT() is dat als er geen GROUP BY-clause is gespecificeerd, er _automatisch_ een impliciete GROUP BY NULL wordt toegevoegd. De veelgebruikte vorm van COUNT is niets anders dan een heel simpel geval van een potente aggregate-functie die toevallig slechts 1 resultaat oplevert.
En je voorkeur voor snelheid is misplaatst; de snelheid wordt bepaald door het executieplan.
Ik had het over het vraagstuk of je het berekenen van aggregates en andere derived data binnen je database-engine moet doen/mogelijk maken, of dat je die verantwoordelijkheid moet verplaatsen naar de code buiten de database. Je kunt in principe ook alle rijen ophalen en dan in een taal naar keuze itereren over de resultset om zelf SUMs, AVGs e.d. te berekenen. De onderbouwbare redenatie om dit soort dingen binnen de database-engine mogelijk te maken is dat deze toch al over de rijen moet itereren, daarbij efficient kan rekenen en het op die manier tevens mogelijk maakt om te sorteren of te filteren op basis van de aggregate (of derived) data.
Het argument voor een ORM was meer bedoeld om dit soort "prepare" achtige constructies te kunnen vermijden. Het heeft ook andere voordelen (helaas ook de nodige nadelen).

Ik vraag me af of die trade-off bewust gekozen is. Het voldeed voor dat moment, maar we zijn 50 jaar verder gewend aan complexere datastructuren dan toen. Een beter werkende resultset is bijvoorbeeld een XML of JSON gebaseerde resultset. Die is net zo snel op te hoesten en kost minder traffic en is prettiger te processen. Zou prima met een connectie optie om te zetten moeten zijn en toch backwards compatible te blijven.

Een ander nadeel van SQL is dat het beschrijvend is voor de mens, maar daardoor is bijvoorbeeld IntelliSense lastig. Stel dat je een query zo zou schrijven: FROM Table SELECT Column1, Column2. In dat geval zou je IntelliSense kunnen gebruiken, omdat je weet met welke tabel je werkt. De huidige syntax SELECT Column1, Column2 FROM Table maakt dit onmogelijk, omdat je bij het typen van de kolom de context nog niet weet. Daarom is LINQ (soort van ORM van .NET) ook precies andersom. TIkt echt een stuk lekkerder...

SQL is heel krachtig, maar het stamt uit de tijd van COBOL en FORTRAN. Dat is ook aan de syntax af te zien. Er zijn heel wat verbeteringen op SQL mogelijk, waardoor de taal een stuk vriendelijker zou worden.

Scalability van relationele databases (vooral over meerdere sites met behoorlijke latency) is een behoorlijk issue. Niet voor niets zijn NoSQL varianten zoals MongoDB, DynamoDB sterk in opkomst. Wel een wat ander doel en ik denk dat SQL ook nog een hele tijd bestaansrecht heeft, maar het zou van mij wel een vernieuwing mogen krijgen.
Het voldeed voor dat moment, maar we zijn 50 jaar verder gewend aan complexere datastructuren dan toen.
Je denkt dat het concept van hiërarchische datastructuren iets van nu is? Het punt is dat regelmatige datastructuren (x-dimensionale tabellen) veel .. regelmatiger zijn. En dat is belangrijk.
Een beter werkende resultset is bijvoorbeeld een XML of JSON gebaseerde resultset. Die is net zo snel op te hoesten en kost minder traffic en is prettiger te processen.
'Prettiger te processen' is onzin. Of je nou de omzetting naar JSON in de database-engine of de aanvragende code doet, maakt voor dit specifieke doel niets uit. 'Minder traffic' is eventueel wel een overweging, maar zodra dat een significante factor wordt, kun je waarschijnlijk beter je queries ophakken. Dat gezegd hebbende is er wel een simpele workaround in (bijvoorbeeld) MySQL, als je dit echt wil:
http://www.thomasfrank.se/mysql_to_json.html
De huidige syntax SELECT Column1, Column2 FROM Table maakt [intellisense] onmogelijk, omdat je bij het typen van de kolom de context nog niet weet.
Op zich waar, maar je wil eigenlijk toch bijna nooit met de hand SQL schrijven. In ieder geval niet dusdanig regelmatig dat code completion nodig is.
Maar ik ben het met je eens dat de syntax van SQL niet ideaal is.
Scalability van relationele databases (vooral over meerdere sites met behoorlijke latency) is een behoorlijk issue. Niet voor niets zijn NoSQL varianten zoals MongoDB, DynamoDB sterk in opkomst.
Ik heb het vermoeden dat die opkomst meer met 'Nieuw!' te maken heeft dan met de noodzaak voor scalability. Laten we eerlijk zijn: 99% van de applicaties waar NoSQL gekozen is heeft die scalability niet nodig. We zijn niet allemaal Google, Twitter of Facebook.
Ik heb het vermoeden dat die opkomst meer met 'Nieuw!' te maken heeft dan met de noodzaak voor scalability. Laten we eerlijk zijn: 99% van de applicaties waar NoSQL gekozen is heeft die scalability niet nodig. We zijn niet allemaal Google, Twitter of Facebook.
Dit. Hetzelfde geldt imo voor diensten als Cloudflare en Amazon webservices die ik zelfs regelmatig tegenkom op persoonlijke websites. 8)7 Voor grote, drukbezochte websites kan dit zijn voordelen hebben maar de site van de buurtvereniging heeft dit écht niet nodig.

NoSQL biedt wat potentiële extra performance ten opzichte van RDMS, ten koste van een aantal garanties met betrekking tot integriteit en veiligheid van de data. In veel gevallen is de integriteit van de data veel belangrijker dan een microseconde extra wachten. Je introduceert grote risico's met het gebruik van NoSQL systemen, zeker als je gaat clusteren, en die moet je als gebruiker goed begrijpen om de eventuele problemen die daaruit voortvloeien te kunnen corrigeren. Hou je daar geen rekening mee dan ben je net zo dom bezig als een SQL-database gebruiken zonder user input te filteren.
Andersom: als je toch al de methoden kent de werken voor serieuze websites, waarom zou je dan een andere methode leren die op kleine websites werkt? Het is niet zo dat Amazon EC2 problemen heeft met een te láge load.
Nee, op zich, maar voor websites met een lage load levert het juist een vertraging op (want meer DNS-lookups, meer verbindingen met verschillende hosts), en bovendien bevorder je hiermee tracking van je gebruikers door dit soort providers uit de VS, terwijl er geen enkele reden is om dat te doen.
Het voldeed voor dat moment, maar we zijn 50 jaar verder gewend aan complexere datastructuren dan toen. Een beter werkende resultset is bijvoorbeeld een XML of JSON gebaseerde resultset. Die is net zo snel op te hoesten en kost minder traffic en is prettiger te processen.
Laat ik even voorop stellen dat ik geen inhoudelijke kennis heb van sql-resultsets en hoe die over de lijn gaan.

Maar een huidige sql-resultset lijkt me ongeveer tig keer minder traffic kosten (alles heeft hetzelfde formaat, dus 1x headers sturen en dan hoef ik enkel values te sturen, itt json die bij elk record headers wil en xml die zelfs een header afgesloten wil hebben)
En prettiger te processen, dat zal best opgaan voor resultsets van 1000 regels.
Maar een xml/json van 4GB (zonder exacte vaststaande structuur) die kunnen een heleboel partijen niet meer processen hoor.
Terwijl met de huidige resultsets zelfs een 286 dat nog kan processen (duurt alleen een beetje erg lang).

En tja, je alternatieve schrijfwijze. Dat is echt peanuts om te implementeren zou je het echt willen (draai de volgorde gewoon weer om als je het moet versturen) alleen blijkbaar ziet niemand er de behoefte in.

En qua Scalability is het dan een afweging met betrouwbaarheid. Qua RDBMS is de betrouwbaarheid zo ongeveer wel uitgekristalliseerd (het werkt of als het niet werkt kan je naar partij x/y/z gaan en die maken het werkend) terwijl bij NoSQL ik op Internet vooral horror stories lees over kwijtgeraakte data etc als er ergens iets fout is gegaan.
Wat is jouw alternatief voor SQL dan?

Want in wezen voldoet SQL nog exact aan waar het voor gemaakt is. Het is een Structured Query Language die een resultaten set teruggeeft.

Hierarchie valt simpelweg niet goed in 1 resultaten set terug te geven.
SQL voldoet voor een heleboel zaken prima, maar voor hierarchische gegevens voldoet het niet. Je wilt niet meerdere roundtrips hebben, maar ook niet dat je data plat wordt geslagen. Een resultset als XML of JSON zou dan veel prettiger en compacter zijn. Het sluit elkaar natuurlijk niet uit.

Het heeft mij altijd verbaasd dat zoiets er nog niet is. Er zijn zat extensies op SQL en dit zou een erg wenselijke zijn. In .NET met Entity Framework zou het helemaal onzichtbaar zijn voor de programmeur. Ik denk dat heel veel programmeurs er blij van worden.
Ach, het probleem is vaak dat mensen niet eens weten dat alles onderliggend nog steeds gewoon middels SQL uitgevoerd wordt maar omgezet wordt naar iets waar zij wel makkelijker mee kunnen werken... Probleem komt dan ook vaak als ze ineens van platform A naar platform B moeten waar hun geliefde 'entityframework' of welk framework dan ook niet werkt..
Een ORM is geen volledige vervanging van SQL. een ORM is leuk om database tabellen met classes in je programmeertaal te mappen, en daarmee simpele SELECT, INSERT of UPDATE query's mee te automatiseren.
Als je echter wat ingewikkeldere query's wilt om data uit meerdere tabellen te combineren of te groeperen met JOINs of GROUP BY's dan is een ORM niet meer toereikend en ben je alsnog aangewezen op SQL dat hiervoor nog steeds heel krachtig is.
Dan ben je niet helemaal up-to-date met de modernere ORMs. Met LINQ/Entity Framework is het juist een verademing om composable queries te maken. In code een dynamisch SQL statement (veilig) opstellen is best lastig.

Het grote probleem van ORM's is vaak dat er teveel data wordt opgehaald (alle kolommen i.p.v. de subset die je nodig hebt) en dat programmeurs niet kijken naar efficiency (onder het motto dat het framework dat wel regelt). Het eerste probleem is oplosbaar (in LINQ/EF), maar het laatste probleem is helaas een mentaliteitskwestie.
Sorry een wat late reactie (oud&nieuw moest ook gebeuren)

Mijn probleem met LINQ/OQL achtige systemen is dat ze 1. minder kunnen en minder ontwikkeling hebben doorgemaakt 2. daardoor meer bugs hebben en minder krachtig/flexibel zijn; en 3. je dit helemaal opnieuw moet leren en uitzoeken.
Dan heb ik het nadeel van weer een abstractielaag, en dus idd performance verlies en hoge kans op schaalbaarheidsproblemen, nog niet meegenomen.

Queries met GROUP BY's, COUNT's, WITH's, CASE WHEN, UNION, subselects, gebruik van substring/timestamp/cast functies, enz, zijn meestal een ramp of onmogelijk in dat soort systemen. Zie bv iets als http://pastebin.com/AiT4jEyj nu is dat een monsterquery waar ik normaal ook geen voorstander van ben, maar soms heb je het gewoon nodig.
Mijn ORM ervaring is trouwens beperkt tot Doctrine en Hibernate.
Precies :-) 9 van de 10 keer is mijn data in ieder geval niet tabulair.
En daarvoor heb je dingen ala Mongo en RethinkDB
MongoDB, RethinkDB en DynamoDB zijn geweldige databases, maar zitten totaal aan het andere spectrum van databases. Soms heb je iets nodig dat wel relationeel is (al was het maar vanwege legacy issues), maar toch wat vriendelijker is voor hierarchische data.
SQL is niet van deze tijd. De taal is in de basis al bijna 50 jaar oud. Veiligheid was toen geen issue, want computers stonden in afgesloten ruimtes en waren natuurlijk disconnected.
Kuch!

Nederlands, Engels, Spaans, allemaal nog veel ouder dan 50 jaar, dus ook allemaal achterhaald? SQL, Structured Query Language, is ook van deze tijd en zal ook in de verre toekomst nog worden gebruikt. De taal is ook springlevend, regelmatig verschijnen er weer nieuwe standaarden bij.
Een goede ORM (Object Relational Mapper) maakt grote delen van SQL in je code onzichtbaar. Als programmeur moet je wel weten hoe SQL werkt, zodat je kunt bekijken of bepaalde statements wel efficiënt zijn. Deze ORM's zorgen er ook voor dat je zelf geen SQL statements meer schrijft en voorkomen dus ook dit soort 'prepare' achtige constructies. Als je handmatig de SQL statements moet preparen, dan is het al foutgevoelig. Je vergeet het makkelijk en dan werkt alles wel, maar is het niet veilig.
En omdat iets niet zichtbaar is voor de programmeur, is het niet van deze tijd of bestaat het niet? ORM's zijn handig om snel iets in elkaar te draaien op een onbekende database, maar wat performance betreft, is het über extreem langzaam. Of je nu Oracle, Firebird, PostgreSQL of SQL Server gebruikt, de queries die door een ORM worden gemaakt, zijn gewoon dom en daardoor wordt een applicatie langzaam. Ik ken voorbeelden van Hibernate waarbij een inlogpagina ruim 1100 queries produceerde en wat ruim 10 seconden duurde. De database deed er slechts enkele milliseconden over, de rest van de tijd ging in Hibernate (dus de ORM) en de Java applicatie zitten. Dom, dommer, ORM.
Maar SQL is op meer vlakken outdated. De uitkomst van een SQL statement is altijd een platgeslagen lijst. Als je hierarchische queries hebt (joins), dan zou een hierarchische resultset ook prettig zijn (kan prima in XML of JSON), maar een SQL resultset is altijd platgeslagen en dat is erg onhandig.
Dan vraag je toch aan je database om een stuk XML of JSON aan jou te geven? Wanneer jij dat fijn vindt, moet je daarom vragen. Wanneer je er niet om vraagt, moet je ook niet klagen dat je het niet krijgt.

Of ga je ook in een bar zitten en loop je na een uur boos weg omdat niemand jou een biertje geeft zonder dat je er om vraagt?

SQL is zeer actueel en wordt in vele applicaties 24x7 gebruikt. Dat er programmeurs zijn die niet alle ins en outs van SQL kennen, klopt helemaal, maar dat wil niet zeggen dat SQL outdated is. Een gebrek aan kennis zegt iets over de programmeur, niet over de taal. Mijn Frans is ook slecht, en dit zegt meer over mij dan over het Frans. Of niet dan?

[Reactie gewijzigd door cariolive23 op 30 december 2014 17:48]

Ik wil best geloven dat Perl niet veilig is, maar is SQL zelf ook niet onveilig?
In dit geval voert SQL gewoon de query uit die Perl aanlevert. Dat dit niet de query was die de programmeur voor ogen had (moeten hebben), kan SQL niet weten.

@hieronder: controle op user-input moet door Perl gedaan worden. Mijn punt is dat SQL (ondanks alle gebreken) in dit geval geen veiligheidsfouten bevat.

[Reactie gewijzigd door doeternietoe op 30 december 2014 10:53]

Je moet user input NOOIT vertrouwen.
Het is dan ook van de zotte om user input aan iets te voeren dat het kan parsen.
Dat de standaard SQL interface bestaat uit text waar de velden gescheiden moeten worden door speciale karakters ipv een binaire interface is natuurlijk van de zotte ... dat we dat nog steeds gebruiken na zoveel jaren hoewel we weten hoeveel fouten dat in de hand werkt is nog veel erger.

Programmeurs zijn allemaal van de pot gerukt wat dat betreft, C had ook al lang aan de kant moeten worden gezet voor het overgrote deel van software.

[Reactie gewijzigd door Pinkys Brain op 30 december 2014 04:00]

Programmeurs zijn allemaal van de pot gerukt wat dat betreft, C had ook al lang aan de kant moeten worden gezet voor het overgrote deel van software.
Dat is hetzelfde als zeggen dat Chinees al lang aan de kant gezet had moeten worden. Er zijn zat (goede) programmeurs die zweren bij C of C++ en er is geen enkele reden waarom zij dat niet zouden moeten doen. Dat andere programmeurs beter uit de voeten kunnen met andere talen doet daar niets aan af. De keuze voor programmeertaal is een combinatie tussen eisen aan snelheid, portabiliteit, flexibiliteit, interoperabiliteit en persoonlijke voorkeur. Hierbij zijn al deze factoren minstens even belangrijk.
Eh, waar haal je C++ opeens vandaan? Eén van de belangrijkste redenen waarom C opzij gezet moet worden is nu juist de beschikbaarheid van C++, wat een stuk betrouwbaarder is. Een C++ std::string is een stuk beter bestand tegen buffer overflows dan een char[20] in C.

C had historisch een snelheidsvoordeel, en dat rechtvaardigde het gebruik, maar C++ is al jarenlang minstens net zo snel zoniet sneller. (Strengere type-safety rules en meer types voorkomen aliasing, waardoor register reloads minder vaak nodig zijn)
Ik haal C++ erbij aangezien die door de meeste critici in één adem door genoemd worden.

C is nog steeds gebruikelijk in embedded systemen en de Linux kernel is ook in C geschreven. Deels omdat dat van oudsher zo is natuurlijk, maar ook omdat C gewoon efficiëntere machine code en kleinere binaries oplevert.

Maar ik weet natuurlijk niet of Pinkies Brain het specifiek over C of over C/C++ had.
Ben blij dat je de opmerking maakt, C is niet opzij geschoven door C++, C is nog steeds een veelgebruikte taal en wat mij betreft nog steeds de taal der talen. Veel mee gedaan en ook wel gemixt met C++.. Ook al zijn er heel veel andere leuke en mooie programmeetalen waar wat voor te zeggen valt. Perl is een krachige taal maar Python vind ik bijvoorbeeld ook een hele mooi taal. En met evenveel plezier nu met Javascript in de weer. Ik heb geloof ik alleen iets tegen Java of beter de JVM, al ken ik die alleen vanuit het oogpunt van beheer en dat vond ik geen pretje. Al kan dat ook aan de code liggen maar ook van wat ik om heen hoor is dat geen onverdeeld genoegen.
Zij zweren bij C of C++, wij zweren als die "goede" programmeurs weer eens bij een kritisch stuk software een buffer overflow in hebben gebouwd.
Bugs zijn onvermijdelijk in elke software, al getuigen buffer overflows doorgaans wel van te gehaast te werk gegaan zijn of onkunde. Er worden minstens net zo veel, zo niet meer ernstige beveiligingslekken in talen gevonden die buffer overflows onmogelijk maken.
Niet alle soorten bugs leiden zo makkelijk naar het uitvoeren van code als buffer overflows, net zo als niet alle soorten bugs zo makkelijk leiden naar het openen van de database inhoud als SQL injection, net zo als niet alle soorten bugs leiden naar het ontwijkbaar maken van een SQL injection prevention layer.

Er zijn klasses van aantoonbaar zeer makkelijk te exploiten bugs die direct kunnen worden terug gevoerd naar specifieke eigenschappen van talen en APIs ... ik zou zeggen, laten we die eigenschappen zo veel mogelijk niet gebruiken. Programmeurs zeggen, laten we tientallen jaren onze kop tegen de muur rammen en doen alsof alleen anderen ooit bugs in hun programmas hebben.

PS. nou doen we als mensen natuurlijk allemaal wel collectief idiote dingen ... maar dat is geen excuus, zouden we ook niet moeten doen.

[Reactie gewijzigd door Pinkys Brain op 30 december 2014 23:03]

Doet me een beetje denken aan de Drupal SNAFU van een tijdje terug ... kwam ook omdat de taal onvoorspelbaar omging met de data.

https://www.drupal.org/SA-CORE-2014-005

Een beetje de achilleshiel van de niet static typed talen, zoals overmatig pointer gebruik dat is van C.

[Reactie gewijzigd door Pinkys Brain op 30 december 2014 03:56]

Een beetje de achilleshiel van de niet static typed talen, zoals overmatig pointer gebruik dat is van C.
Het woord 'overmatig' zegt al dat het een slecht teken is. Dat gebeurt dan ook vrij weinig, in de meeste C-code worden pointers gebruikt waar ze nodig / een functie hebben, en dus niet overmatig zijn. Geen achilleshiel wat mij betreft. Dat is een inherente eigenschap van de taal die het snel en efficiënt maakt, maar waar je wel enige kennis van moet hebben voordat je ermee aan de slag gaat.
Dat die "kennis" er niet is bij een groot deel van programmeurs is wel duidelijk.

Net als string SQL queries zouden de meeste programmeurs niet in de buurt van c mogen komen. Het beetje energie verbruik door inefficientere talen is zo terugverdient door de mindering in exploits.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True