Appsecurity: ondergeschoven door ouderwetse aanpak
Gepubliceerd: Dinsdag 30 december 2008
Auteur: Michiel van Blommestein
Vraag het aan een willekeurige beslisser of afdelingshoofd, en hij zal u verzekeren dat applicatiebeveiliging heel erg belangrijk is. Maar iets eraan doen is minder populair. Wat moet er verandering in de wereld van applicatiesecurity? "Applicatiesecurity was altijd gericht op gesloten omgevingen."
"U weet wellicht wie Tom Hogan is? Dat is het hoofd van de softwaredivisie van HP", zo zegt Hoffman vlak voor hij met een muisbeweging naar het volgende powerpointblad klikt. "En dit is zijn declaratieoverzicht van het tweede kwartaal." Het licht van de beamer projecteert een wat saai aandoende tabel Het is een lijst met etentjes, vervoerskosten enzovoorts die Hogan bij zijn bedrijf heeft gedeclareerd in de lentemaanden van 2008. Grappig detail: een van de declaraties is afgewezen.
Het is een van voorbeelden die Hoffman, hacker en tegenwoordig beveilgingsonderzoeker bij HP-dochter SPI Dynamics gaf tijdens een presentatie aan Techworld, afgelopen herfst. Het lek in het declaratiesysteem van HP was volgens hem eenvoudig uit te buiten met een SQL-injectie. Ondertussen is de boel uiteraard gerepareerd, maar het lek liet meer toe dan het lezen van de declaraties van medewerkers. "Declaraties moeten altijd door iemand anders worden goedgekeurd", zegt Hoffman. "Daar bleken we ook eenvoudig bij te komen, en een test waarbij ik een enkele dollar kon declareren voor mezelf werkte. Die heb ik trouwens netjes aan Hogan teruggegeven."
Wal en schipHet belangrijkste probleem is dat applicatiebeveiliging in het ontwikkelproces tussen wal en schip in valt, zo zegt Sebastien Deleersnyder, beveiligingsspecialist bij integrator Telindus en oprichter van de Belgische afdeling van OWASP (Open Web Application Security Project) in een interview met Techworld. OWASP is een internationale denktank die applicatiebeveiliging beter op de radar wil krijgen.
De ontwikkelaar bekommert zich volgens Deleersnyder vooral over het op tijd afkomen van een applicatie, terwijl de beheerder het zich niet verantwoordelijk voelt voor fouten in de code. "Ze zijn allebei weliswaar verantwoordelijk, maar het resultaat is dat die verantwoordelijkheid versnippert", zegt Deleersnyder. Daar is Hoffman het gedeeltelijk mee oneens. "Je kunt van een beheerder moeilijk verwachten dat ze verantwoording afleggen voor een fout in software die ze niet zelf hebben uitgekozen."
Het is een gevolg van de verplaatsing van applicaties naar het web, zo gaat Deleersnyder verder. "Applicatiesecurity was altijd gericht op gesloten omgevingen. Applicaties draaiden immers vooral inpandig", zegt hij. "Maar met de komst van Web 2.0, en dan vooral AJAX, Flex en dat soort technologie, zijn is dat allang niet meer het geval." Die uittreding van applicaties heeft ertoe geleid dat de 'oude' beveiligingsmaatregelen toe zijn aan herziening, iets dat voorlopig niet van de grond wil komen.
OntwikkelprocesMaar hoe zou de aanpak eigenlijk moeten zijn? Zowel Hofmann als Deleersnyder zouden graag veranderingen zien in het ontwikkelproces. "Een securitylek moet in de ontwikkeling behandeld worden als een defect in de software. Het is gewoon een bug, maar het wordt nu als apart achterafje behandeld", zegt Hoffman. Hij is dan ook een van de vele pleitbezorgers uit de securityhoek van wat hij noemt een 'defense in depth'-aanpak van applicatie-ontwikkeling; in plaats van een incomplete testfase op het einde, zouden ontwikkelaars na elke ontwikkelfase een testmoment moeten inbouwen. "Dus na het ontwerp direct even zoeken naar mogelijke lekken, na de ontwikkeling zelf even zoeken, na het in productie nemen enzovoorts", zegt Hoffman.
Over applicatiebeveiliging bestaan misverstanden. "Eén daarvan is dat een gewone Firewall en SSL voldoende beveiliging bieden", zegt Deleersnyder. "De ander is dat verbeteringen aan het framework waarmee de applicatie gebouwd wordt beveiligingsproblemen kan voorkomen. Het kan een hulp zijn voor goede ontwikkelaars, maar het is niet afdoende; het blijft gewoon mogelijk om slechte code te schrijven."
Toch zijn er verbeteringen en veranderingen op komst. De belangrijkste verandering voor 2009 is volgens Deleersnyder de verschuiving van de beveiligingsfocus naar de browser. "Het is een belangrijk toegangspunt geworden voor allerlei applicaties, en beveiligers kijken er ook steeds meer op die manier naar. Dat is positief", zegt hij.
Met html 5.0 op de rol hoopt Deleersnyder dat security prominenter gaat worden in deze nieuwe specificatie, iets waar OWASP op aandringt. "In de huidige drafts is het voor ons nog niet voldoende. Er moet bijvoorbeeld nog goed gekeken worden naar hoe html omgaat met de gegevens die browsers lokaal opslaan", zegt Deleersnyder.
Lees hier de explainer over wat er bij applicatiebeveiliging om de hoek komt kijken.
Bron: Techworld
