We Love IT > Magazine > Inhoud - 2009 uitgave 2 > Sogeti Nederland

Proactive Security Strategy

"60% van de websites bevat een ernstig beveiligingslek", dat is de conclusie van het zevende WhiteHat Security onderzoek dat eerder dit jaar werd gepubliceerd. Vergelijkbare onderzoeken tonen hogere cijfers. Hoe veel het precies is weet natuurlijk niemand, maar dat het er teveel zijn is zeker. Wat is de oorzaak van deze hoge cijfers? Zijn de meeste programmeurs zo slecht of speelt er iets anders? In dit artikel geven we een korte inleiding in Application Security en zullen we aangeven hoe je het meest voorkomende beveiligingslek, crossite scripting, in Oracle Application Express kunt voorkomen.

Het beveiligingsprobleem komt deels voort uit het feit dat het eigenlijk nooit een probleem is geweest. De eerste applicaties draaiden op een grote centrale computer en konden worden bereikt via terminals. Wilde je iets doen op het systeem dan moest je bij een terminal in de buurt zijn. De applicatie kon ¿open¿ worden ontwikkeld want het beveiligingsprobleem was op te lossen met fysieke maatregelen. In de periode erna gingen we systemen aan elkaar knopen. Systemen gingen met elkaar communiceren over netwerken. Het probleem verschoof zich naar de netwerklaag. Oplossingen als firewalls werden in het leven geroepen en er werd dus nog steeds ¿open¿ ontwikkeld. Nu, met het Internet, Web2.0 en cloudcomputing kan een applicatie overal, altijd en met iedereen praten en verschuift het probleem zich nogmaals, maar nu naar de applicatie zelf.

Bugs en flaws

Uit bijna alle studies blijkt dat ongeveer de helft van de beveiliginggerelateerde problemen voortkomt uit het ontwerp en de inrichting van de applicatie. Deze fouten noemen we 'flaws'. De andere helft, die voortkomen uit de daadwerkelijke bouw, noemen we 'bugs'. Een goed voorbeeld om het verschil duidelijk te maken zijn de flaws en bugs is het racespelletje Mariokart voor de Nintendo Wii.

In dit spel is het de bedoeling om zo snel mogelijk drie ronden over een parcours te rijden. Stel dat je erg goed bent, dan zou je er 30 seconden over doen om een ronde te rijden, en 1 minuut 30 als totaaltijd. Deze scores worden vanaf de Wii verstuurd naar een centrale server zodat je kunt zien hoe goed je bent ten opzichte van andere spelers. Het spel was amper een week uit en er verschenen scores van 0,01 seconden. Wat was hier het geval? Men reed de eerste twee ronden normaal en stopte in de derde ronde vlak voor de finish. De tijd liep op naar 2 minuten, 3 minuten, etc. om uiteindelijk aan te komen bij 99 minuten. Daarna sprong de tijd terug naar 0 minuten. En dan gingen de spelers de finish over. Bij Nintendo had niemand er bij stil gestaan dat er mensen zijn die meer dan anderhalf uur wachten om een goede tijd neer te zetten. Dit komt dus voort uit het ontwerp en noemen we een flaw. Dit werd snel door Nintendo gerepareerd door op de server de racegegevens te analyseren.

Een maand later kwamen er totaaltijden op de server van 35 seconden. Wat de spelers hier deden was een ronde rijden en dan vervolgens heel vaak vooruit en achteruit over de finish. Als men dit ongeveer tien keer deed ging er iets mis en werd deze actie door het spel gezien als een volledige ronde. Dit kon je dan nog een keer herhalen voor de laatste ronde om zo op enkele seconden boven een rondetijd uit te komen. In het ontwerp van de applicatie zal duidelijk staan dat een speler de 3 ronden volledig moet rijden, maar dit is blijkbaar niet goed geprogrammeerd. Dit is dus een bug.

Secure Development Lifecycle

Zoals in deze voorbeelden worden dit soort problemen vooral achteraf ontdekt. Het probleem oplossen betekent dan veel extra werk. Hoe eerder in de lifecycle van applicatieontwikkeling een probleem wordt onderkend, hoe efficiënter het is om treffende maatregelen te nemen.

100% veilig is in de praktijk onmogelijk en wellicht niet altijd nodig, maar veel problemen kunnen worden voorkomen door volgens een Secure Development Lifecycle (SDLC) te werken. Er zijn een aantal SDLC¿s beschikbaar. De meest bekende is de ¿Security Touchpoints¿ van Citigal. Deze gaat uit van zeven punten in de lifecycle van een applicatie. Of je nu waterval, iteratief, agile of een ander ontwikkelproces neemt, je zult altijd langs deze punten komen. We zullen er een aantal kort behandelen.

Applicatieontwikkeling begint met het opstellen van de eisen en wensen ten aanzien van de functionaliteit. Wat moet de applicatie allemaal kunnen? Vandaar uit worden de use cases opgesteld. Vanuit de SDLC wordt gesteld dat naast de functionele requirements ook de security requirements moeten worden opgesteld. Hierin wordt het ongewenste gedrag beschreven. De gedachtegang hierachter is dat als je alleen beschrijft wat je wilt, je soms impliciet ongewenste functionaliteit meekrijgt. Het alleen stellen dat de applicatie beveiligd moet worden met een login en wachtwoord sluit niet uit dat SQL statements gebruikt kunnen worden om het systeem alsnog te hacken. De security requirements zijn een input voor de "abuse cases". Een abuse case is een beschrijving van de complete interactie tussen een systeem en één of meerdere actors, waarbij de uitkomst van de interactie schadelijk is voor het systeem, een actor of stakeholder van het systeem. Als hier iets wordt gedefinieerd als ongewenst zal het ook worden benoemd in de ontwerpen, testplannen en sourcecode.

Tijdens de realisatiefase kan men naast het controleren van de source op stijl en syntax ook "static code analyse" toepassen. Hierbij wordt door analyse van de broncode bepaald of het uitvoerbare resultaat tot ongewenste data flows en constructies kan leiden. Er zijn verscheidene tools beschikbaar die meeste zaken vele malen sneller kunnen vinden dan dat een mens dat ooit zal kunnen.Sommige situaties zullen echter nooit voor kunnen komen of zo bedoeld zijn. Daar is er altijd iemand nodig om de uitkomst te kunnen beoordelen.

Alle stappen worden uitgebreid behandeld in het boek ¿Software security¿ van Gary McGraw. Microsoft heeft zijn eigen Security Development Lifecycle. Deze is niet zo platformonafhankelijk als touchpoints, maar gaat specifiek in op welke oplossingen er zijn met de diverse Microsoft producten. Als laatste is er de CLASP van OWASP. Deze geeft geen oplossingen maar stelt alleen vragen waar een specifieke rol aan zou moeten denken.

Binnen Sogeti ondersteunen we alle drie de SDLC¿s, echter er ontbrak nog iets aan deze aanpak. Een SDLC geeft een richting maar je moet wel de kennis en de tools hebben om er mee aan de slag te gaan. Om hierin te voorzien zijn wij met Proactive Security Strategy (PaSS) begonnen. Met PaSS worden eerst alle betrokkenen bewust gemaakt van application security. Hiervoor is een algemene Application Security Awareness cursus opgezet. Per functie (projectmanager, informatie analyst, ontwikkelaar, etc.) en per platform is er een specifieke vervolgcursus of werkgroep beschikbaar om die kennis en tools te borgen. Deze kennis wordt actief met het OWASP gedeeld. Proactive Security Strategy (PaSS)

Open Web Application Security Project

Het “Open Web Application Security Project” (OWASP) is een online community voor het vinden, voorkomen en bestrijden van onveilige applicaties. De basis is de website www.owasp.org waar op basis van een wiki de meest uiteenlopende informatie omtrent applicatiebeveiliging wordt geborgd. Het meest bekende product dat is voortgekomen uit OWASP is de “OWASP top 10”. Dit is een lijst van de tien meest voorkomende problemen. Deze lijst wordt periodiek geactualiseerd omdat sommige problemen meer onder de aandacht komen. Op nummer één staat al sinds 2004 crosssite scripting (XSS).

XSS ontstaat wanneer een webserver 'client-side' invoergegevens ongefilterd terugstuurt zodat deze door de webbrowser van de 'client' worden weergegeven.Het gevaar van XSS is heel breed omdat XSS, onmerkbaar voor de eindgebruiker, het gedrag van de browser kan beïnvloeden en de content van de pagina kan lezen en wijzigen. Een voorbeeld hiervan is het stelen van sessiegegevens. Nadat een clientapplicatie, zoals een browser, een verzoek heeft gedaan voor een webpagina en de server antwoord heeft gegeven, zijn de client en de server elkaar vergeten. Dit is inherent aan het http protocol wat stateless is. Om toch een vorm van dialoog te creëren wordt er door de server bij het eerste antwoord een sessie identificatie meegegeven. Bij ieder volgend verzoek zal de browser dit nummer weer mee sturen. Het enige wat iemand dus uniek maakt in de conversatie met de server is dat nummer. Weet iemand dat nummer te bemachtigen kan hij het zelf meegeven in zijn verzoek en zal de server denken dat hij die andere persoon is. Met XSS is het mogelijk om deze gegevens uit te lezen.

XSS met Oracle Application Express

In onderstaand scherm wordt de mogelijkheid geboden om voor een product een uitgebreide omschrijving op te nemen.

Product Description

Door deze ‘Product Description’ uit te breiden met bijvoorbeeld onderstaande toevoeging

kan er al invloed worden uitgeoefend op hoe de informatie in bijvoorbeeld overzichtschermen wordt getoond. In dit geval door het tonen van een smiley en een alertbox, zoals in de volgende schermafbeelding is weergegeven.
Overzichtscherm met smiley en alertbox

Om te voorkomen dat dergelijke malicious code van gebruikers ook daadwerkelijk wordt uigevoerd bij het tonen in overzichten kan in Application Express de manier van tonen van deze gegevens worden aangepast. In de ‘Column Attributes’ van het betreffende veld PRODUCT_DESCRIPTION is er de mogelijkheid om aan te geven; ‘Display as Text (escape special characters, does not save state)’.

Door het zo aan te passen worden special characters (zoals <, > en &) vervangen zodat deze nog wel worden weergegeven, maar niet door de browser geïnterpreteerd worden. Eventueel ingevoegde HTML-code wordt hierdoor niet uitgevoerd bij het laden van de webpagina. Verder is het aan te raden om de invoer van de gegevens altijd te controleren of de inhoud overeenkomt met wat wordt verwacht. Zo kan in bovengenoemde situatie worden gesteld dat de verwachte invoer in het veld ‘Product Description’ alfanumeriek dient te zijn. In Application Express kan hiervoor eenvoudig de volgende validatie op het item worden toegevoegd:

Hiermee wordt de invoer van special characters voorkomen:

Sample Application

Met een aantal relatief simpele aanpassingen kan het risico van XSS in een Oracle ApEx applicatie dus worden voorkomen. Op basis van dit concept kunnen op andere platformen vergelijkbare aanpassingen gemaakt worden.

Naast XSS zijn er nog vele andere beveiligingsproblemen die getackeld moeten worden. In een volgend artikel zullen we hier verder op ingaan.

Over de auteurs: Marinus Kuivenhoven en Simon Boorsma zijn beiden werkzaam bij Sogeti Nederland B.V. als Oracle en Security consultants.

Lees meer over Sogeti Nederland B.V.

Ga terug naar We Love IT uitgave 2 - 2009

Advertentie