Fietsen verleer je niet. Programmeren kennelijk ook niet. Deze gedachte overviel me tijdens mijn bezoek aan de OWASP BeNeLux 2010 in Eindhoven eind vorig jaar. Deze gedachte voegde zich bij een andere mening die ik al een tijdje heb: Ik verbaas me over het soort kwetsbaarheden wat in applicaties gevonden wordt. In besturingssystemen worden nog steeds buffer overflows bij de vleet gevonden.
In webapplicaties is het niet anders, al hebben de kwetsbaarheden een ander karakter. Kijken we naar de huidige OWASP top 10-lijst dan zijn de top twee kwetsbaarheden 'injection' en 'cross-site scripting'. Deze kwetsbaarheden staan al jaren in de top 10. In beide gevallen is de webapplicatie kwetsbaar omdat er data gebruikt worden die vanuit een onbetrouwbare bron zijn binnengekomen. Meestal zal dit gewoon tekst zijn die de gebruiker intikt in een webformulier. Als de informatie van de gebruiker afkomt en de gebruiker geen fouten maakt en niet kwaadwillend is, dan gaat dit goed. Dat is wel een hele lijst aannames, maar als beveiliger mag je daar niet van uitgaan.
Luisterend naar de presentaties hierover, kreeg ik spontaan flashbacks naar mijn programmeercarrière. Ik heb als software engineer nooit het internettijdperk meegemaakt. Sterker nog, ik heb geprogrammeerd voor een mainframeplatform. Niet van IBM, maar van Unisys, de A Series-systemen. Nu waren er in die tijd geen webapplicaties, maar de problematiek achter buffer overflows was bekend en ook injectie-problematiek waren we ons bewust van. Cross-site scripting is wat moeilijker te projecteren op de systemen uit die dagen.
A Series-systemen hebben een andere architectuur dan de pc of Unix. Deze systemen zijn in de zestiger en zeventiger jaren ontworpen met beveiliging als een fundamentele pijler. Er waren specifieke functies opgenomen in het besturingssysteem om buffer overflows en injecties van ongewenste data tegen te gaan, die door de programmeur eenvoudig gebruikt konden worden. Vandaar mijn verbazing dat we dertig jaar later nog steeds hiermee aan het worstelen zijn.
En het punt van dit artikel? Sommige besturingssystemen zijn verkeerd opgezet? Standaard constructies voor programmeren bestaan allang? Vroeger was alles beter?
Help me aub, ik zie het niet.
@Caption Obvious: het is nogal duidelijk: de auteur vraagt zich af waarom hetzelfde probleem zich in 1001 gedaanten voordoet. En geeft ook aan dat er ten minste 1 oplossing is: een bibliotheek van functies die de problemen verhelpt.
Het nieuwe probleem: een projectmanager vinden die budget vrijmaakt om deze bibliotheek te implementeren.
Er zijn genoeg redenen aan te geven dat beveiligingsproblemen niet verdwenen zijn:
– architecturen zijn door het internet complexer geworden, waardoor zaken als cross-site scripting in beeld komen
– er worden steeds nieuwe exploitatiemethoden ontwikkeld, zoals ‘return oriented programming’
– managers en opdrachtgevers geven nog steeds voorkeur aan goedkoop en snel, beveiliging is alleen in naam een issue, IT-shops die hier veel aandacht aan besteden verliezen de wedstrijd op commercieel gebied
– leveranciers van ontwikkelomgevingen geven de voorkeur aan regelmatige vernieuwing boven stabiliteit, stilstand is achteruitgang, ontwikkelaars moeten volgen, dat zorgt ervoor dat beveiliging achteraan blijft hobbelen.
“Is veilig programmeren wel zo nieuw?”
Nee, maar het gebruik van “common-sense” / “nuchter boeren verstand” blijkbaar wel.
Want zoals Murphy al aangaf:
“Ïf something can go wrong, it WILL go wrong”
Maak de (digitale) dingen niet ingewikkelder dan echt nodig is. Dat scheelt een hoop overhead, onduidelijkheid en kans op ontwerp en programmeerfouten.
@Captain Obvious – Het gaat mij om het menselijk gedrag. Alle techniek wordt door mensen ontwikkeld. Als het probleem al zo lang bekend is en er ook al veel langer oplossingen voor gevonden zijn in het tijdbeeld van toen, dan verbaasd het mij dat we er vandaag de dag toch nog steeds mee worstelen.
@Marcus – In Unisys A Series is de bescherming wat meer dan een software library. Het is ingebouwd in de firmware. Je hebt in dat geval dus geen extra budget nodig, als je het systeem al in huis hebt – en dat zijn er niet zo veel.
@Victor – Return oriented programming is een slimme techniek, maar ook die heeft een kwetsbaarheid zoals een buffer overflow nodig om toegepast te kunnen worden. Nog meer reden waarom je de basis veilig moet hebben.
Ik ben het met allen eens dat software alleen maar complexer geworden is en dat de focus ligt op goedkoop en snel. Onveilig programmeren is wellicht snel in de implementatie, maar zeker niet goedkoop op termijn. Het repareren van kwetsbaarheden wordt alleen maar duurder hoe verder in het productieproces die ontdekt wordt. Ik begrijp het echter wel, op een gegeven moment gaan ze niet meer van het budget af van die projectmanager…
En dan komen we terug op de paradox: Het is goedkoper om iets goed te ontwikkelen, met aandacht voor security vanaf het begin. Maar omdat het duurder voor het implementatietraject is, doen we het dus kennelijk niet. En zo werkt het al tijden…
Programmeren op een mainframe (waar de auteur naar refereert is denk ik niet te vergelijken met de hedendaagse manier van programmeren.
zelf ben ik ooit begonnen met programmeren in de vorm van hexadecimale code kloppen op een exidy sorcerer met 16k geheugen (kostte destijds, omgereked, €1500 !)
Vooraf flowchart maken, hex commando’s erbij zoeken, tellen of het in geheugen paste etc. Een monnikkenwerk, maar wel rete-stabiel!
Zoals de auteur in zijn reactie al aangeeft, het mainframe waarop hij geprogrammeerd heeft is al van huis uit beschermd. Hoe anders is dit bij een gemiddelde windows PC, die out of the box vol zit met lekkages, getuige het aantal vulnerability- en andere patches dat jaarlijks uitkomt.
Ook het traditioneel (ouderwets) programmeren, waarbij je zelf alles in de hand had (inclusief beveiliging) bestaat al lang niet meer. We gebruiken allerlei libraries van in- en externe partijen, waarbij we dan hopen dat er niet te veel lekken inzitten. In plaats van hexadecimale (of binaire) code te kloppen, gebruiken we een zoveelste generatie programmeertaal, die de code uiteindelijk compileert naar nullen en enen. Ook hierbij hopen we dat dit goed en veilig gebeurt.
Niet dat dit verkeerd is. Immers, er kunnen hele mooie applicaties mee gemaakt worden.
Echter, als programmeur heb je daarmee wel veel minder grip op de veiligheid van het totale syteem dan op de oude mainframes.
Kijk ik naar de vraagstelling, dan denk ik niet dat veilig programmeren nieuw is. Het is alleen wel veel moeilijker geworden.
@PaVaKe: Leuk, ik ben ook begonnen op de Exidy! Even voor de beeldvorming: ik programmeerde in het mainframe OS i.s.m. de hardware ontwerpers om o.a. beveiliging goed in te bouwen.
Ik hoor vaak dat het programmeren veranderd is. En ja, we hebben nu object-oriented programming en visual suites. En helaas ook verwacht men voor alles tegenwoordig een kant-en-klare library.
Maar zelfs als je er van uitgaat dat een Windows/unix/linux systeem vandaag de dag meer kwetsbaarheden heeft, kijk dan even naar de top twee problemen die ik noemde: overflows en injecties.
Overflows voorkom je als programmeur door niet blind data in te kopieren, maar te zorgen dat je altijd een grens stelt. Of dat nu in de applicatie zit, in de library of in het OS. Ik ben het met je eens dat je als applicatieprogrammeur niet de problemen in het besturingssysteem kunt oplossen. Dat was in de mainframe dagen ook niet… Statische codeinspectie zou potentieel voor overflows al aan het licht brengen. Dat wordt dus kennelijk niet genoeg gedaan en dat verbaasd me.
Injecties voorkom je door niet alles te accepteren wat een gebruiker kan ingeven. Ook dit vergt wat extra werk. Met voldoende scheiding tussen model-view-controller zou een applicatieprogrammeur hier altijd iets in kunnen betekenen, ongeacht welke libraries je gebruikt. Ook dit komt al in statische codeinspecties aan het licht.
Ik ging naar OWASP denkend dat het allemaal moeilijker geworden was, ik kon het echter prima volgen met mijn mainframe verleden…
in hoeverre worden de system methologies nog gebruikt en die natuurlijk in aansluiting met het platform of gaat tegenwoordig iedereen weer achter de computer zitten en schrijft naar eigen dunk een programma