thesis tue 2005

1

The forgotten backdoor

De beveiliging van webapplicaties

Thesis door : Perry Mertens Begeleider : Adri de Bruin RA. RE. Datum : februari 2005

2

Inhoudsopgave

VOORWOORD. .......................................................................................................................4

1 INLEIDING. .....................................................................................................................5

1.1 Probleemstelling. ....................................................................................................5 1.2 Leeswijzer...............................................................................................................5

2 WEBSERVICES EN WEBAPPLICATIES...................................................................7

2.1 Definitie van webservice. .......................................................................................7 2.2 De definitie van webapplicaties..............................................................................7 2.3 Welke mogelijkheden biedt een webapplicatie?.....................................................8 2.4 Het verschil tussen webservices en webapplicaties................................................8 2.5 Webapplicatie architecturen. ..................................................................................9 2.6 Tier-lagen .............................................................................................................11 2.7 Middleware...........................................................................................................12

3 WELKE BEDREIGINGEN EN MAATREGELEN ZIJN ER RONDOM WEBAPPLICATIES..............................................................................................................14

3.1 De bedreiging code injection................................................................................15 3.1.1 De bedreiging Cross-site scripting. ......................................................................17 3.1.1.1 De maatregelen ter voorkoming van cross-site scripting. ....................................18 3.1.1.2 De risico classificatie van cross-site scripting. .....................................................21 3.1.2 De bedreiging SQL-injection................................................................................23 3.1.2.1 Maatregelen ter voorkoming SQL-injection.........................................................26 3.1.2.2 De risico classificatie van SQL-injection. ............................................................28 3.1.3 De bedreiging parameter manipulatie...................................................................30 3.1.3.1 Maatregelen tegen parameter manipulatie............................................................30 3.1.3.2 De risico classificatie van parameter manipulatie. ...............................................31 3.2 De bedreiging session Hi-jacking.........................................................................33 3.2.1 Maatregelen tegen session hi-jacking...................................................................33 3.2.1.1 De risico classificatie session hi-jacking. .............................................................35 3.3 De bedreiging identity spoofing. ..........................................................................37 3.3.1 De maatregelen tegen identity spoofing. ..............................................................38 3.3.2 De risico classificatie identity spoofing................................................................41 3.4 De bedreiging Information disclosure en applicatieve Denial of Service attack..44 3.4.1 Maatregelen tegen Information disclosure en applicatieve Denial of Service

attack. (D.O.S.) .....................................................................................................44 3.4.2 De risico classificatie Information disclosure en applicatieve Denial of Service.48

4 POSITIONERING SECURITY MANAGEMENT.....................................................50

4.1 Wat zijn de knelpunten. ........................................................................................50 4.2 Invoeren en borging in de organisatie. .................................................................51 4.3 Security awareness. ..............................................................................................53

3

4.4 De tooling. ............................................................................................................53 4.5 Tot slot..................................................................................................................54

5 SAMENVATTING EN CONCLUSIE..........................................................................55

REFERENTIES ......................................................................................................................57

BEGRIPPENLIJST................................................................................................................61

BIJLAGE 1 .............................................................................................................................62

BIJLAGE 2. ............................................................................................................................63

5

1 INLEIDING. Bij het uitvoeren van een audit of een securityscan wordt onder andere gecontroleerd op de beveiliging en op de getroffen maatregelen van de IT-infrastructuur. Hierbij kwamen de onderstaande bevindingen steeds terug bij de beveiliging van webapplicaties.

o Door druk van commercie worden bij organisaties amper reviews uitgevoerd op de geïmplementeerde beveiligingsmaatregelen in een webapplicatie. Daardoor neemt de kans toe op onveilige webapplicaties die niet bestand zijn tegen actuele bedreigingen.

o De verantwoordelijkheid voor security management is niet belegd waardoor gedurende het ontwikkelingstraject niet gewaakt wordt over de implementatie van de juiste maatregelen van de beveiliging van webapplicaties.

o Bij veel organisaties wordt geen specifieke kennis van actuele bedreigingen van webapplicaties geborgd. Bij medewerkers in een ontwikkelorganisatie wordt onvoldoende aandacht besteed aan specifieke bedreigingen van webapplicaties.

Tijdens het uitvoeren van de audits blijkt dat er, bij de ontwikkeling van webapplicaties, weinig aandacht is voor de beveiliging. Middels deze thesis wordt de aandacht gevestigd op de bedreigingen en de daaruit voortvloeïende maatregelen die nodig zijn om een veilige en robuuste webapplicatie te ontwikkelen.

1.1 Probleemstelling. In dit onderzoek zal het onderschatte probleem van exploitatie van zwakheden in webapplicatie programmering aan het licht gebracht worden. Hiertoe is onderzocht wat de bedreigingen van webapplicaties zijn. Daarnaast wordt aangeven welke maatregelen getroffen dienen te worden om de veiligheid van de webapplicatie te waarborgen. Kernvragen die in deze thesis worden beantwoord, zijn:

1. Welke bedreigingen zijn er op het gebied van webapplicaties? 2. Welke technische beveiligingsmaatregelen kan men treffen om deze bedreigingen te

minimaliseren en te beheersen? 3. Hoe hoog zijn de risico’s indien maatregelen ontbreken? 4. Welke rol kunnen en moeten de ontwikkelafdeling, de security manager en de IT-

auditor spelen bij het beveiligen van webapplicaties?

Begrenzing van het onderzoek De thesis is begrensd tot webapplicaties en enkele organisatorische en procedurele maatregelen. Het beoordelen van diepgaande organisatorische en procedurele maatregelen alsmede “hardening” van servers en webservers valt buiten de scope van deze thesis.

1.2 Leeswijzer. In hoofdstuk één komt de probleemstelling aan de orde, hierin wordt tevens de begrenzing van deze thesis aangegeven. Hoofdstuk twee geeft uitleg over webservice, webapplicaties en webarchitecturen. In hoofdstuk drie wordt ingegaan op de bedreigingen (kernvraag 1) en maatregelen (kernvraag 2) die getroffen kunnen worden. De risico’s die ontstaan indien bepaalde maatregelen ontbreken zullen weergegeven worden in diverse matrices. (kernvraag 3)

6

Vervolgens beschrijft hoofdstuk vier over de positionering van security management en hoe de beveiliging van webapplicaties verbeterd kan worden. (kernvraag 4) Tenslotte volgt in hoofdstuk vijf de conclusie.

7

2 WEBSERVICES EN WEBAPPLICATIES. Webservices zijn bedoeld voor de communicatie tussen bedrijven en klanten en voor organisaties intern. De communicatie tussen organisaties en klanten kan sterk verbeteren door middel van webservices, omdat webservices de samenwerking verzorgen in een heterogene omgeving. Doordat verschillende gedistribueerde systemen kunnen draaien op een grote variëteit aan software platforms en architecturen, wordt de integratie tussen klant en bedrijf efficiënter en daardoor goedkoper.

Met behulp van webservices kunnen verschillende bedrijfsdiensten aan elkaar gekoppeld worden en kunnen organisaties gebruik maken van de voordelen van het World-Wide-Web. (WWW)

2.1 Definitie van webservice. Een webservice kan gezien worden als een verzameling van functies die zijn gebundeld in een enkele entiteit. Door deze entiteit als een service op een netwerk aan te bieden kunnen meerdere applicaties gebruik maken van deze functies. Deze applicaties kunnen bestaan op het intranet, extranet of het internet. [Philippe Michiels] Webservices bieden business logic, data op het netwerk aan. Deze zijn beschikbaar door middel van een programmeerbare interface. Hierbij moet worden gedacht aan onderstaande modellen (Deze modellen zijn verder uitgelegd in paragraaf 2.7):

o Extended Mark-up Language (XML). o Simple Object Access Protocol (SOAP). o De Web Services Description Language (WSDL). o Universal Description, Discovery and Integration (UDDI).

Webservices worden, onder andere, gebruikt voor Business to Business (B2B), Business to consumer (B2C), intern en E-commerce gebruik. Door het gebruik van webservices die communiceren op één van de boven beschreven manieren, zal de communicatie ingrijpend verbeteren. Het voordeel van deze webservices is dat er gebruik wordt gemaakt van de interface van de webbrowser. Doordat er gebruik wordt gemaakt van de webbrowser als frontend zullen de kosten voor deze client beduidend lager zijn. Door middel van webservices kunnen verschillende bedrijven onderling aan elkaar gekoppeld worden en gebruik maken van de voordelen van het World-Wide-Web. (WWW) Een bank kan bijvoorbeeld gebruik maken van webservers voor het aanbieden van zijn producten via de publieke website. Het aanbieden van zijn diensten via een webbrowser is mogelijk door middel van webapplicaties. Dit zijn applicaties die gebruikt worden over een netwerk zoals het internet. Er zijn wel enige voorwaarden waaraan een applicatie dient te voldoen voordat er over een webapplicatie mag worden gesproken.

2.2 De definitie van webapplicaties. In de bestaande literatuur zijn er diverse definities van het begrip “webapplicatie” gevonden die onderling verschillen. Ter wille van de duidelijkheid is voor deze thesis de onderstaande definitie geformuleerd:

8

Een webapplicatie is een toepassing waarbij communicatie plaats vindt op basis van het HTTP protocol. Een webapplicatie is toegankelijk via een webserver en kan door meerdere gebruikers gelijktijdig worden aangesproken doormiddel van een webbrowser.

2.3 Welke mogelijkheden biedt een webapplicatie? Met behulp van webapplicaties kan informatie naar een grote groep mensen uitgedragen worden. Dit is mogelijk doordat de applicaties alleen op de webservers geïnstalleerd kunnen worden en er afgezien van een webbrowser geen extra clientsoftware nodig is. Verder zijn webapplicaties vanwege de minimale beheersen installatiekosten per gebruiker ook hét middel voor het inwinnen van gegevens van een grote groep gebruikers. Webapplicaties zijn bovendien ideaal als de gebruiker vanaf verschillende locaties zijn informatie wil benaderen en gegevens wil invoeren. Bij gebruik van applicaties in een intranet-omgeving bereikt men eenvoudig alle medewerkers in de organisatie. Bij gebruik van internet hebben medewerkers de beschikking over de applicaties zowel thuis als op reis. Om er voor te zorgen dat de juiste informatie op de juiste plek aankomt, wordt in paragraaf 2.5 beknopt uitleg gegeven over webapplicatie architecturen.

2.4 Het verschil tussen webservices en webapplicaties. De termen webservices en webapplicaties worden vaak door elkaar gehaald zonder dat men zich hiervan bewust is. (zie figuur 1) Middels een voorbeeld zal het verschil aangeduid worden tussen de twee termen.

Figuur 1 In de praktijk blijkt dat webservices en webapplicaties vaak niet los te zien zijn. Het bekijken van het saldo van een bankrekening is een onderdeel van een webservice.

9

Een webservice vervult altijd de backoffice functie terwijl de webapplicatie de GUI verzorgt naar de eindgebruiker. Het saldo, dat de eindgebruiker op zijn scherm te zien krijgt, is een onderdeel van een webapplicatie. De service die er voor zorg draagt dat de juiste gegevens van het saldo op het scherm verschijnt, is een webservice. De webservice verzorgt de communicatie naar de backoffice systemen. De volgende paragraaf zal gaan over de webapplicatie architecturen.

2.5 Webapplicatie architecturen. Typologie De Gartner Group [Gartner Group] heeft de afgelopen jaren een duidelijke visie ontwikkeld op het gebied van webapplicatie architecturen. Hun uitgangspunt is dat traditionele gegevensverwerkende toepassingen meestal een gelaagde structuur vertonen, waarbij drie lagen instaan voor respectievelijk de volgende functies:

o Presentatie. (constructie beheer van de gebruikersinterface) o Logica, ook wel business logic of bedrijfsregellaag genoemd. (bewerkingen

en controles op gegevens) o Data. (opslag en beheer van persistente gegevens)

Figuur 2 geeft hiervan een voorstelling.

Figuur 2

De eerste webapplicaties bestonden uit een 1 tier architectuur. Dit werd later uitgebreid met een 2- en 3-tier architectuur. Hieronder volgt een beknopte uitleg. 1-tier Een webapplicatie gebouwd volgens een 1-tier architectuur bevat alle componenten van het functionele 3-lagenmodel in één module. 2-tier In een webapplicatie gebouwd volgens een 2-tier architectuur is het database management system (DBMS) en/of de datalaag gescheiden van de overige lagen van het functionele 3-lagenmodel. Het DBMS bevindt zich op de server in een aparte applicatie. Gebruikt men bijvoorbeeld Microsoft SQL-Server (een DBMS) dan spreekt men van een 2-tier applicatie. In een 2-tier architectuur worden door Gartner twee varianten onderkend: De fat client en de plump client. [zie: Systems Software Architectures Scenario, Gartner Group, 29 oktober 1997] In een fat client architectuur bevindt zich alleen het Database management system (DBMS) op de server.

10

In een plump client architectuur wordt het DBMS aangevuld met stored procedures. In het algemeen wordt er door bedrijven niet gekozen voor stored procedures omdat daardoor ontwikkelaars gebonden zijn aan één merk database. Bij de huidige databases wordt de data benaderd door middleware producten zoals websphere. Er zijn veel tegenstrijdigheden geconstateerd op het gebied van stored procedures. De volgende personen hebben dit uitstekend verwoord:

One drawback of stored procedures is that they provide less ad hoc flexibility than remote dynamic SQL. In addition, stored procedures may perform very poorly if their plans are not refreshed (rebound) to take advantage of the optimizer statistics - dynamic SQL creates a fresh plan with every execution. Another drawback is that there is no transactional synchronization – that is, two- phase commit – between stored procedures; each stored procedure is a separate transaction. Another problem is that stored procedures are slow – especially when compared to a compiled language. Also, many databases recompile their stored procedures every time they are invoked or whenever they get swapped out of memory. However, the main drawback of stored procedures is that they’re totally non- standard. This results in a number of problems. No two vendor implementations are alike. The language for describing the stored procedures and their functionality varies from server to server; stored procedures are not portable across vendor platforms. There is no standard way to pass or describe the parameters. It is difficult for database tools to create and manage stored procedures. Dealing with the parameters is very messy (there is no standard interface definition language or stub compiler tool). [Client/Server Survival Guide, tird edition Robert Orfali, Dan Harkey, Jeri Edwards]

3-tier In een 3-tier architectuur zijn de interface, de logische/datalaag en het DBMS op verschillende lagen geïmplementeerd. Deze architectuur wordt ook wel een thin client architectuur genoemd. In het onderstaande figuur 3 zijn de drie verschillende architecturen nog eens weergegeven. Elk donkergrijs blokje stelt een “tier” voor. Er is hierbij bovendien onderscheid gemaakt tussen een 2-tier architectuur fat client en 2-tier architectuur plump client. Elk wit blokje stelt een laag uit het functionele 3-lagenmodel voor.

Figuur 3

11

Voordelen van een meer lagen-architectuur. De voordelen van een meer lagen-architectuur wordt verkregen door:

1. Herbruikbaarheid van de componenten. 2. Flexibiliteit bij de ontwikkeling van één van de tier webapplicaties. 3. Eenvoudige vervangbaarheid door de meer lagenarchitectuur. 4. Beheersbaarheid doordat bijvoorbeeld de logica of het DBMS op één centrale

plek beschikbaar zijn.

Ad 1. Herbruikbaarheid. Componenten kunnen zonder overtollige ballast hergebruikt worden. Als men bijvoorbeeld een rekenregel wil hergebruiken is het in een 3-tier applicatie niet nodig om dit via de interfacelaag te doen. Een applicatie of een webapplicatie kan dan rechtstreeks de rekenregel aanroepen. Ad 2. Flexibiliteit. Bij de ontwikkeling van één van de tier webapplicaties kan per laag worden bekeken op welke wijze de laag het beste geïmplementeerd kan worden. Zo kan men beslissen om het DBMS op Mainframe in bijvoorbeeld DB2 (een product van IBM) te implementeren, de rekenregels op een Unix omgeving en de presentatie op Windows of Linux omgeving door middel van een webbrowser. Bij een 1-tier applicatie draait alles op hetzelfde platform. Wil men dus van platform veranderen dan moet dit gedaan worden voor de hele webapplicatie. Ad 3. Vervangbaarheid. In een meer lagenarchitectuur is het mogelijk om een bepaalde laag op eenvoudige wijze te vervangen. Eenvoudig is hier een relatief begrip omdat uit de praktijk blijkt dat het vervangen van een laag niet altijd zonder slag of stoot gaat. Feit is wel dat het vervangen van bijvoorbeeld een database in een 1-tier applicatie veel complexer is dan in een 2-tier of 3-tier applicatie. Ad 4. Beheersbaarheid. Wanneer de logica of de bedrijfsregels en/of het DBMS op één centrale plek staan is het veel eenvoudiger om het geheel te beheren.

2.6 De tier-lagen 1-tier versus 2-tier. Tegenwoordig is het met de meeste moderne tools zoals C ++, Java, Visual Java en Visual Basic geen enkel probleem meer om een 2-tier applicatie te bouwen. Omdat het vaak moeilijker is om een 1-tier webapplicatie te bouwen, verdient het de voorkeur om minimaal een 2-tier applicatie te bouwen. 2-tier versus 3-tier. Over de keuze tussen een 2-tier en een 3-tier architectuur zegt Gartner het volgende:

“Developers must consider the nature of each application and choose between two-tier and three-tier designs on a case-by-case basis. For small, routine applications, a two-tier approach is still faster, simpler and less expensive. For complex and/or large applications, a three-tier design costs less to develop, maintain and administer.” [www.gatner.com]

[Gartner Group]

12

Een drie lagen-architectuur doet zich onder meer voor wanneer een webserver een externe database raadpleegt om dynamische webpagina’s op te bouwen. Om de communicatie te verzorgen tussen de componenten, tiers en de backoffice dienen we gebruik te maken van middleware.

2.7 Middleware. Hoe wisselen twee computers informatie uit? Naast een fysieke verbindingslijn en een communicatieprotocol dienen ook de verschillen tussen types, merken en versies overbrugd te worden. Daarvoor is de systeemsoftware “middleware” benodigd. Microsoft ziet Middleware als de ‘next generation’-internet. Zie het als componenten via het web of beter: componenten beschikbaar gesteld door middel van internettechnologie. Componenten zullen in dit programma- model hun services aanbieden via open internetstandaarden waarin o.a. HTTP [RFC 1945,2616], XML[RFC2376] en SOAP [W3C] een belangrijke rol spelen. Een voorbeeld: stel iemand wil een verzekering afsluiten via de Wellowell. De persoon gaat naar de website van Wellowell (http://www.wellowell.nl ) en zal in eerste instantie diverse verzekeringen met elkaar willen vergelijken. De bezoeker vult een aantal webpagina’s in om zijn wensen kenbaar te maken en drukt vervolgens op de ‘vergelijken’-button. Middleware maakt hier een verzoek van. Dit verzoek komt binnen op de website van Wellowell die vervolgens de decentrale software van de verzekeringsmaatschappijen aanroept om een offerte te kunnen aanbieden. In het voorbeeld van Wellowell betekent dit dat de software van de verzekeringsmaatschappijen niet bij Wellowell staat maar bij de maatschappijen zelf. Om de communicatie tussen de verzekeringsmaatschappijen te realiseren wordt een standaard wijze van aanbieden en presenteren van gegevens afgesproken. Er wordt gebruik gemaakt van onderstaande standaard internet middleware:

1. Extended Mark-up Language XML. 2. Simple Object Access Protocol SOAP. 3. De Web Services Description Language WSDL. 4. Universal Description, Discovery and Integration UDDI.

Ad 1. Extended Mark-up Language XML. De Extended Mark-up Language (XML) is de manier om gegevens op een generieke en flexibele manier te representeren. Door een universele gegevensindeling aan te bieden is het mogelijk om gegevens op eenvoudige wijze aan te passen of om te zetten in andere vormen. Op XML gebaseerde standaarden, waaronder SOAP en UDDI, vormen samen de open methodologie voor communicatie tussen webapplicaties. [W3C] Ad 2. Simple Object Access Protocol SOAP. Het Simple Object Access Protocol (SOAP) is het protocol om gegevens met elkaar uit te wisselen. Een belangrijk deel van de Soapspecificaties bestaat uit een verzameling regels over hoe men gegevens, in XML-formaat, kan gebruiken. Het beschrijft hoe een bericht moet worden vorm gegeven (de zogenaamde envelop), hoe men met behulp van SOAP een zogenaamde remote procedure call (RPC) kan doen en hoe SOAP kan worden getransporteerd over HTTP. Daarnaast kan SOAP ook over andere transportprotocollen worden gebruikt. Denk aan FTP, e-mail en MQ-Series van IBM. [W3C]

13

Ad 3. De Web Services Description Language WSDL. De Web Services Description Language (WSDL) is een standaard wijze om de services van een component te beschrijven. WSDL is gebaseerd op XML en is door Microsoft in samenwerking met IBM ontwikkeld. Met WSDL kan worden beschreven welke berichten een webservice accepteert en welke het genereert. Een soort contract dus. Deze standaard manier maakt het mogelijk voor ontwikkelaars om online de services van een component te raadplegen en te interpreteren. [W3C] Ad 4. Universal Description, Discovery and Integration UDDI. Met UDDI (Universal Description, Discovery and Integration) heeft men voor providers een mechanisme opgezet om hun webservices op een generieke manier te adverteren. Een soort Gouden Gids dus, ook wel de UDDI registry genoemd. [W3C] In de gids is een aantal verschillende soorten informatie opgenomen. De gids is onderverdeeld in witte, gele en groene pagina’s. Op de witte pagina’s wordt de organisatie beschreven; onder andere het adres, een contact (persoon) en een tekstuele toelichting van de organisatie. De gele pagina’s bevatten een categorisering van organisaties van drie type indelingen: industriële standaardcodering opgesteld door de US government [NAICS]; producten service-indeling volgens de United Nations/SPSC en een geografische taxonomie. Dit maakt het mogelijk om vanuit verschillende dimensies door de Gouden Gids te bladeren. Tenslotte zijn er de groene pagina’s. Deze bevatten alle informatie over de diensten die aangeboden worden en hoe deze aangeroepen kunnen worden. In een sterk vereenvoudigde vorm is de UDDI business registry dus niets anders dan een overzicht van diensten met de technische specificaties hoe de diensten (webservices) gebruikt kunnen worden.

Figuur 4

De beschreven middleware (zie figuur 4) hebben voornamelijk betrekking op de webservices. De webservice verzorgt de communicatie tussen de webapplicatie en de backends. In dit hoofdstuk is beschreven welke middleware en protocollen hiervoor gebruikt worden. Een webserver die gebruik maakt van dynamische data kan niet zonder webservices. De zwakke plekken zijn dan ook de webapplicaties die communiceren door middel van middleware naar de backoffice. De kwetsbaarheden op het gebied van webapplicaties worden nader uitgewerkt in het volgende hoofdstuk.

14

3 WELKE BEDREIGINGEN EN MAATREGELEN ZIJN ER RONDOM WEBAPPLICATIES.

Door het gebruik van scantools zoals Nessus, ISS Internet security scanner en andere commerciële en opensource tools wordt de indruk gewekt dat een webapplicatie veilig is. Dit komt doordat deze tools geen kwetsbaarheden constateren op het gebied van webapplicaties omdat zij voornamelijk naar infrastructurele componenten en geregistreerde kwetsbaarheden zoeken.[ zie voor bekende kwetsbaarheden www.cert.org] Waarom de stelling dat webapplicaties niet veilig zijn? Een webapplicatie kan kwetsbaar zijn omdat deze steunt op de integriteit van de omgeving waarbinnen de webapplicatie draait. Indien in deze omgeving en de onderliggende lagen, zoals het netwerk en het besturingssysteem, zwakheden bestaan, zal de webapplicatie en de achtergelegen data risico lopen. Veel webapplicatie hacks slagen omdat binnen het besturingssysteem onvoldoende controles worden uitgevoerd op de wijze waarop webapplicaties worden aangeroepen of geïmplementeerd. Een aanval op het niveau van de webapplicatie zal dus zijn gericht op de specifieke functionaliteit van de webapplicatie en is steeds uniek. Eén van de meest onderschatte bedreigingen van webapplicaties is dat kwaadwillige invoer binnen HTTP-verzoeken verwerkt kan worden. Het doel is om toepassingen te dwingen tot het uitvoeren van onbevoegde handelingen of zijn normale verrichting te onderbreken. Daarom is de grondige invoer controle een essentiële tegenmaatregel tegen de vele aanvallen en behoort tot de hoogste prioriteit bij het ontwikkelen van webapplicaties. Belangrijk is dat security management geen vast onderdeel is van het ontwikkelproces. Een bedreiging kan ontstaan als ontwikkelaars geen code review doen en er tijdens de oplevering van een webapplicatie een uitgebreide security assessment ontbreekt. De bovengenoemde tools zijn niet afdoende. Daarnaast worden programmeurs vaak niet geleerd om veilig te programmeren. De bedreigingen die zich dan voordoen worden nagenoeg niet opgemerkt. Dit kan echter een groot financieel gewin opleveren voor kwaadwillende. Voor een e–commerce omgeving kan dit een financieel risico en een image probleem tot gevolg hebben. Het komt vaak voor dat door webapplicatie zwakheden, een kwaadwillende persoon misbruik maakt van bijvoorbeeld andermans creditcard gegevens. Een bijkomend probleem kan zijn dat een persoon de identiteit van een ander kan aannemen en daarmee toegang heeft tot vertrouwelijke gegevens. De hieronder beschreven onderdelen in figuur 5 behoren tot de meest onderschatte bedreigingen bij het ontwikkelen van webapplicaties. Bij de ontwikkeling van webapplicaties dient er door de programmeur, acceptant, auditor of de security manager gecontroleerd te worden op maatregelen tegen de volgende aanval technieken [SANS, Microsoft en OWASP ]:

De bedreigingen van webapplicaties. 1. Code injection. Onder code injection valt het volgende:

a. Cross-Site Scripting. b. SQL-injection. c. Parameter manipulatie.

2. Session hi-jacking. 3. Identity spoofing. 4. Information disclosure en Denial of Service.

15

Tegen deze bedreigingen zijn diverse maatregelen te treffen. Deze maatregelen zijn in dit hoofdstuk per bedreiging beschreven en vormen tezamen een raamwerk om een veilige webapplicatie te ontwikkelen. Vooralsnog is een 100% veilige webapplicatie een fictie. Door deze maatregelen worden de risico’s geminimaliseerd. Daarnaast zal rekening gehouden moeten worden met het feit van menselijke fouten in hard- en software.

Figuur 5

In dit hoofdstuk is verder per bedreiging opgenomen welke risico’s een organisatie loopt indien de beschreven maatregelen niet of onvoldoende worden getroffen. Dit is gedaan per maatregel. Hierbij is een onderscheid gemaakt tussen een niet vertrouwelijke en niet financiële webapplicatie enerzijds en een vertrouwelijke en financiële webapplicatie anderzijds. Dit onderscheid wordt gemaakt omdat de hoogte van het risico tevens wordt beïnvloed door de soort webapplicatie, zijnde niet financieel versus financieel of niet vertrouwelijk versus vertrouwelijk. Hierbij wordt gebruik gemaakt van de risico classificaties low, medium, high. Voor de interpretatie van de risico classificaties zie bijlage 2.

3.1 De bedreiging code injection. Code injection komt voor wanneer een kwaadwillend persoon een willekeurige code kan aanmaken om de veiligheidscontext van een webapplicatie te ontwijken. Door deze attacks kan informatie verkregen worden en data gemanipuleerd waardoor de integriteit en de continuïteit van een webapplicatie in gevaar kan komen. Er zijn diverse soorten aanvallen op het gebied van code injection . [Mark Burnett]

16

De volgende aanvallen vallen onder code injection :

a. Cross-site scripting. b. SQL-injection. c. Parameter manipulatie.

Het gevaar code injection in combinatie met phishing is een onderschat probleem. De schade voor bedrijven wereldwijd loopt tot in de miljarden [www.msnbc.msn.com/id/5184077/] en dit zal de komende jaren nog meer oplopen. De hieronder beschreven alinea geeft een indruk wat de impact kan zijn van slechte webapplicaties in combinatie met code injection en phishing.

Survey: 2 million bank accounts robbed Criminals taking advantage of online banking, Gartner says EXCLUSIVE By Bob Sullivan Technology correspondent MSNBC Updated: 4:25 a.m. ET June 14, 2004 Nearly 2 million Americans have had their checking accounts raided by criminals in the past 12 months, according to a soon-to-be released survey by market research group Gartner. Consumers reported an average loss per incident of $1,200, pushing total losses higher than $2 billion for the year. problem. "There has been a big increase in the abuse of existing checking accounts," Litan said. "What's really scary about it is right now there are no back-end fraud detection solutions for it." The survey results, extrapolated from a telephone poll of 5,000 consumers conducted in April, offer a rare glimpse at the state of bank fraud: Financial institutions are tight-lipped about fraud losses. But Litan said the study confirms comments she regularly hears from bank investigators. "The results are consistent with what banks are telling me.When I talk to them, they all nod their heads that this is the area where they are seeing the most fraud escalation," she said. 'Constant siege' The trend neatly follows a sharp rise in so-called phishing e-mails, which attempt to steal consumers' user names and passwords by imitating e-mail from legitimate financial institutions. A Gartner study released in May showed at least 1.8 million consumers had been tricked into divulging personal information in phishing attacks, most within the past year. Phishing attempts designed specifically to steal bank information began to skyrocket about 10 months ago, according to Dave Jevans, chair of the Anti-Phishing Working Group. Overall, phishing e-mails have jumped 4,000 percent in the past six months, and just last month, Citibank overtook eBay as the most common target. The company faced an average of 16 attacks per day, and 475 separate phishing attacks during April, an increase of nearly 400 percent from March. Citibank didn't immediately return requests for comment. "It's working, there's no doubt about that.There's people who are under constant siege now," Jevans said. "It's like people setting up fake ATMs everywhere." Some days, banks are targeted dozens of times, which not only leads to identity theft, but also jam-packed customer service telephone lines. "Clearly the issues are far more significant than anyone expected they would be. Phishing and spoofing (setting up look-alike bank Web( sites true cross site scripting) are really getting to people," said Larry Ponemon, founder of privacy think tank Ponemon Institute, and a bank consultant. "It is an epidemic. It's a very big problem." Meer informatie http://www.msnbc.msn.com/id/5184077/

17

Uit bronnen van WebCohort [Webcohort] Lab bleek dat 92% van de webapplicaties kwetsbaar zijn voor de hieronder beschreven problemen. Van de onderzochte webapplicaties zijn de volgende percentages gepubliceerd:

o Cross-site scripting: 80%. o SQL-injection: 62% o Parameter manupulatie: 60% o Cookie poisoning: 37%. o Database Server: 33%. o Web Server: 23% o Bufferoverflow: 19%.

Het onderzoek van webCohort geeft duidelijk weer wat voor bedreigingen er zijn op het gebied van webapplicaties. Bij Microsoft was het mogelijk om creditcardnummers te achterhalen. De aanvaller gebruikte hiervoor een lek gebaseerd op 'cross-site scripting'. Hiermee was het mogelijk om een voet tussen de deur te krijgen bij een verbinding die een gebruiker opzet met de passport dienst van Microsoft. Op het moment dat iemand zich bij Microsoft aanmeldt, komt het script van Slemko (de maker van deze bug) in werking. In de paar minuten na de aanmelding is de dienst kwetsbaar en is de persoonlijke informatie in principe voor hackers toegankelijk. Microsoft stelt in een reactie dat er geen bewijs is dat er daadwerkelijk persoonlijke informatie is achterhaald. Het product passport van Microsoft wordt door 165 miljoen internetters gebruikt. Hiervan hebben zo'n 2 miljoen mensen een elektronische portemonnee [Slemko] In de paragraaf 3.1 wordt code injection en de daarbij behorende maatregelen verder uitgewerkt. In paragraaf 3.2, 3.3 en 3.4 wordt Session hi-jacking, Identity spoofing en Information disclosure en Denial of Service uitgewerkt. 3.1.1 De bedreiging Cross-site scripting. Cross-site scripting (XSS) is een manier die een kwaadwillende kan gebruiken om een scriptcode in te brengen in een webapplicatie vanaf een webbrowser. Dit is alleen mogelijk indien de webapplicatie niet controleert op invoeren uitvoer validatie. Webpagina's bevatten tekst en HTML-codes. Deze worden gepubliceerd door een webapplicatie en deze stuurt de HTML-codes door naar een webbrowser. Webservers die over statische pagina's beschikken, zijn niet vatbaar voor XSS doordat de manier van afhandelen al van tevoren is gedefinieerd. Webapplicaties die dynamische pagina's aanmaken, hebben echter geen controle over de manier waarop de webbrowser de uitvoer afhandelt. Als er door een kwaadwillende een scriptcode wordt toegevoegd aan een dynamische pagina dan beschikt de webapplicatie en de webbrowser niet over voldoende informatie om dit vast te stellen en om de benodigde beveiligingsmaatregelen te treffen. De XSS aanvallen doen zich voor door een kwetsbaarheid in de webpagina aan de client-side bijvoorbeeld een “javascript” in te brengen. Dit script wordt teruggezonden door een niets vermoedende gebruiker waardoor de script wordt uitgevoerd door de webbrowser. Doordat de webbrowser het script van een vertrouwde website ontvangt, heeft de webbrowser geen manier om te controleren of het script “echt” is. Door XSS kan de beveiliginginstellingen van webbrowsers en webapplicatie worden omzeild. De aanvallen gebaseerd op XSS werken ook over Secure Socket Layer (SSL) verbindingen. Één van de ernstigste aanvallen die kan plaats vinden is wanneer een aanvaller een script schrijft om het authenticatiecookie van een andere persoon te bemachtigen.

18

Door in het bezit te komen van het authenticatiecookie kan een persoon iemands identiteit aannemen. Dit stelt de aanvaller in staat om de identiteit van de andere persoon te “spoofen” en als “legitieme gebruiker” aan te loggen op het betreffende systeem. Om het gevaar XSS te minimaliseren is het belangrijk dat de volgende maatregelen worden toegepast om de bedreiging XSS te minimaliseren.

3.1.1.1 De maatregelen ter voorkoming van cross-site scripting. De volgende maatregelen dienen standaard opgenomen te worden om XSS te voorkomen:

1. Valideer alle (data)invoer en (data)uitvoer van een webapplicatie die zijn ontvangen van de “boze buitenwereld”.

2. Controleer de tekst-uitvoer voor een webpagina middels HTML-encoding. 3. Maak gebruik van de correcte character encoding bij een webpagina. 4. Maak geen gebruik van een frame bij een inlog pagina. 5. Controleer altijd op de invoeren uitvoer van vermomde HTML karakters en

escapetekens 6. Installeer een webfilter zoals Microsoft IIS URLScan en pas in Apache het

httpd.conf aan webserver en filter volgende parameters “”& < > ‘’% %% ^ | union

Hieronder volgt een uitwerking van de hierboven beschreven maatregelen. De optie webfilter is niet verder uitgewerkt. Dit hoort een standaard onderdeel te zijn van server hardening. (webfilter) Ad 1. Valideer alle invoer en uitvoer van een webapplicatie die zijn ontvangen van de “boze buitenwereld”. Bij webapplicaties is het van belang dat alle invoer en uitvoer velden dienen te worden gecontroleerd op in- en uitvoer validatie. Vertrouw nooit de ontvangen invoer van de “boze buitenwereld”. Valideer alle invoer die is ontvangen van de “boze buitenwereld” op basis van lengte, formaat en reikwijdte van de datavelden. Door het toepassen van in- en uitvoer validatie kunnen kwaadwillende personen deze velden niet meer misbruiken en de combinatie van XSS en phishing wordt op deze manier vele malen bemoeilijkt. Ad 2. Controleer de tekst-uitvoer voor een webpagina middels HTML-encoding. Als een tekstuitvoer voor een webpagina geschreven wordt dient altijd gecontroleerd te worden of de tekst geen speciale karakters HTML-codes bevat zoals <, >, |,~, % en & . Met deze karakters kan een kwaadwillende een script starten op het moment dat een gebruiker de tekst leest. De methode HTML-encoding functie die gebruik kan worden bij programmeertalen zoals Java, ASP, Perl, Python en PHP vervangt deze karakters, die een speciale betekenis in HTML variabelen hebben, naar ongevaarlijk tekst. Hiermee voorkomt men dat tekst uitvoer van webpagina’s kan worden misbruikt. Hieronder een voorbeeld (zie figuur 6) van een webapplicatie zoekmachine die niet aan in- en uitvoer validatie doet. We kunnen vast stellen dat bij de uitvoer geen HTML-encoding wordt toegepast.

19

Figuur 6

Ad 3. Maak gebruik van de correcte character encoding bij een webpagina. Om te weten welke gegevens voor webpagina’s geldig zijn, is het belangrijk om de manieren van “invoer” te beperken. Dat verhindert dat kwaadwillende gebruikers speciale characters gebruiken om de routines van de invoer validatie te ontwijken. Daarom is het van belang dat er wordt gekozen voor een standaard character encoding. Geadviseerd wordt om in Nederland de volgende character encoding ISO-8859-1 te gebruiken. Het is ook mogelijk de standaard character encoding aan te zetten in de webserver configuratie. In de praktijk blijkt dat de standaard character encoding bijna altijd uit staat. Door gebruik te maken van de correcte character encoding kan men geen XSS doen met bijvoorbeeld een Japanse character set. Ad 4. Maak geen gebruik van een frame bij een inlog pagina. Er zijn de laatste tijd veel zwakheden gevonden met betrekking tot frames. De combinatie van XSS en frames maakt het voor een kwaadwillende zeer eenvoudig om een “man in the middele attack” uit te voeren door middel van phishing. De kwaadwillende dient er voor zorgt te dragen dat de gebruiker wordt omgeleid naar de valse website. Deze omleiding kan tot stand komen middels een hyperlink op een webserver of een fake e-mail. Op het moment dat een gebruiker op de betreffende website aan het surfen is, kan hij niet zien dat hij op een fake website is beland. Dit is mogelijk doordat de originele site in de frame zit van de fake-website. In de praktijk komt dit veelvuldig voor en steeds meer gebruikers worden hier het slachtoffer van. Door geen gebruik te maken van frames bij een inlog pagina is het niet meer mogelijk een valse bancaire inlog pagina te spoofen in combinatie met frame spoofing en XSS. Ad 5. Controleer altijd op de in- en uitvoer van vermomde html- karakters en escapetekens. Bij het ontwikkelen van webapplicaties dient een programmeur te controleren op alle mogelijke in- en uitvoer. Hierbij zal ook naar de heximale, decimale en octale in- en uitvoer gekeken moeten worden. Als een programmeur hier geen rekening mee houdt, zullen er de komende jaren weer vele webapplicatie exploits ontstaan. Hieronder volgt een voorbeeld van een code voor server site javascript voor het afvangen van speciale tekens. De volgende tekens zijn als voorbeeld voor een webapplicatie. Op iedere regel staat hetzelfde daarom dient alle invoer en uitvoer te worden gecontroleerd.

20

Hieronder zijn een paar voorbeelden van encoding met de tekst: “<H1>Dit is een test<H1>”

− %3cH1%3eDit+is+een+test%3cH1%3e ( Url encoding) − %U0025%U0033%U0063%U0048%U0031%U0025%U0033%U0065%U0044%U0069%U007

4%U002B%U0069%U0073%U002B%U0065%U0065%U006E%U002B%U0074%U0065%U0073%U0074%U0025%U0033%U0063%U0048%U0031%U0025%U0033%U0065 (latin unicode)

− 60 0 72 0 49 0 62 0 68 0 105 0 116 0 32 0 105 0 115 0 32 0 101 0 101 0 110 0 32 0 116 0 101 0 115 0 116 0 60 0 72 0 49 0 62 0

− 3C48313E4469742069732065656E20746573743C48313E (HEX) − <U1>Qvg vf rra grfg<U1> (Rot13 (ascii)

Hieronder volgt een voorbeeld code voor server side javascript voor het afvangen van speciale tekens. function _encodePM(_sName) { var _sRetStr = ""; for (var i=0; i<_sName.length; i++) { var c = _sName.charCodeAt(i); //spaties, getallen, kleine letters, hoofdletters if (c == 32 || (c >= 48 && c <= 57) || (c >= 65 && c <= 90) || (c >= 97 && c <= 122)) _sRetStr += _sName.charAt(i); else _sRetStr += "&#" + c + ";"; } return (_sRetStr); }

Indien een maatregel ontbreekt, is het dan aannemelijk of er een risico aanwezig is? Het antwoord op deze vraag wordt weergegeven in diverse matrices verderop in dit hoofdstuk.

21

Matrix uitleg. In matrices 1 tot en met 6 wordt weergegeven of het aannemelijk is, dat er een risico aanwezig is, indien een bepaalde maatregel niet wordt nageleefd. Daarbij wordt gebruik gemaakt van de risico classificatie low, medium en high. Er wordt onderscheid gemaakt tussen niet vertrouwelijke en/of niet financiële webapplicaties versus vertrouwelijke en/of financiële webapplicaties. In de linker kolom staat “Crosssite scripting”. Dit heeft betrekking op het ontbreken van “validatie input” als maatregel. De matrix is naar eigen inzicht en ervaring opgezet.

Threat = De bedreiging. Business Impact = De bedreiging dat er financiële of materiele schade ontstaat

voor een organisatie. Vulnerbility = Hoeveel tijd het kost om deze bedreiging uit te buiten. Likelyhood = De kans dat deze bedreiging gebeurt. Company continuity = Bedreiging voor de continuïteit van een organisatie. Company Image = Bedreiging naam reputatie van een organisatie. Changes of destruction = Bedreiging dat er data wordt verwijderd of vernietigd. De gehanteerde “RISK” van de rechter kolom betekent risico aanduiding en is hieronder verder uitgewerkt:

High (hoog) risico Deze risico’s zijn dermate significant dat ze onmiddellijk aandacht behoeven gezien de mogelijke omvang van het risico.

Medium (middel) risico

Deze risico’s behoeven niet de onmiddellijke aandacht, maar de maatregelen dienen tijdig te worden opgevolgd.

Low (laag) risico

Hierbij is sprake van een tekortkoming die geaccepteerd kan worden of die gecompenseerd kan worden door andere maatregelen.

3.1.1.2 De risico classificatie van cross-site scripting. Uit matrix 1a blijkt dat bij websites zonder vertrouwelijke en financiële informatie het gevaar voor cross-site scripting over het algemeen laag is. Daar het te behalen gewin niet of nauwelijks aanwezig is, is ondanks het ontbreken van maatregelen het risico laag. Opvallend is echter dat indien de maatregel “webfilter” ontbreekt het mogelijk is controle te verkrijgen over het onderliggende operating systeem, hierdoor is het risico hoog. Uit matrix 1b blijkt dat bij een webapplicatie waar wel vertrouwelijke of financiële handelingen plaatsvinden door het ontbreken van de maatregelen Ad 1. tot en met Ad 6 de risico’s medium zijn. De medium risico’s verdienen zeker de aandacht, daar deze op langere termijn mogelijk kunnen worden uitgebuit. En daarmee directe schade kunnen geven aan personen en organisaties.

22

Indien de maatregel “webfilter” ontbreekt is het mogelijk controle te verkrijgen over het onderliggende operating systeem, hierdoor is het risico hoog.

Matrix 1a

Matrix 1b

23

3.1.2 De bedreiging SQL-injection. Eén van de meest ernstige aanvallen op webapplicaties heeft tot doel de queries te kapen die door de front-endscripts worden gebruikt en zodoende de controle over de toepassing of de gegevens over te nemen. Dit wordt SQL-injection genoemd. De meeste webtoepassingen zijn voorzien van dynamische inhoud. Hierdoor kan een gestructureerde manier van onderhoud plaatsvinden op de webserver. Deze dynamische manier wordt meestal tot stand gebracht door bijgewerkte gegevens uit een database op te halen. Een van de populairste platforms om webgegevens op te slaan zijn SQL gerelateerde databases. Veel webapplicaties zijn geheel gebaseerd op front-endscripts die simpelweg queries uitvoeren op een SQL database. Deze is op een webserver of op een afzonderlijk back-end systeem gehuisvest. SQL-injection verwijst naar de invoer van SQL queries om in een toepassing een onvoorziene handeling op gang te brengen. Vaak worden bestaande queries bewerkt om hetzelfde resultaat te bereiken. Dynamische SQL kan gemakkelijk worden gemanipuleerd, zelfs door één enkel teken op een bepaalde plek te plaatsen, waarna de hele query kwaadaardig gedrag gaat vertonen. Tot de lettertekens die vaak voor dergelijke invoer validatie aanvallen worden gebruikt, behoren het enkele aanhalingsteken ('), het dubbele streepje (--) en de puntkomma(;) die binnen dynamische SQL allemaal een speciale betekenis hebben. [hacking Exposed] Wat kan een kwaadwillende onder andere met een buitgemaakte SQL-query aanvangen?

o Men kan zich ongeautoriseerd toegang verschaffen tot gegevens. o Men kan via slinkse methoden authenticatie omzeilen en toegang krijgen tot

bijvoorbeeld vertrouwelijke informatie. o Men kan de totale controle verkrijgen over de webservers of het back-end SQL-

systeem. o Men kan fraude plegen door middel van transacties, die direct in de database worden

geplaatst. Blind SQL-injection. Hoewel SQL-injection meestal met de hand wordt gedaan, zijn er niettemin mogelijkheden waarmee de opsporing en uitbuiting van zwakke plekken kan worden geautomatiseerd. Dit is mogelijk doordat “hackers” SQL-error strings bewaren in een signatuurbestand. Deze bestanden en code zijn niet eenvoudig te verkrijgen maar in landen zoals China en Nigeria hebben mensen veel geld over voor de betreffende software. [hacking Exposed] UNION de techniek voor SQL-injection. Een van de belangrijkste technieken bij SQL-injection is de UNION operator. In een database is ook een tabel aanwezig met een lijst van usernames, passwords en id’s staan. Deze lijst kan worden opgevraagd met de volgende query:

SELECT username, password FROM users WHERE id = 1

24

Er bestaat in SQL, de UNION operator, hiermee kunnen queries aan elkaar worden geplakt, mits het aantal kolommen van de beide queries gelijk is en de types van de resultaten paarsgewijs gelijk zijn. (string, int, etc.) De query met de UNION erbij komt er dan als volgt uit te zien:

SELECT naam, beschrijving, prijs FROM producten WHERE id = 12 UNION SELECT username, password, id FROM users WHERE id = 1

Door nu voor de waarde 12 een niet bestaand id te gebruiken wordt de eerste query leeg en bestaat het resultaat alleen uit de tweede query. Dus:

SELECT naam, beschrijving, prijs FROM producten WHERE id = 666666 UNION SELECT username, password, id FROM users WHERE id = 1

Deze query wordt verkregen met behulp van de volgende URL:

http://www.webapplicatie.com/product.php?id={666666 UNION SELECT username, password, id FROM users WHERE id = 1}

Zo kan van een username het wachtwoord worden uitgelezen. Als men van alle users het wachtwoord en de username wil uitlezen, dient men een script te schrijven die de betreffende pagina ophaalt voor alle id's, http://www.evilcoder.org/content/view/92/41/

25

Een ander voorbeeld van SQL-injection: Bij een boekhandel was het mogelijk alle vertrouwelijke gegevens en creditcardnummers te achterhalen. In figuur 7 is het weergegeven door middel van het ‘OR’ commando direct informatie te verkrijgen van de achtergelegen database.

Figuur 7 Doordat er geen invoer validatie wordt toegepast in de webapplicatie in figuur 7 is het mogelijk queries rechtstreeks naar achtergelegen database te versturen. In de praktijk gaat 95 % van de aanvallers om creditcard gegevens. Door gebruik te maken van SQL-injection komt de betreffende webapplicatie eigenaar er vaak niet achter dat zijn vertrouwelijke informatie is misbruikt. [Mcclure] De Authenticatie in een invulformulier omzeilen door gebruik te maken van SQL-injection. Hieronder volgt nog een voorbeeld van het gebruik van SQL-injection bij invulformulieren. Veelal moet een gebruiker zijn (inlog)gegevens invullen op een zogenaamd invulformulier alvorens de beschikking te krijgen over zijn eigen credentials. In onderstaande tabel staat aangegeven op welke wijze het inlogproces in sommige gevallen kan worden omzeild

26

Vorm van authenticatie Gebruikers naam en wachtwoord Authenticatie zonder wachtwoord of gebruikersnaam

Gebruikersnaam: OR '1'='1 Wachtwoord: ' OR '1'='1

Authenticatie met alleen gebruikersnaam Gebruikersnaam: ‘admin’ -

Authenticatie als eerste gebruiker in de tabel

Gebruikersnaam: admin'-

Authenticatie als fictieve gebruiker Gebruikersnaam: union select r, user', passtvd' [http://www.nextgenss.com]

Indien het mogelijk is dat een kwaadwillend persoon SQL-injection gebruikt, dan kan eenvoudig de achterliggende database gemanipuleerd worden. Het is al een keer voorgekomen dat op basis van SQL-injection de jaarcijfers van een beurs genoteerde instantie voortijdig zijn gepubliceerd. (Buhrmann)

3.1.2.1 Maatregelen ter voorkoming SQL-injection. Hieronder volgen maatregelen die gebruikt kunnen worden om SQL-injection te voorkomen:

1. Valideer alle (data)invoer en (data)uitvoer die door een webapplicatie zijn ontvangen van de “boze buitenwereld”.

2. Implementeer de afhandeling van standaardfouten en berichtgeving. Dit omvat tevens een algemene foutmelding van alle fouten.

3. Vergrendel Data Sources Open Database Connectivity (ODBC) en Java Database Connectivity (JDBC) door middel van een machine gebonden user-id en wachtwoorden en schakel berichtgeving aan de clients uit.

4. Maak in een webapplicatie geen gebruik van dynamische SQL commando’s. 5. Gebruik tools zoals Appscan of @stake webproxy voor controle op invoer

validatie afhandeling. (zie hoofdstuk 4)

Hieronder volgt een uitwerking van de hierboven beschreven maatregelen die betrekking hebben op SQL-injection. Ad 1. Valideer alle invoer en uitvoer die door een webapplicatie zijn ontvangen van de “boze buitenwereld” Voor uitwerking zie paragraaf 3.1.1. de bedreiging Cross-site scripting Ad 2. Implementeer de afhandeling van standaardfouten en berichtgeving. Voor uitwerking zie paragraaf 3.4 de bedreiging Information disclosure en applicatieve Denial of Service attack. Ad 3. Vergrendel ODBC en JDBC door middel van machine gebonden user-id en wachtwoorden en schakel berichtgeving aan de clients uit. Het tot stand komen van een verbinding tussen de webapplicatie en middleware vind meestal plaats op basis van een user-id en een wachtwoord. Het is hierbij van belang dat het wachtwoord niet plaintext in source code van een webapplicatie staat vermeld. De connectie tussen de webapplicatie en de middleware dient voorzien te zijn van een station restriction en user restriction. Op het moment dat een hacker aanlogt vanaf het internet met deze user-id dan dient de onderliggende middleware de databaseconnectie te blokkeren.

27

De user-ids die gebruikt worden voor JDBC en ODBC mogen absoluut geen root of admin rechten hebben op het onderliggende operating system. Ad 4. Maak in een webapplicatie geen gebruik van dynamische SQL. In de praktijk zien we veel tegenstrijdigheden op het gebied van security. Microsoft adviseert om SQL-injection te voorkomen door gebruik te maken van Stored procedures of geparametiseerde SQL. Bij het gebruik van webapplicaties waarvan de back-end database (SAP, Peoplesoft) vrij van keuze is, kan alleen van Dynamische SQL gebruik worden gemaakt. De reden hiervoor is dat deze producten “database onafhankelijk” zijn gemaakt. Bij Applicaties die gebruik maken van dynamische SQL dient het ontwerp altijd te zijn gebaseerd op een 3-tier model. Hieronder volgt een nadere uitleg van de drie vormen die een database benaderen op basis van SQL:

1. Dynamische SQL 2. Geparameteriseerd SQL 3. Stored procedures

Ad 1. Dynamische SQL. Dynamische SQL is een eenvoudige manier om een database te benaderen.

Bijvoorbeeld: Select * from Tab Bij het gebruik van dynamische SQL is het van belang dat query altijd vanuit middleware wordt aangestuurd en niet direct vanuit de webapplicatie. Dynamische SQL komt voor bij webgebaseerde applicaties die op meerdere platforms werken. Zoals bijvoorbeeld SAP en Peoplesoft. Nadeel van Dynamische SQL:

o Bij een verkeerd architectuur ontwerp is SQL-injection eenvoudig. Een webapplicatie toont zijn query bijvoorbeeld via een URL “http://www.test.com/”select%20*%20 from%20TAB;”

o Door geen gebruik te maken van middleware werkt het in het algemeen zeer traag.

o Dynamische SQL is zeer kwetsbaar voor SQL-injection, gebruik bij risicovolle webapplicaties geparameteriseerd SQL.

Voordeel van Dynamische SQL:

o Database onafhankelijk. Ad 2. Geparameteriseerd SQL. Geparameteriseerd SQL is een query die een programma zelf in elkaar draait, waarvan de parameters al bij voorbaat vast staan. Door deze query met variabelen door te geven aan de database, middels een prepare statement, kan de database de query wat optimaliseren. Hierdoor is de database beter beveiligd tegen SQL-injection. Nadeel geparameteriseerd SQL:

o Vaak gebouwd voor één type of merk database. Voordeel geparameteriseerd SQL:

o Verhoogt de beveiliging en de performance van een webapplicatie.

28

In geval van geparameteriseerd SQL wordt het SQL statement bij wijze van spreken 5.000 keer uitgevoerd maar slechts één keer geparsed. Voorbeeld:

Select total amount from ps_ledger where account = :1 Dit statement wordt vaak aan Oracle aangeboden, echter iedere keer met een andere waarde voor: 1. Ad 3. Stored Procedures . Er kan gesteld worden dat stored procedures erg veel lijken op een script die gecompileerd is en opgeslagen is in de database. Het zijn letterlijk 'Opgeslagen procedures' van SQL queries tot complete scripts die zijn opgeslagen in de database. De programmeur bepaalt of er gebruik wordt gemaakt van stored procedures. In de praktijk blijkt dat indien hiervan gebruik wordt gemaakt de snelheid en beveiliging van een database verbetert. Nadeel Stored Procedures:

o Vaak gebouwd voor één type of merk database. o Vraagt om meer kennis van een database administrator.

Voordeel Stored Procedures: o Verhoogt de beveiliging en de performance van een webapplicatie.

3.1.2.2 De risico classificatie van SQL-injection. Uit matrix 2a en 2b blijkt dat SQL-injection nagenoeg altijd een hoog risico met zich meebrengt indien de gestelde maatregelen niet worden nageleefd. Door het ontbreken van deze maatregelen kan de totale controle over de webapplicatie, webservers of het back-end SQL-systeem worden verkregen. Er kan gesteld worden dat de manier van benaderen van een database van belang is of een webapplicatie wel of niet gevoelig is voor SQL-injection. Bij het begin van een technisch ontwerp zijn de volgende keuzes van belang:

o Wordt er gebruik gemaakt van een 2 tier of 3 tier ontwerp. o Wordt er gebruik gemaakt van Stored procedures of geparametiseerd SQL. o Wordt er gebruik gemaakt van Dynamic SQL dan dient er gebruik te worden gemaakt

van middleware.

Als er onvoldoende invoer validatie plaatsvindt dan is het mogelijk om bijvoorbeeld een ‘Select’ statement te versturen naar de achter gelegen databases.

29

Matrix 2a (voor de matrix uitleg zie bijlage 2)

Matrix 2b

30

3.1.3 De bedreiging parameter manipulatie. Met aanvallen op basis van parameter manipulatie wijzigt de aanvaller de gegevens die tussen de client en de webapplicatie worden verzonden. Hiermee kan een kwaadwillende de controles die op een client of een back-end systeem zijn ingebouwd, omzeilen of zo instellen dat de webapplicatie anders reageert. Het wijzigen van parameters zal in de meeste gevallen plaatsvinden door het gebruik van een proxy server zoals Achilles [DigiZen Security Group]. Een tool als Achilles manipuleert zowel het HTTP en HTTPS verkeer. De gevens die gemanipuleerd kunnen worden zijn de volgende gegevens:

o Query strings. o Form fields. o Cookies. zie paragraaf 3.5 o Gemanipuleerde HTTP headers.

3.1.3.1 Maatregelen tegen parameter manipulatie. Hieronder volgen maatregelen die parameter manipulatie van een webapplicatie kunnen tegengaan:

1. Vertrouw niet op client-side validatie. 2. Zorg ervoor dat de controles plaatsvinden op de server-side en niet op de client-side. 3. Valideer alle waarden die van de client worden ontvangen. 4. Voorkom webapplicatie bufferoverflow.

Hieronder volgt een uitwerking van de hierboven beschreven maatregelen die betrekking hebben op parameter manipulatie. Ad 1. Vertrouw niet op client-side validatie. Een Server-side code doet zijn eigen validatie. Met client-side validatie wordt bijvoorbeeld met javascript gekeken of de invoer correct is. Op het moment dat een kwaadwillend persoon door middel van een proxy deze invoer “omzeilt” wordt het aan de andere kant gezien als “goede invoer”. Dit geeft een attacker weer mogelijkheden om een systeem aan de server-side te omzeilen. Ad 2. Zorg ervoor dat de controles plaatsvinden op de server-side en niet op de client-side. Zorg ervoor dat de gebruikerscontroles niet door parameter manipulatie omzeild kunnen worden. De parameters in een URL kunnen door eindgebruikers door het webbrowser vakje van de adrestekst worden gemanipuleerd. Heeft bijvoorbeeld de URL http://www.< YourSite>/< ?YourApp>/sessionId=10 een waarde van 10 dan kan deze in een ander random nummer worden veranderd om op deze manier verschillende output te ontvangen. Zorg ervoor dat de controles plaatsvinden op de server-side en niet op de client-side. Ad 3. Valideer alle waarden die van de client worden ontvangen. Als de waarden op een webformulier vooraf zijn bepaald, kunnen de clienten/gebruikers deze veranderen en terug sturen met totaal onvoorspelbare resultaten. Bijvoorbeeld als het invoer gebied geldt voor de invoer van een postcode, dan dient ervoor gezorgd te worden dat er alleen postcodes kunnen worden ingevoerd.

31

Ad 4. Voorkom webapplicatie bufferoverflow. Een bufferoverflow is een specifieke methode waarmee misbruik gemaakt kan worden van fouten in de implementatie van een webapplicatie. Als er aan een invoer veld of een HTTP headerveld een te lange serie tekens wordt aangeboden, kan een webapplicatie hierdoor anders reageren. Als gevolg hiervan geeft de webapplicatie informatie terug van bijvoorbeeld een geheugen segment. Een kwaadwillende kan code versturen waardoor deze code een kwaadwillende code kan worden. De meeste bufferoverflows zijn het gevolg van het ontbreken van invoer validatie. Waarom niet altijd de invoer wordt gecontroleerd, heeft te maken met een keuze op het gebied van performance. Het herschrijven van bijvoorbeeld de HTTP Referer-field kost veel performance en daardoor tijd en wordt in de praktijk veelal achterwege gelaten.

3.1.3.2 De risico classificatie van parameter manipulatie. Uit matrix 3a en 3b blijkt dat parameter manipulatie voor beide soorten webapplicaties een risico met zich meebrengt. Door het ontbreken van de gestelde maatregelen wordt er een medium risico gevormd op een niet financiële en niet vertrouwelijke webapplicatie, doordat waarden een verkeerde voorstelling van zaken geven. Bij de vertrouwelijke of financiële webapplicatie is een hoog risico aanwezig, indien de maatregelen ontbreken, daar het niet zeker is of de gegevens betrouwbaar zijn. In de webapplicatie dienen extra maatregelen te worden getroffen op het gebied van paramater manipulatie. In de praktijk kan het al voldoende zijn om te werken met eenvoudige scripts en aanpassingen in de server-side webapplicatie. En vertrouw niet op client-side validatie als er data binnenkomt. In de praktijk dient de maximale buffer grootte van tevoren gedefinieerd te worden, zowel in de webapplicatie als op webserver niveau. In de praktijk zijn deze buffers maximaal 8096 bytes groot, als een data veld groter is dan deze waarde dan dient de webserver en de webapplicatie dit te negeren.

matrix 3a (voor de matrix uitleg zie bijlage 2)

32

Matrix 3b

33

3.2 De bedreiging session Hi-jacking. Met session hi-jacking probeert een aanvaller de credentials van een tegenpartij te stelen om zo illegaal toegang te verkrijgen tot een webapplicatie. Session-hi-jacking gebeurt tegenwoordig meestal door virussen, phishing of een Trojan horse programma. Voor webapplicaties dienen wel degelijk maatregelen aanwezig te zijn om session hi-jacking te voorkomen. Om dit tegen te gaan wordt session management [Hugh and Lane] gebruikt. 3.2.1 Maatregelen tegen session hi-jacking. Webapplicaties worden opgebouwd op het stateless HTTP protocol. Daardoor is session management een applicatie–level verantwoordelijkheid. Session security is zeer kritisch en belangrijk voor de algemene veiligheid van een webapplicatie. Om session hi-jacking tegen te gaan dient gebruik gemaakt te worden van session management en dienen de onderstaande technische maatregelen getroffen te worden:

1. Zorg voor een begrenzing van een cookie sessie duur. (lifetime) 2. Vertrouw niet op HTTP header informatie. 3. Beveilig de session state tegen ongeautoriseerde toegang. 4. Voorkom dat vertrouwelijke informatie in de locale cache achter blijft. 5. Beveilig vertrouwelijke webpagina’s door middel van SSL.

Hieronder volgt een uitleg van de bovengenoemde maatregelen. Ad 1. Zorg voor een begrenzing van de cookie sessie duur. (lifetime) Beperk de duur van de sessies om de kans op session hi-jacking en replay attacks 1 te verkleinen. Hoe korter de sessie, hoe minder kans en tijd een attacker heeft om een cookie af te vangen en deze te gebruiken om toegang te krijgen tot een toepassing. Het afvangen van een cookie is ook mogelijk door middel van XSS. Bij het uitloggen en afsluiten van een webapplicatie dienen alle cookies te worden verwijderd. 1) Poging om in een computersysteem binnen te breken, door een opgenomen netwerk conversatie terug af te spelen Ad 2. Vertrouw niet op HTTP-Header informatie. Bij HTTP- verzoeken- en ontvangen van requests, dient de webapplicatie ervoor te zorgen dat er geen risicovolle informatie in HTTP-headers wordt vermeld. Met behulp van een webproxy server is dit eenvoudig om vast te stellen. Bijvoorbeeld: een controle dient vast te stellen of het verzoek daadwerkelijk uit de betreffende pagina voortkomt die door de webapplicatie wordt geproduceerd. Dit dient te worden gedaan om met zekerheid vast te stellen of de HTTP headers niet zijn vervalst. Ad 3. Beveilig de session-status tegen ongeautoriseerde toegang. Overwogen moet worden hoe informatie over de sessie-status dient te worden opgeslagen. Voor optimale performance en snelheid wil men deze graag opslaan op een server. Maar bij het gebruik van server farms moet de session-state worden opgeslagen in een shared database. Dit is nodig om de connectie via de betreffende webserver vast te houden. Wanneer de gebruiker door een load balancer wordt omgeleid naar een andere webserver dan is deze gebruiker zijn sessie kwijt. Men zal ervoor moeten zorgen dat er een beveiligde link is opgezet naar de shared database voor het afhandelen van de sessie status. Hiermee voorkomt men dat, door middel van eavesdropping (snifferen), een link kan worden afgetapt. Als het om zeer vertrouwelijke gegevens gaat, dient men ook te denken aan een cryptografisch systeem om de integriteit en vertrouwelijkheid te waarborgen. (zie paragraaf 3.3)

34

Ad 4. Voorkom dat vertrouwelijke informatie in de locale cache achterblijft. Bij het gebruik van een Internet browser blijft ongemerkt veel informatie achter op een PC. Bij vertrouwelijke informatie is het mogelijk dat een kwaadwillende deze informatie misbruikt. In figuur 8 volgt hiervan een voorbeeld.

Figuur 8 In de velden “Inlognaam” en “ wachtwoord” zijn, door de programmeur, de “COMPLETE attributen” niet uitgezet in een HTML formulier. Secure pagina’s kunnen ook worden opgeslagen in de cache van een webbrowser. Om dit te voorkomen dient de programmeur ervoor te zorgen dat de vertrouwelijke informatie niet lokaal achterblijft. De security manager dient richtlijnen op te stellen waarmee de auditor de betreffende codes kan controleren. (zie voor verdere uitwerking hoofdstuk vier) De beste manier om de volgende HTTP header te plaatsen is: 'Pragma: No-cache' and 'Cache-control: No-cache'. Of <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> en <META HTTP-EQUIV="Cache-Control" CONTENT="no-cache"> Door het plaatsen van de HTTP header zal het een kwaadwillende moeilijker worden gemaakt om vertrouwelijke informatie te vinden die in de cache opgeslagen is geweest. Ad 5. Beveilig vertrouwelijke webpagina’s door middel van SSL. Bij het gebruik van vertrouwelijke gegevens is het van belang dat de betreffende informatie versleuteld over de lijn gaat. Een ander punt is ook dat er geen vertrouwelijke informatie achterblijft op de PC. Vaak gaat er vertrouwelijke informatie wel versleuteld over de lijn maar het is schrikbarend wat er achterblijft aan vertrouwelijke informatie in de lokale cache van de PC. Bij bancaire toepassingen wordt geadviseerd altijd gebruik te maken van SSL door middel van hardware based SSL accelerators. Dit heeft als voordeel dat het SSL certificaat niet meer op een server draait maar op een speciale crypto box. Dit komt de snelheid ten goede.

35

Bovendien zijn deze boxen zeer moeilijk te hacken in verband met het tamperproof zijn van deze hardware.

3.2.1.1 De risico classificatie session hi-jacking. Uit matrix 4a blijkt dat het risico van session hi-jacking laag is. De bedreiging session hi-jacking is altijd aanwezig indien het een financiële of vertrouwelijke webapplicatie betreft. Uit matrix 4b blijkt echter dat bij een webapplicatie waar wel vertrouwelijke of financiële handelingen plaatsvinden de risico’s oplopen van medium tot high indien de gestelde maatregelen ontbreken. Een kwaadwillende kan een sessie van een ander overnemen en deze misbruiken. Indien de bovengestelde maatregelen niet zijn toegepast dan is session-hi-jacking altijd een hoog risico.

Matrix 4a (voor de matrix uitleg zie bijlage 2) .

36

Matrix 4b

37

3.3 De bedreiging identity spoofing. De laatste tijd zijn veel bedrijven en personen slachtoffer geworden van een zogenaamde 'phishing scam'. In februari 2004 betrof dit meer dan 282 websites. [http://news.netcraft.com/archives/2004/04/01/new_phishing_scam_prompts_warnings.html] Dit is een geval van oplichting waarbij via een nep website naar iemands creditcard gegevens wordt 'gevist'. Phishing (vissen) is een verzamelnaam voor digitale activiteiten die tot doel hebben persoonlijke informatie van mensen te ontfutselen. Deze persoonlijke informatie kan direct worden misbruikt, in het geval van creditcardnummers, door het doen van uitgaven of voor wat in het Engels 'identity theft' wordt genoemd, het stelen van een identiteit. In dit geval zijn bijvoorbeeld gegevens als sofi-nummers, adressen en geboortedata nodig. Identity spoofing is grotendeels gebaseerd op authenticatie. Hieronder volgt een uitleg hiervan. Authenticatie. Authenticatie voorziet in zekerheid omtrent de identiteit van zowel de zender als de ontvanger. Dit is van belang zodat een ieder zeker weet van wie en voor wie het bericht is. Naast authenticatie van zender en ontvanger is ook authenticiteit van de maker van het bericht zelf zeer relevant; dit heeft betrekking op niveau van het bericht zelf, terwijl de authenticatie van zender en ontvanger op het transmissieniveau plaatsvindt. Authenticatie is het proces om de bezoekersidentiteit te bepalen en er zijn vier te overwegen aspecten:

o Bepaal waar de authentificatie in een toepassing wordt vereist. Het wordt over het algemeen vereist wanneer een vertrouwensgrens wordt gepasseerd. De grenzen van het vertrouwen omvat gewoonlijk gebruikers, processen en systemen.

o Bevestig wie de bezoeker is. De gebruikers identificeren zich met gebruikersnamen en wachtwoorden om de authentiteit te bepalen.

o Identificeer de gebruiker op verdere verzoeken. Dit vereist één of andere vorm van authentificatie op basis van crypto of een session-id.

o Bij het aanloggen op een webapplicatie dient gebruik te worden gemaakt van extra controles. Dit kan bijvoorbeeld bestaan uit een grafische invoer weergave door middel van een muis. (zie figuur 9)

Figuur 9

Figuur 9 laat een aanlog scherm zien waarbij aangeklikt wordt met een muis waardoor een keylogger niet het gehele wachtwoord kan afvangen.

38

Veel webapplicaties werken op basis van user-id en wachtwoorden in een HTML formulier. De problemen en vragen die hier betrekking op hebben zijn:

o Worden de gebruikersnamen en wachtwoorden verzonden in klare tekst over een onveilig kanaal?

o Bij het versturen over een onveilig kanaal kan een attacker dit afluisteren of wordt er gebruik gemaakt van een SSL connectie?

o Hoe worden de persoonlijke gegevens opgeslagen? o Als de gebruikersnamen en wachtwoorden in plaintext worden opgeslagen of in een

database, vraagt dat om problemen? o Wat als een bestandsfolder incorrect wordt geconfigureerd en een aanvaller de

persoonlijke gegevens kan doorbladeren en de inhoud naar zijn home PC kan downloaden?

o Wat als een ontevreden beheerder iemands gegevensbestand van gebruikersnamen en wachtwoorden misbruikt?

o Wat als een persoons het slachtoffers is van browser hi-jacking? o Wat als de PC is voorzien van spyware met een keyboardlogger? o Als de beveiligingslekken in de browser worden misbruikt en ongezien een

programma geïnstalleerd wordt op de harde schijf van een argeloze surfer. Bij het bezoeken van een specifieke website, bijvoorbeeld een online bank, komt de malware in actie en onderschept gebruikersnamen en wachtwoorden van de internetgebruiker.

De vraag is “hoe worden de persoonlijke gegevens geverifieerd?” Er is geen behoefte om gebruikerswachtwoorden op te slaan in klare tekst, als het enige doel is te verifiëren of de gebruiker het wachtwoord kent. In plaats daarvan is het beter een hash te bewaren zodat het wachtwoord niet direct leesbaar is bij een hack. Om de bedreiging van dictionary attacks te ontmoedigen, dient men “sterke” wachtwoorden te gebruiken om zo deze aanvallen te bemoeilijken. Een betere oplossing is gebruik te maken van een goede cryptografische toepassing. Hoe wordt de authenticiteit van de users vastgesteld als ze willen inloggen? In de meeste gevallen is dit op basis van een authenticatie ticket. Dit kan eventueel ook een authenticatie cookie zijn. 3.3.1 De maatregelen tegen identity spoofing. Om identity spoofing te voorkomen dient men, om te beginnen, ervoor te zorgen dat een cookie en de authentificatie van een webapplicatie adequaat is geregeld. Hoe dient een cookie beveiligd te worden:

o Als het Cookie over een onveilig kanaal wordt verzonden, kan een aanvaller het cookie afvangen en het misbruiken om tot de toepassing toegang te verkrijgen. Een gestolen authentificatie cookie is een gestolen opening. Er dient gebruik gemaakt te worden van een beveiligde verbinding zoals SSL. Voor een optimale beveiliging dient gebruik gemaakt te worden van een challenge en response op basis van sterke cryptografie.

o Bij gebruik van cookies die vertrouwelijke informatie bevatten dient men minimaal van SSL gebruik te maken en een versleuteld cookie te gebruiken.

o Als er toch van een cookie gebruik gemaakt wordt, dient deze te werken op basis van een session-id en de data in de cookie dient te worden versleuteld.

De hieronder beschreven maatregelen verbeteren de authenticatie van een webapplicatie toepassing:

39

1. Maak op de webserver afzonderlijke publieke en private directory’s. 2. Gebruikers policy en gebruikers accounts blokkeren. 3. Wachtwoorden bij webapplicaties dienen regelmatig te worden gewijzigd. 4. Zorg ervoor dat een gebruikersaccount geblokkeerd kan worden. 5. Bewaar geen wachtwoorden in een home directory. 6. Maak geen gebruik van klare tekst wachtwoorden. 7. Bescherm Authenticatie Cookies. 8. Versleutel de vertrouwelijke informatie en de status van een cookie. 9. Maak gebruik van cryptografie t.b.v. authenticatie en SSL voor het versleutelen van

vertrouwelijke informatie. Hieronder worden de beschreven maatregelen met betrekking tot identity spoofing uitgewerkt. Ad 1. Maak op de webserver afzonderlijke publieke en private directory’s. Een publieke webserver omgeving kan door iedereen worden benaderd. De private gebieden dienen op een aparte webserver te zijn geïnstalleerd en kunnen slechts door specifieke individuen worden betreden en de gebruikers dienen gebruik te maken van authenticatie. Voorbeeld. Bij een detailhandel website is het mogelijk om de productcatalogus publiekelijk door te bladeren. Wanneer iemand een product aan de “winkelkar” toevoegt, identificeert de toepassing zich met een herkenningsteken. Wanneer iemand een order plaatst, voert deze een veilige transactie uit. Dit vereist dat men moet inloggen om de transactie die over SSL wordt getransporteerd authentiek te verklaren. Door onderscheid te maken in publieke en privé toegangsgebieden, kunnen door gebruik te maken van afzonderlijke authentificatie en van SSL, de gebieden beperken tot het gedeelte waar vertrouwelijke informatie mee gemoeid is. Ad 2. Gebruikers policy en gebruikers accounts blokkeren. Een user policy is een richtlijn die geldt voor één of meerdere gebruikers. Deze richtlijnen dienen door security managers te worden vastgesteld. Veel systemen zijn niet voorzien van een user policy. Hierdoor kunnen kwaadwillende ongemerkt acties uitvoeren. Door bijvoorbeeld een “brute force attack” uit te voeren, kan de user-id en wachtwoord van de gebruikers achterhaald worden. De betreffende informatie zal daardoor niet zichtbaar worden als er geen gebruik wordt gemaakt van logging en monitoring. Om te voorkomen dat de user-id en het wachtwoord van gebruikers wordt achterhaald, dient iedere gebeurtenis in een logboek, na een vastgesteld aantal mislukte, gelukte of onderbroken sessieopeningen, te worden weggeschreven. Als van authenticatie van vensters gebruik wordt gemaakt, bijvoorbeeld door middel van NTLM of het Kerberos protocol, kan dit beleid automatisch door het werkende systeem worden gevormd en worden toegepast. Pas echter op met het afsluiten van user accounts op basis van mislukte logon. Dit kan ook leiden tot een denial of service attacks als de user-ids bekend zijn.

Ad 3. Wachtwoorden bij webapplicaties dienen regelmatig te worden gewijzigd. De wachtwoorden zouden niet statisch moeten zijn maar dienen periodiek gewijzigd te worden. Dit kan verstrekkende gevolgen hebben voor het toepassingsontwerp. Bij confidentiële of financiële webapplicaties kan beter gebruik worden gemaakt van een cryptografisch oplossing op basis van kennis (pincode) en bezit. (bijv. een token) Ad 4. Zorg ervoor dat een gebruikersaccount geblokkeerd kan worden. Als het systeem wordt gecompromitteerd via een bepaalde user-id, dan moet een beheerder deze user-id direct kunnen blokkeren om zo verdere aanval of misbruik te verhinderen.

40

Ad 5. Bewaar geen wachtwoorden in een home directory. Als iemand zijn wachtwoorden moet verifiëren, is het niet noodzakelijk de wachtwoorden op te slaan. Maak in plaats daarvan gebruik van een hash. Om de bedreiging van dictionary attacks op te vangen dient men gebruik te maken van sterke wachtwoorden, bijvoorbeeld bestaande uit een verplicht aantal hoofdletters, kleine letters, nummers en minimaal 8 karakters. Ad 6. Maak geen gebruik klare tekst wachtwoorden. De wachtwoorden van klare tekst die over een netwerk worden verzonden, zijn kwetsbaar voor afluisteren. Om deze bedreiging te beperken, dient men het communicatiekanaal te beveiligen, bijvoorbeeld door SSL te gebruiken om het verkeer te coderen. Ad 7. Bescherm Authenticatie Cookies. Een gestolen authenticatie cookie is een gestolen login. Het is beter om gebruik te maken van een authenticatie ticket waarbij het ticket gebruik maakt van encryptie en veilige communicatie kanalen. Beperk ook de tijdsduur waarin een authenticatie ticket geldig is. Dit om spoofing voortvloeiend uit replay attacks te voorkomen. Als het een aanvaller toch lukt om een cookie af te vangen en deze gebruikt om ongeoorloofde toegang tot een website te verkrijgen, zorg dan voor een sessie time-out. Het verkleinen van de cookie time-out verhindert replay attacks niet, maar het beperkt de hoeveelheid tijd die de aanvaller heeft om misbruik te maken van de gestolen cookie. Ad 8. Versleutel de vertrouwelijke informatie en de status van een cookie. De cookies kunnen gevoelige informatie bevatten, zoals gebruiker of password gegevens, die als deel van het server-side proces worden gebruikt. De cookie moet in deze situatie altijd versleuteld zijn op basis van een sterke cryptografie. Ad 9. Cryptografie voor beveiligen van webapplicaties. Cryptografie draagt vooral zorg voor het authenticatie-aspect en het vertrouwelijkheidaspect. Cryptografie is essentieel om computernetwerken geschikt te maken voor zakelijke transacties en het is een voorwaarde om de privacy te waarborgen en fraude te voorkomen. Cryptografie, in zijn meest fundamentele vorm, verstrekt het volgende:

o Vertrouwelijkheid. Er wordt gezorgd dat een bericht geheim blijft.

o Non-Repudiation (authenticiteit). Deze dienst zorgt ervoor dat een gebruiker niet kan ontkennen dat een bepaald bericht is verzonden. Tevens kan een ontvanger niet ontkennen een bericht te hebben ontvangen.

o Integriteit. Deze dienst gaat na of de verzonden data niet veranderd is. Hierbij is de informatie onzichtbaar voor anderen.

o Authentication. Hierbij is de persoon, wie hij zegt dat hij is.

41

Webapplicaties maken vaak gebruik van cryptografie om opgeslagen gegevens te beveiligen. Cryptografie kan er ook voor zorgen dat de informatie die over het netwerk gaat versleuteld en beveiligd wordt. De volgende situaties verbeteren de veiligheid van een webapplicatie als er gebruik wordt gemaakt van cryptografie:

1. Maak gebruik van bekende Cryptografische algoritmes en routines. 2. Beveilig de encryptie sleutels. 3. Maak gebruik van hardware of software gebaseerde tokens, smartcards of USB

dongles.

Hieronder volgt een uitwerking van de hierboven beschreven maatregelen. Ad 1. Maak gebruik van bekende Cryptografische algoritmes en routines. Maak gebruik van bekende Cryptografische algoritmes en routines. Deze zijn langdurig getest en zwakheden zijn meestal bekend. Het is belangrijk dat men de juiste algoritme en de juiste sleutel kiest. Dit is belangrijk om een goede graad van beveiliging te verkrijgen bij webapplicaties. Ad 2. Beveilig de encryptie sleutels. Als een aanvaller de beschikking krijgt over “private” sleutels dan zijn de gecodeerde gegevens niet meer veilig. Zorg voor adequate processen voor het beheer van sleutels en sla de sleutels op op speciale tamperproof hardware. Ad 3. Maak gebruik van hardware of software gebaseerde tokens, smartcards of USB dongles. Deze dongles of tokens zijn een aanvulling op de gebruikelijke beveiliging van gebruikerswachtwoorden en werken als een soort “eenmalige quiz”. De gebruiker wordt eerst naar de beveiligings server geleid, die hem een zogenaamde “challange” presenteert. Deze bestaat bijvoorbeeld uit een reeks getallen die ingetoetst moeten worden in de hard- of softtoken na het inbrengen van een PIN. De uitkomst van de berekening, de 'response', wordt door de beveiligings server geëvalueerd en wanneer deze wordt goed bevonden, krijgt de gebruiker toegang. Er kan ook gebruik worden gemaakt van Private SSL certificaten op basis van een smartcard of handmatige installatie. Met behulp van deze methodiek en de daarbij behorende client voorzieningen is het relatief eenvoudig om een veilige toegang te verkrijgen naar een webapplicatie. Door gebruik te maken van cryptografische beveiliging wordt het risico van identity spoofing grotendeels ondervangen. 3.3.2 De risico classificatie identity spoofing. Uit matrix 5a blijkt dat identity spoofing nauwelijks een risico vormt als het gaat om niet vertrouwelijke en niet financiële webapplicaties. Daar het te behalen gewin niet of nauwelijks aanwezig is, is ondanks het ontbreken van maatregelen het risico laag. Een aantal maatregelen brengen een medium risico met zich mee daar zij betrekking hebben op richtlijnen die zijn uitgewerkt in hoofdstuk 4. Deze richtlijnen kunnen niet in matirx 5a worden genegeerd.

42

Identity spoofing non-confidential or non-finance webapplication


Matrix 5b geeft een medium tot hoog risico aan. De medium risico’s hebben betrekking op richtlijnen.(zie hoofdstuk 4) Het uitbuiten hiervan kost tijd. De hoge risico’s duiden aan, indien de gestelde maatregelen ontbreken, dat een kwaadwillende zich voor kan doen als een ander persoon en bijvoorbeeld de autorisatie behorend bij die persoon misbruikt. De hoge risico’s hebben ook betrekking op vertrouwelijke en financiële webapplicaties. Het aanloggen met alleen een user-id en wachtwoord is uit de tijd en financiële organisaties dienen met maatregelen te komen tegen identity spoofing. Dit kan bijvoorbeeld door gebruik te maken van kennis (inlogcode) en bezit.(Token of Tancode, etc.)

43

Matrix 5b

44

3.4 De bedreiging Information disclosure en applicatieve Denial of Service attack. Webapplicaties kunnen gevoelig zijn voor information disclosure en applicatievel denial of service attacks. Information disclosure is het verstrekken van informatie over de onderliggende webapplicatie en de inrichting van onderliggende services. Deze informatie komt doorgaans voor in getoonde foutmeldingen of andere mededelingen op sites. De informatie kan worden gebruikt bij de voorbereiding van aanvallen door een kwaadwillende. Bij een applicatieve denial of service attack zorgt een aanvaller dat de webapplicatie niet meer beschikbaar is. Dit kan bijvoorbeeld door een “brute-force” attack te gebruiken, waarbij login namen van vele gebruikers worden geblokkeerd. Bij de brute-force attack wordt vele malen het wachtwoord van een gebruiker verkeerd ingevuld, zodat deze geblokkeerd wordt. 3.4.1 Maatregelen tegen Information disclosure en applicatieve Denial of Service

attack. (D.O.S.) Een maatregel om system-level information disclosure en applicatieve denial of service attacks te verhinderen is “exception management”. Exeption management houdt onder andere in:

1. Lek geen informatie uit aan een browser client. 2. Voorkom gedetailleerde fout boodschappen van webapplicaties. 3. Controleer de content op abnormality. 4. Zorg voor audittrail en logging.

Hieronder worden de maatregelen beschreven met betrekking tot information disclosure en Denial of service attack D.O.S. Ad 1. Lek geen informatie uit aan een browser client. Stel geen informatie bloot, die tot informatie onthulling kan leiden, in het geval van een foutieve afhandeling. Als iemand aan het browsen is geef dan niet de standaard webbrowser foutmelding door. Bij een Microsoft webserver kan gebruik worden gemaakt van de default 404 error pages. Deze pagina’s bevatten helaas openingen van XSS [Microsoft security bulletin MS02-018 ], waarmee bijvoorbeeld gebruikers-credentials achterhaald kunnen worden. Figuur 10 bevat een voorbeeld van een foutieve default 404 en een SQL error page en een goede afhandeling.

45

Foutieve afhandeling Goede afhandeling

Figuur 10 Ad 2. Voorkom gedetailleerde fout boodschappen van webapplicaties. Een aanvaller kan veel informatie halen uit gedetailleerde foutmeldingen. Dit is vaak voor een aanvaller een indicatie hoe verder te kunnen met deze gegevens. Verzendt gedetailleerde foutmeldingen altijd naar een logboek en verzendt alleen minimale informatie naar de webbrowser, die gebruik maakt van een webapplicatie. Neem ook maatregelen zodat wachtwoorden of andere gevoelige gegevens niet worden gelogd. Er moet voldoende aandacht worden besteed aan het incorporeren van logging mechanismen ten behoeve van audit trails en het signaleren van een aanval op de webapplicatie in het kader van security monitoring. Als er geen inzicht is waarin zwakheden in de webapplicaties worden uitgebuit door kwaadwillende personen, bestaat het risico dat inbraakpogingen niet tijdig worden gesignaleerd.

46

De hieronder beschreven maatregelen zijn uitgewerkt op het gebied van logging, audittrail en monitoring. Ad 3. Controleer de content op abnormality. Bij abnormality logging wordt er gekeken naar plotseling veranderende verkeersstromen. Als er een verhoging van het aantal “POST” requests op een webserver binnen komen, dan zal dit direct zichtbaar zijn. Door gebruik te maken van een host-based Intrusion Detection System (IDS) kan men de content controleren op abnormality. Voor een nadere uitleg van IDS zie bijlage I. Ad. 4. Zorg voor audittrail en logging. Om inzicht te krijgen in informatie disclosure of een D.O.S. kunnen we niet zonder logging en audittrails. Hiermee is het mogelijk om vast te stellen wat er precies gebeurd is en hoe de aanvaller te werk is gegaan. Tevens kunnen de logs worden gebruikt voor debugging en bij een misdrijf als forensisch bewijs. Er dient een logging aanwezig te zijn voor meerdere tiers van de applicatie. Door het actief monitoren is het mogelijk om te kijken naar “suspicious–looking” activiteiten. Zo kan een aanval in een vroeg stadium worden geconstateerd en de audittrail en logging kunnen dan als bewijs dienen voor een forensisch onderzoek. In bijvoorbeeld Basel II is bepaald dat banken minimaal 3 jaar hun weblogs dienen te bewaren. Wat betreft de logging dienen de hieronder beschreven punten minimaal een onderdeel te zijn van het beheer van een webapplicatie straat:

1. Audit en logging voor meerdere applicatie tiers. 2. Log altijd belangrijke gebeurtenissen. 3. Beveilig de logbestanden. 4. Back-up en analyseer logbestanden als een standaard proces.

Ad 1. Audit en logging over meerdere applicatie tiers. Audit en logging over meerdere applicaties tiers zijn voornamelijk voor non-repudiation, om vast te stellen of een transactie daadwerkelijk is gedaan. Bij logging dient het onderliggende operating systeem te worden gebruikt voor de logging. Voor de databases dient een aparte logging database te worden geïmplementeerd. Ad 2. Log altijd belangrijke gebeurtenissen. Het loggen van events is vaak niet geïmplementeerd. Daardoor is het lastig om een goed overzicht te krijgen. De soorten gebeurtenissen die moeten worden geregistreerd zijn: succesvolle en onderbroken sessiepogingen, wijziging en herwinning van gegevens, netwerkmededelingen, administratieve functies en het onbruikbaar maken van de logging. De logboeken zouden de tijd en de plaats van de gebeurtenis, de machinenaam, de identiteit van de huidige gebruiker, de identiteit van het proces in werking en een uitvoerige beschrijving van de gebeurtenis moeten omvatten. Ad 3. Beveilig de logbestanden. Logbestanden kunnen vertrouwelijke informatie bevatten en dienen niet voor iedereen toegankelijk te zijn. De voorkeur gaat er naar uit dat de logging nooit wordt opgeslagen op de webapplicatie server maar op een aparte beveiligde loghost. Beveilig en beperk de toegang tot de logbestanden. Dit maakt het voor aanvallers moeilijker met logboeken te knoeien en zo hun sporen te wissen. Machtig slechts personen, zoals beheerders en security managers, die gebruik maken van dual authentication op basis van kennis en bezit, voor het aanloggen op deze systemen.

47

Ad 4. Back-up en analyseer logbestanden als een standaard proces. Het kan gebeuren dat voor forensisch onderzoek de logging als bewijs moet dienen. Als er geen logging of audittrail aanwezig is, zal vaak geen onderzoek gestart kunnen worden naar de betreffende persoon. Zorg dan ook voor een structurele aanpak voor het back-uppen van de logbestanden. Een ander punt waaraan veelal onvoldoende aandacht besteed wordt, is het controleren en analyseren van logbestanden. Als een back-up van de logbestanden wordt gemaakt dient er een procedure aanwezig te zijn om logbestanden te controleren en analyseren op mogelijke aanvallen. Het analyseren van informatie kan gebeuren door middel van intrusion-, detectie-, en preventie systemen.

48

3.4.2 De risico classificatie Information disclosure en applicatieve Denial of Service. Door het afvangen van fouten in een webpagina en door het uitvoeren van de controle op content en logging kunnen applicatieve-D.O.S. aanvallen voorkomen worden. Hierdoor kan adequate actie ondernomen worden om de beschikbaarheid van de webapplicatie te garanderen. D.O.S. aanvallen op netwerk niveau kunnen niet voorkomen worden doordat deze eenvoudig te spoofen zijn. Zo kan een potentiële aanval vroeg worden geconstateerd door middel van een “Host Based Intrusion Dectection System. (HIDS) De audittrails en logging kunnen later als bewijs dienen voor een forensisch onderzoek. Uit matrix 6a blijkt dat bij webapplicaties zonder vertrouwelijke en niet financiële informatie het gevaar classificatie Information disclosure en applicatieve Denial of Service attack laag is. Het kan lastig zijn als door een Denial of Service een webapplicatie niet beschikbaar is. De foutboodschappen kunnen rare foutmeldingen opleveren, maar deze vormen meestal geen direct risico. Uit matrix 6b blijkt dat bij een webapplicatie waar wel vertrouwelijke of financiële handelingen plaatsvinden de risico’s oplopen van medium tot high. Met de vrijkomende informatie kan een kwaadwillend persoon zijn aanval voorbereiden. Deze persoon kan zien hoe bijvoorbeeld een query is opgebouwd en deze met een UNION commando misbruiken. Bij financiële en vertrouwelijke webapplicaties dienen de beschreven maatregelen zeker te worden nagestreefd.


49

Matrix 6b

50

4 POSITIONERING SECURITY MANAGEMENT. Het bouwen en testen van een webapplicatie kost veel tijd. Door de commerciële druk wordt voor de beveiliging vaak niet de tijd genomen. Ter illustratie, in hoofdstuk drie is gebleken dat meer dan 90% van de webservers problemen hebben met code-injection.

4.1 Wat zijn de knelpunten. Security management wordt vaak alleen toegepast binnen audit en security afdelingen. Doordat security afdelingen en auditors vaak laat in het ontwikkelingsproces betrokken worden, draaien die webapplicaties al geruime tijd. De security afdelingen en auditors controleren deze webapplicaties wel, maar vooral op de bekende exploits. De exploits van applicaties en in het bijzonder de bedreigingen, beschreven in hoofdstuk drie, worden echter vergeten. Tools zoals Nessus, ISS internetscanner en andere zijn grotendeels op netwerk kwetsbaarheden gebaseerd. Voor webapplicatie audits heeft de auditor en de security afdeling geen of onvoldoende beschikking over de juiste tooling. Daarnaast ontbreekt vaak voldoende kennis over de tooling. Dit is gebleken na onderzoek en interviews met de heren M. van de Bergh (Hoofd IT audit ING) en C. van het Hoof (Docent VU IT-audit opleiding Amsterdam). Dit kan tot gevolg hebben dat een webapplicatie ten onrechte het oordeel “ goed” krijgt. Zo is het voorgekomen dat door code-injections op een “goed” bevonden site in twee dagen 10.000 creditcards nummers werden doorverkocht aan de Chinese maffia (Bron Cert Australie). De webcirkel van figuur 11 geeft weer waar het fout gaat bij het ontwikkelen van webapplicaties. Dit probleem wordt geïllustreerd in de door mij genoemde “webapplicatie cirkel”. (zie figuur 11)

Figuur 11 webapplicatie cirkel Het ontwikkeltraject van een webapplicatie is als volgt:

o Ontwikkelomgeving: het ontwikkelen van een webapplicatie. o Acceptatie omgeving: het testen en functioneel beoordelen van een webapplicatie. o Security afdeling: beoordeling of de webapplicatie volgens security richtlijnen in

productie is gegaan. o Auditors: controle of de webapplicatie voldoet aan de richtlijnen. Indien richtlijnen

ontbreken wordt de webapplicatie op best pratice beoordeeld.

51

Dit traject is weergegeven in de webapplicatie cirkel. Deze cirkel is opgedeeld in groene en witte vlakken. De groene vlakken zijn de processen. Waar security management en security checks voor de betreffende webapplicatie worden toegepast, is aangeduid met een wit vlak. Aandacht voor webapplicatie security (zie het witte vlak in figuur 11) zien we vaak terug bij een onderdeel van auditing en de security afdeling. Kortom de uitvoer van security management is te oppervlakkig en beperkt tot twee afdelingen. Om risico’s, zoals in deze thesis zijn geschetst, te voorkomen, zou security ook een vast onderdeel moeten zijn van het ontwikkel-, acceptatie- én testtraject. Hoe zou dit opgepakt moeten worden voor de betrokken afdelingen?

4.2 Invoeren en borging in de organisatie. Het is van groot belang dat security management een integraal onderdeel wordt van de in de webapplicatie cirkel (figuur 11) weergegeven afdelingen. In de werkprocessen dient security management verankerd te worden. Ontwikkelingsafdelingen dienen specifieke ontwikkelstandaarden en richtlijnen op te stellen. Deze standaarden en richtlijnen dienen gedetailleerd beschreven te worden en de maatregelen dienen te worden geaccordeerd. Tevens dient in deze standaarden en richtlijnen het proces beschreven te zijn dat zorgt voor de borging van de juiste set aan maatregelen. Hierbij kan gedacht worden aan collegiale code reviews en het gebruik van tooling voor geautomatiseerd reviewen van geprogrammeerde code. In de Acceptatieomgeving dienen testen te worden uitgevoerd om vast te stellen of een webapplicatie de functionaliteit biedt en werkt volgens de requirements van de gebruikers of opdrachtgever. Tevens dient vastgesteld te worden of de betreffende webapplicatie veilig en robuust is, zodat deze in de productieomgeving geplaatst kan worden. Wanneer opgeleverde programmatuur niet veilig is bevonden tijdens de acceptatiefase, mag deze niet worden geaccordeerd en in productie worden genomen. Na in productie name van een geaccordeerde webapplicatie, is de beheerorganisatie verantwoordelijk hiervoor. Bij de overdracht naar de beheerorganisatie dient vastgesteld te worden of de geïmplementeerde beveiligingsmaatregelen voldoende zijn. Beveiligingsaspecten moeten derhalve standaard hun weerslag hebben op testscripts en daarmee expliciet deel uitmaken van de uit te voeren acceptatietesten. De kwaliteit van geïmplementeerde beveiligingsmaatregelen kan worden vastgesteld door gebruik te maken van tooling. Op deze manier worden de in hoofdstuk drie beschreven bedreigingen zoveel mogelijk voorkomen. Dit neemt niet weg dat security checks door security management en audits ook moeten worden uitgevoerd. De afdeling security management dient webapplicatie richtlijnen (policy’s) op te stellen voor webapplicatie ontwikkelaars en deze dienen geborgd te worden in de organisatie. Voor een organisatie kunnen ook de ISO 17799 controls met de requirements betreffende classificatie een uitgangspunt zijn. In een security policy ten behoeve van een ontwikkelomgeving dienen minimaal de volgende richtlijnen te staan. Richtlijnen ten behoeve van webapplicatie ontwikkelomgeving policy: 1. Beveiligingseisen voor systemen.

o Analyse en specificatie van beveiligingseisen. o Voor nieuwe systemen of uitbreidingen van bestaande systemen dienen de

beveiligingseisen te zijn opgenomen.

52

2. Beveiliging in toepassingssystemen. Gegevens die worden ingevoerd in webapplicaties dienen te worden gevalideerd. De volgende maatregelen dienen uitgevoerd te worden:

o Validatie van invoergegevens ten behoeve van Cross-site scripting, SQL-injection en parameter manipulatie.

o Validatie van uitvoergegevens en information disclosure. o Session hi-jacking. o Identity spoofing. o Applicatieve Denial of Service attack. o Database beveiliging.

3. Cryptografische beveiliging . Cryptografische systemen en technieken dienen te worden gebruikt ter beveiliging van gegevens die aan risico’s blootgesteld kunnen worden en die onvoldoende beveiligd worden door andere maatregelen.

o Beleid ten aanzien van het gebruik van cryptografische beveiliging. o Versleuteling (encryptie). o Digitale handtekeningen. o Onweerlegbaarheid. o Sleutelbeheer.

4. Beveiliging van systeembestanden. Het handhaven van de integriteit van een webapplicatie is de verantwoordelijkheid van de ontwikkelaar en de eigenaar, aan wie het webapplicatie of de programmatuur toebehoort. Hieronder zijn de volgende controles van toepassing:

o Controle op operationele programmatuur. o Beveiliging van testgegevens. o Toegangsbeveiliging voor ontwikkelbibliotheken met bronprogramma's.

5. Beveiliging bij ontwikkel - en ondersteuningsprocessen. Managers die verantwoordelijk zijn voor de ontwikkeling en ondersteuning van webapplicaties, zijn ook verantwoordelijk voor de beveiliging van de project– of ondersteunende afdelingen. Zij dienen ervoor te zorgen dat alle voorgestelde systeemwijzigingen worden gecontroleerd, zodat de beveiliging van de webapplicatie-, systeem- of besturingsomgeving niet in gevaar gebracht wordt. De hieronder beschreven richtlijnen dienen minimaal te worden uitgewerkt:

o Procedures voor het beheer van wijzigingen. o Technische controle op wijzigingen in het besturingssysteem. o Restricties op wijzigingen in softwarepakketten. o Controle op geheime communicatiekanalen en Trojan horse en spyware. o Uitbesteden van ontwikkeling van programmatuur. o Het regelmatig uitvoeren van een securityscan/webasessment.

Echter security maatregelen hebben ook hun keerzijde, ze brengen kosten met zich mee en in het algemeen beperken ze de functionaliteit van de webapplicatie. Het is van belang om niet zwaarder te beveiligen dan nodig is, maar ook niet te licht. Om de risico’s te kunnen beheersen moet bekend zijn welke risico’s gelopen worden en hoe groot deze risico’s zijn. Om dit te onderzoeken dient een risicoanalyse uitgevoerd te worden. Een risicoanalyse is een methode die informatie oplevert op basis waarvan het management zal beslissen of er maatregelen getroffen dienen te worden. Het management kan echter ook beslissen om een risico te accepteren. Bij het ontwerpen van financiële en vertrouwelijke webapplicaties, dient een risicoanalyse een standaard onderdeel te zijn van het ontwerp.

53

In hoofdstuk drie is een risicoanalyse gedaan op het ontbreken van maatregelen. De uitkomst kan bruikbaar zijn als invoer voor het bepalen welke maatregelen genomen moeten worden. De risicoanalyse kan gebaseerd zijn op de standaard benadering “de checklist”, maar de voorkeur gaat uit naar een maatwerkbenadering voor iedere nieuwe financiële en vertrouwelijke webapplicatie.

4.3 Security awareness. Naast het bovengenoemde, dienen de medewerkers van een organisatie bewust te worden gemaakt van de risico’s met betrekking tot webapplicaties. Programmeurs dienen te worden bijgeschoold op het gebied van bedreigingen en maatregelen van webapplicaties. De acceptanten en security managers dienen te worden getraind in het detecteren van de bedreigingen. Van Security managers zal eveneens verwacht worden dat zij kennis verkrijgen van webapplicaties en de maatregelen om bedreigingen te elimineren. Auditors zullen kennis van bedreigingen van webapplicaties moeten opdoen om hun controles hierop in te kunnen richten. Wanneer auditors beter bekend zijn met de bedreigingen, kunnen zij de controle en hun natuurlijke adviesfunctie naar de organisatie toe beter invullen.

4.4 De tooling. Om de softwarematige bedreigingen, die beschreven zijn in hoofdstuk drie, te voorkomen en te detecteren is tooling nodig. Zonder adequate tooling is dit niet mogelijk. De tooling dient een standaard werkset te zijn voor ontwikkelaars, acceptanten, security managers en auditors. Tools die gebruikt kunnen worden zijn bijvoorbeeld:

o Webinspect for Developers. o @Stake WebProxy, AppScan. o Diverse open source tools. o Source code ananylser van Forify software o Prexis van OunceLabs o Source Code Analysis van securesoftware

Met behulp van deze tooling kunnen programmeurs direct kijken of hun programmatuur gevoelig is voor de aanvallen die beschreven zijn in hoofdstuk drie. De hierboven beschreven tools vereisen een hoog kennisniveau over webprogrammering bij het gebruik en de vertaling van de resultaten die de tools laten zien. Hiermee wordt bedoeld; het omzetten van de gepresenteerde resultaten in bedreigingen voor de organisatie, de inschatting van de kans op het zich voordoen hiervan en de impact die deze bedreigingen hebben op de organisatie. Wanneer de kennis binnen de organisatie niet of onvoldoende aanwezig is, zal deze moeten worden ingehuurd om tot het beoogde resultaat te komen.

54

4.5 Tot slot. Indien security management een vast onderdeel wordt van alle afdelingen in de webapplicatie cirkel (zie het witte vlak in figuur 12) zullen de webapplicaties binnen deze organisaties veiliger en robuuster worden. Figuur 12

--

55

5 SAMENVATTING EN CONCLUSIE. De beveiliging van webapplicaties blijkt veelal onderbelicht. Het ontbreken van kennis en awereness op dit gebied bij security afdelingen en auditors en het ontbreken van security management in het ontwikkelacceptatie proces zijn hier de grootste oorzaken van. Om webapplicaties te kunnen beveiligen is inzicht nodig in de bedreigingen en de maatregelen om deze het hoofd te bieden. In hoofdstuk drie zijn bedreigingen op het gebied van webapplicaties en de daarbij behorende maatregelen aan de orde gekomen. De bedreigingen zijn:

1. Cross-Site Scripting. 2. SQL-injection. 3. Parameter manipulatie. 4. Session hi-jacking. 5. Identity spoofing. 6. Information disclosure en Denial of Service.

Het ontbreken van de in hoofdstuk drie genoemde maatregelen op de bovengenoemde bedreigingen brengt risico’s met zich mee. De impact hiervan is afhankelijk van het doel van de webapplicatie. Samengevat kunnen de risico’s van de bedreigingen bij het ontbreken van genoemde maatregelen als volgt worden weergeven. In grafiek 1 is de impact en de probability (de waarschijnlijkheid) van alle bovengenoemde bedreigingen beschreven en in de volgende grafiek samengevoegd.

Grafiek 1. Er is onderscheid gemaakt tussen niet vertrouwelijke of niet financiële webapplicaties en vertrouwelijke of financiële webapplicaties. De reden hiervoor is dat de risico inschattingen afhankelijk zijn van het doel van de webapplicatie. Dit blijkt duidelijk uit grafiek 1.

56

De informatie die blijkt uit grafiek 1 vormt een raamwerk voor ontwikkelaars, acceptanten, security managers en auditors om de risico’s zichtbaar te maken. Voor iedere bedreiging zal vervolgens een afweging, door middel van een risicoanalyse gemaakt moeten worden, om te bepalen welke maatregelen getroffen dienen te worden. Dit zou al bij het ontwikkeltraject door de programmeur plaats moeten vinden. Echter in de praktijk wordt tijdens het ontwikkelproces veelal onvoldoende aandacht besteed aan security. Hierdoor kunnen webapplicaties zwakheden bevatten waardoor veiligheid niet kan worden gewaarborgd. Er dient in de acceptatieomgeving worden meegenomen in hoeverre tests van beveiligingsmaatregelen zijn toegepast tijdens de acceptatietestfase. De beveiligingsmaatregelen, beschreven in hoofdstuk drie, zouden altijd behandeld moeten worden als reguliere requirements en als zodanig deel moeten uitmaken van het acceptatie-test traject. Er dient periodiek een securityscan/webassessment te worden uitgevoerd om vast te stellen of de maatregelen daadwerkelijk zijn ingevoerd. Om 'in control' te zijn over het security management proces dient de verantwoordelijkheid voor dit proces eenduidig belegd te zijn. De hiervoor verantwoordelijke functionaris is verantwoordelijk voor het opstellen, implementeren en continue evalueren van dit proces. Het is van groot belang dat security management een integraal onderdeel wordt van het ontwikkelen acceptatieproces. In de werkprocessen zal security- en risicoanalyse dan ook moeten worden verankerd. Een andere punt is dat het security management richtlijnen dient op te stellen op het gebied van webapplicatie beveiliging. Deze dienen geborgd te worden in de organisatie. Aan de hand van deze richtlijnen kunnen auditors hun audits doen. Security management dient derhalve een vast onderdeel te worden van de webapplicatie cirkel. De webapplicatie cirkel zal er dan alsvolgt uitzien. (Figuur 13)

Figuur 13 Daarnaast dient binnen het ontwikkel-, acceptatie- en applicatie-traject, binnen het security management en auditing gebruik gemaakt te worden van de juiste tooling. Hierdoor kunnen de bedreigingen die aan het gebruik van webapplicaties kleven worden beperkt en/of tijdig worden gedetecteerd. Het toepassen van in deze thesis genoemde maatregelen is de basis voor een veilige en robuuste webapplicatie.

57

REFERENTIES

[Dam] Internet, intranet en beveiliging: het technisch kader P.P.A. van Dam, G. Hulst, H. van Hulst, Ir. H.A.M. Luijf, Dr. M.E.M. Spruit 1998 [Hunter] Passwords to protection: security, internet banking P. Hunter Computerweekly, june 1998 [Hugh and Lane] Web Database Applications with PHP & MySQL Hugh E. Williams, David Lane March 2002 [Mark Burnett] Hacking the Code May 2004 [Joost van Dijk] http://www.apache.nl/~jvd/paper.html [email protected] [Whiting] Web bank joins cutting edge of screen scraping R. Whiting Informationweek, march 2000 [Young] Online security threatens banks K. Young The banker, september 1999 [The Apache XML Project] The Apache Software Foundation, 2002 [Philippe Michiels] Webapplicaties Webapplicaties, van Java Front End tot XML Back End UIA 2001-2002 [Microsoft press] Secure programming code 2003 paperback [Slemko] [http://www.theregister.co.uk/2001/11/05/ms_passport_cracked_with_hotmail/]. [Microsoft press] Improve web application security. 2003 paperback

58

[Microsoft press] building secure asp_net applications http://www.microsoft.com/technet/security/topics/DevSecApps.mspx 2003 paperback [Mcclure] Ethcial Hacking Exposed Version 3.0 2002 Stuart Mclure Joel scambray [Walter Voell] Hackers blackboek 2003 Ingo Haese publishing [K , K. Dr ] Carlton Books, Ltd. 2002 [www.w3c.org] webservices Architecture, W3C, different editors [www.cert.org] CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests [DigiZen Security Group]. Dit bedrijf is failliet 2003 [Maatschappij- en Gedragswetenschappen (FMG)] Universiteit van Amsterdam 2003 [www.google.com] Frequently Asked Questions 2004 [www.Gartner group.com] Web applicatons and midleware 2004 [www.securiteam.com] Informatie over applicatie security en hacks.2004 [www.packetstromsecurity.org] Iinformatie over applicatie security en hacks 2004/ [WebCohort] http://www.imperva.com/company/news/2004-feb-02.html www.imperva.com] [www.owsap.org] The Open Web Application Security Project (OWASP) www.owsap.org Alt.comp.risks newsgroep [IBM DeveloperWorks – Web services] http://www-106.ibm.com/developerworks/webservices/

59

[General Microsoft .NET vision:] Microsoft .NET Homepage http://www.microsoft.com/net [.NET Developer] Center http://msdn.microsoft.com/net/ [Microsoft .NET Framework FAQ] http://msdn.microsoft.com/library/default.asp?URL=/library/techart/faq1117 00.htm [Articles published on MSDN Magazine] http://msdn.microsoft.com/msdnmag/issues/0900/http://msdn.microsoft.com/msdnmag/issues/1000/ [Microsoft .NET Framework Delivers the Platform for an Integrated, Service- Oriented Web,] by Jeffrey Richter http://msdn.microsoft.com/msdnmag/issues/0900/Framework/Framework.as p [The Programmable Web: Web Services Provides Building Blocks for the Microsoft .NET] Framework, by Mary Kirtland http://msdn.microsoft.com/msdnmag/issues/0900/WebPlatform/WebPlatfor m.asp [Visual Studio .NET: Build Web Apps Faster and Easier Using Web Services and XML, by] Dave Mendlen http://msdn.microsoft.com/msdnmag/issues/0900/VSNET/VSNET.asp [Sharp New Language]: C# Offers the Power of C++ and Simplicity of Visual Basic, by Joshua Trupin http://msdn.microsoft.com/msdnmag/issues/0900/csharp/csharp.asp [Active Server Pages+: ASP+ Improves Web App Deployment] Scalability, Security, and Reliability, by Dave Sussman http://msdn.microsoft.com/msdnmag/issues/0900/ASPPlus/ASPPlus.asp [Metadata in the Microsoft .NET - Avoiding DLL Hel] Introducing Application Metadata in the Microsoft .NET Framework, by Matt Pietrek http://msdn.microsoft.com/msdnmag/issues/1000/metadata/metadata.asp [NET Framework-Part 2: Microsoft .NET Framework Delivers the Platform for an Integrate] Service-Oriented Web, by Jeffrey Richter http://msdn.microsoft.com/msdnmag/issues/1000/Framework2/Framework2. asp [Develop a Web Service] Up and Running with the SOAP Toolkit for Visual Studio, by Rob Caron [http://msdn.microsoft.com/msdnmag/issues/0800/webservice/webservice.asp] [NET Framework, Visual Studio.NET, and ASP.NET Developer Resources] http://www.devx.com/dotnet/resources/default.asp [ISP Hosting on Microsoft .NET technology] http://www.brinkster.com

60

[www.microsoft.com] http://www.microsoft.com/netherlands/technet/security/bulletins/ms03-047.aspx http://msdn.microsoft.com/library/en-us/secmod/html/secmod92.asp http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch08.asp http://msdn.microsoft.com/msdnmag/issues/02/01/security/security0201.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/seccodeguide.asp. [A Comparative Overview of language C# (versus the language Java] http://www.genamics.com/visualj++/csharp_comparative.htm [Universal Description, Discovery and Integration (UDDI)] http://www.uddi.org/ http://uddi.microsoft.com/ [Biztalk] http://www.microsoft.com/biztalk http://www.microsoft.com/biztalk/techinfo/default.htm http://msdn.microsoft.com/msdnmag/issues/1100/BeyondASP/BeyondASP.a sp [Tunix} www.tunix.nl/ www.tunix/nav/frmdiensten.html [ASP.NET Community Sites] http://www.aspng.com/ http://www.aspnextgen.com/ http://www.aspworkshops.com/ http://www.4guysfromrolla.com/ http://www.aspfree.com/ http://www.asptoday.com/ http://www.asp101.com/ http://www.ibuyspy.com/ (Microsoft's own beta site, including full sample download) http://conventions.coe.int http://www.ster.be/lieven/ http://www.justitie.nl http://europa.eu.int/prelex http://europa.eu.int/comm/justice_home/news/intro/wai/news_intro_en.ht m http://www.cpbweb.nl http://staff.washington.edu/dittrich/ http://www.cisco.com/warp/public/707/newsflash.html http://www.opensourcefirewall.com/ddos_whitepaper_copy.html http://www.giac.org/practical/gsec/Ryan_Barnett_GSEC.pdf http://www.sans.org/rr/paper.php?id=478 http://www.cgisecurity.com/articles/xss-faq.shtml http://www.securityfocus.com/guest/17905 http://www.sans.org/rr/paper.php?id=567 http://www.giac.org/practical/gsec/Doug_Sax_GSEC.pdf http://www.giac.org/practical/gsec/Michael_Patrick_GSEC.pdf http://www.denialinfo.com/ http://www.geocities.com/SiliconValley/1947/Ftpbounc.htm http://www.cert.org/tech_tips/ftp_port_attacks.html http://www.sans.org/rr/paper.php?id=388 http://www.linuxsecurity.com/docs/LDP/Secure-Programs-HOWTO/ http://www.technicalinfo.net/papers/CSS.html. ObjectWatch Newletters (about middleware technology) http://www.objectwatch.com/Past_Issues.htm

61

BEGRIPPENLIJST Begrippen lijst zie www.vua.nl [Maatschappij- en Gedragswetenschappen (FMG)] Universiteit van Amsterdam 2003

62

BIJLAGE 1 Uitleg intrusion detectie en preventie systemen Host-based IDS (HIDS) Dit type systeem verzamelt en analyseert data, zoals systeem logbestanden, afkomstig van een computer waarop een service gehost is (bijv. een webserver). Voor deze specifieke host met een specifieke functie kan vervolgens bepaald worden of er afwijkend gedrag plaats vindt of heeft gevonden. Network-based IDS (NIDS) Een NIDS controleert alle activiteiten die plaats vinden in een bepaald netwerk door de daadwerkelijke packets op dat netwerk te analyseren. Deze pakketjes worden bekeken en vergeleken met empirische data om hun bedoeling te verifiëren. De technieken die hiervoor gebruikt worden zijn ondermeer packet-sniffing en connectie analyse in tegenstelling tot de HIDS die alleen gebruik maakt van logbestanden. Bovendien houdt de NIDS niet alleen een enkele host maar ook het gehele netwerk in de gaten. Application based IDS (AIDS) De Application based IDS controleert alleen specifieke applicaties in een netwerk zoals database management systemen, content management systemen, accounting systemen, etc. Aanvallen worden gedetecteerd door analyse van de specifieke applicatie log files. Deze systemen kunnen doorgaans vele verschillende aanvallen identificeren en soms zelfs tot de individuele gebruiker. Vaak kunnen ze ook met encrypted data werken, iets wat een HIDS of NIDS praktisch nooit kan. Het complementair inzetten van een combinatie van bovenstaande systemen verhoogt de bescherming van een netwerk aanzienlijk. In dat geval creëert men een uit verschillende lagen bestaande intrusions detection omgeving. Het spreekt voor zicht dat een dergelijke verhoging van de bescherming gepaard gaat met veel extra kosten waardoor analyse van prioriteiten, (eerst de NIDS, dan voor de belangrijkste hosts een HIDS en als laatste eventuele AIDS voor kritische applicatie), gewenst is.

63

BIJLAGE 2. Matrix uitleg In matrices 1 tot en met 6 wordt weergegeven of het aannemelijk is, dat er een risico aanwezig is, indien een bepaalde maatregelen uit hoofdstuk 3 niet wordt nageleefd. Daarbij wordt gebruik gemaakt van de risico classificatie low, medium en high. Er wordt onderscheid gemaakt tussen niet vertrouwelijke en/of niet financiële webapplicaties versus vertrouwelijke en/of financiële webapplicaties. In de linker kolom staat “Crosssite scripting”. Dit heeft betrekking op het ontbreken van “validatie input” als maatregel. De matrix is naar eigen inzicht en ervaring opgezet.

Threat = De bedreiging. Business Impact = De bedreiging dat er financiële of materiele schade ontstaat

voor een organisatie. Vulnerbility = Hoeveel tijd het kost om deze bedreiging uit te buiten. Likehood = De kans dat deze bedreiging gebeurt. Company continuity = Bedreiging voor de continuïteit van een organisatie. Company Image = Bedreiging van naam reputatie van een organisatie. Changes of destruction = Bedreiging dat er data wordt verwijderd of vernietigd worden. De gehanteerde “RISK” van de rechter kolom betekent risicoaanduiding en is hieronder verder uitgewerkt:

High (hoog) risico Deze risico’s zijn dermate significant dat ze onmiddellijk aandacht behoeven gezien de mogelijke omvang van het risico.

Medium (middel) risico

Deze risico’s behoeven niet de onmiddellijke aandacht, maar dienen de maatregelen tijdig te worden opgevolgd.

Low (laag) risico

Hierbij is sprake van een tekortkoming die geaccepteerd kan worden of die gecompenseerd kan worden door andere maatregelen.

thesis tue 2005

Documents

de maatregelen

de definitie

de bedreiging sql

de bedreiging session

de bedreiging code injection

adri de bruin ra

webapplicaties thesis

bedreigingen en maatregelen