Dinsdag kwamen met het eerste deel van "Webservices Security – Moving up the stack!". In dit uitgebreide artikel beschrijft Vincent Alwicher de de nieuwe bedreigingen en uitdagingen van Webservices technologie.

Nieuwe bedreigingen en uitdagingen
Er zijn drie belangrijke gevaren te onderkennen:

1. Webservices interfaces etaleren meer functionaliteit dan klassieke webapplicaties en bieden daarmee potentieel meer mogelijkheden tot fouten of misbruik;
   
2. Traditionele technische beveiligingsmaatregelen bieden niet voldoende bescherming;
   
3. Webservices (security) technologieën zijn volop in ontwikkeling.

1) Webservices etaleren meer functionaliteit
Webservices technologie maakt het makkelijker om kritieke data en business processen aan de buitenwereld bloot te stellen. Het verhoogt de risico’s die organisaties lopen indien er geen adequate maatregelen worden genomen. De beveiliging van Webservices wordt dan ook gezien als het grootste obstakel voor algemene acceptatie van Webservices door de markt en voor wereldwijd gebruik van deze technologie op open publieke netwerken.
Er is een fundamenteel verschil tussen het gebruik van traditionele webtechnologieën en Webservices technologie. De toegangscontrole tot de meeste webgebaseerde toepassingen is proactief, terwijl Webservices toegangscontrole in de regel reactief is. Een traditionele webapplicatie bestaat vaak uit twee of meer lagen. De HTML weblaag op een webserver geeft ingevoerde informatie door aan een applicatieserver in een andere laag. De weblaag fungeert als filter en zal geen interne functies van de applicatie adverteren, toegankelijk maken of anderszins blootstellen. De applicatieserver zal er simpelweg voor zorgen dat alleen geautoriseerde functies toegankelijk zijn. Een Webservice heeft echter helemaal geen webserver nodig om ontsloten te kunnen worden. Een Webservice is veel meer geïntegreerd met de applicatie en, zonder de juiste maatregelen te nemen, rechtstreeks adresseerbaar voor iedere cliënt en alle beschikbare functies van de Webservice (SOAP endpoint) worden door middel van WSDL en het XML schema publiekelijk gemaakt. Bedrijfsgevoelige informatie en structuren kunnen op deze manier veel eenvoudiger blootgesteld worden, met alle gevaren van dien (zie figuren 3 en 4).

Figuur 3. “Waltzing Through Port 80…?”

Figuur 4. Webservices interface blootstelling

2) Huidige beveiligingsmaatregelen bieden onvoldoende bescherming
Voor Webservices beveiliging zijn traditionele maatregelen zoals firewalls niet voldoende om het gevaar te stoppen. Er moet onderscheid gemaakt worden tussen bestaande TCP/IP transportprotocollen en de nieuwe Webservices protocollen. Met de eerste set bestaat al heel veel ervaring en er zijn afdoende maatregelen (firewalls, proxies, IDS/IPS, etc) om bekende aanvallen tegen te gaan. Het gevaar zit echter in de nieuwe generatie XML en Webservices protocollen die zich allemaal bevinden in de applicatielaag van het TCP/IP model. Figuur 5 geeft de verhouding weer tussen de TCP/IP stack en de Webservices stack. Eigenlijk is de Webservices stack helemaal geen stack. Alle lagen bevinden zich op hetzelfde niveau, namelijk de TCP/IP applicatielaag. Daarnaast moet er ook een nuance worden gemaakt tussen protocollen en talen (dit valt buiten de scope van dit artikel en figuur 5 is daarom een simplistische voorstelling van zaken).
Een van de gevaren is dat SOAP berichten eigenlijk gewoon “getunneld” worden via een transportprotocol zoals HTTP (figuur 3). Zoals hiervoor beschreven kunnen deze berichten RPC’s bevatten die ook direct uitgevoerd kunnen worden. Volgens statistieken van SANS en CERT zijn RPC-gebaseerde services vaak kwetsbaar voor aanvallen en virussen, zoals bijvoorbeeld het MS-Blaster worm in zomer 2003 heeft bewezen. Traditionele netwerkfirewalls zullen dit “tunnelen” niet opmerken. Natuurlijk zijn er tegenwoordig geavanceerde firewalls die tot en met de hoogste laag in de applicatieprotocollen kunnen kijken, maar het is niet voldoende om te detecteren dat er XML berichten je firewall passeren. Er bestaat grote behoefte om op basis van de inhoud van deze XML berichten toegangscontrole uit te voeren en andere beveiligingsmaatregelen te nemen.

Figuur 5. TCP/IP stack versus Webservices stack

Webservices introduceren ook een aantal nieuwe uitdagingen. Het “losjes-gekoppelde” karakter van Webservices zorgt er voor dat er gedistribueerde applicaties ontstaan die services of gegevens betrekken van andere Webservices. De uitdaging is nu om in zo’n complexe gedistribueerde omgeving security te abstraheren van de onderliggende infrastructuur. Daarnaast moet er security sessie-informatie onderhouden kunnen worden over de verschillende Webservices heen. Hierbij moet de vertrouwelijkheid, integriteit, authenticiteit en onweerlegbaarheid gewaarborgd kunnen worden van zowel de sessie- als de transactiedata. Een transactie kan bijvoorbeeld vereisen dat voor bepaalde elementen van een XML bericht de vertrouwelijkheid gewaarborgd moet zijn. Verschillende partijen kunnen bewerkingen uitvoeren op diverse elementen van het bericht, behalve op het versleutelde element dat exclusief voor maar één partij toegankelijk is. Voorbeeld: Bij de aankoop van een product in een webwinkel zal de financiële afhandeling met de creditcardmaatschappij plaatsvinden via SOAP/XML berichten waarbij de creditcardgegevens in een versleuteld element zijn verpakt die alleen leesbaar is voor de creditcardmaatschappij (zie figuren 6 en 8).

Figuur 6. Voorbeeld Webservices & multi-hop topologie

Binnen een complexe Webservices infrastructuur kunnen verschillende SOAP endpoints aanwezig zijn, die fysiek weer op verschillende locaties worden gehost door diverse organisaties. Een Webservice kan opereren in naam van een eindgebruiker. Delegatie en het in naam van de gebruiker acteren (impersonation) door een Webservice betekent een extra uitdaging. Ten slotte is het bestaan van een diversiteit aan authenticatiemethoden en de vele identiteiten en rollen die gebruikers tegenwoordig hebben een grote uitdaging. Vrijwel alle authenticatie- en autorisatieproducten in de markt focussen sterk op mens-machine interactie. In de Webservices wereld is er veel meer machine-machine interactie. Dit stelt andere eisen aan hoe vertrouwensrelaties tussen Webservices worden vastgesteld en opgezet.
,Nieuwe Webservices security initiatieven
Een veelgestelde vraag als Webservices security ter sprake komt is: Is SSL niet voldoende? Secure Sockets Layer is een point-to-point oplossing en kan in sommige situaties zeker voldoende bescherming bieden. Met name in een omgeving waar maar twee Webservices met elkaar communiceren. In een grote multi-hop omgeving is end-to-end security noodzakelijk. In dat geval biedt SSL niet voldoende bescherming. Een bericht kan bijvoorbeeld stoppen op verschillende SOAP endpoints, verwerkt worden en dan weer doorgestuurd worden naar een volgend endpoint (zie figuren 6 en 8). Het is mogelijk dat bepaalde elementen uit het bericht niet door alle endpoints ingezien mogen worden. Om de vertrouwelijkheid en integriteit te waarborgen is versleuteling en integriteitcontrole in het bericht zelf noodzakelijk. SSL is alleen maar een oplossing waarmee de transportlaag kan worden beveiligd en waarmee server- en/of clientauthenticatie wordt geleverd. Zodra het bericht een endpoint heeft bereikt komt deze uit de SSL tunnel en zal dan onbeschermd binnen de endpoint (Webservice) beschikbaar zijn. Het is dan voor een aanvaller mogelijk om het bericht ongemerkt aan te passen en weer door te sturen naar de volgende endpoint in de keten.

Het niet voldoen van SSL vraagt dus om andere oplossingen. W3C en OASIS zijn twee verschillende, onafhankelijke standaardisatieconsortiums die werkgroepen hebben opgericht om de standaardisatie van nieuwe Webservices security protocollen te stroomlijnen (figuur 7). Deze nieuwe protocollen worden veelal door fabrikanten ontwikkeld en vervolgens door W3C, OASIS of een andere onafhankelijke partij verder ontwikkeld. Een van de belangrijkste initiatieven is door Microsoft, IBM en Verisign geïntroduceerd: WS-Security. Het eigenaarschap van dit protocol is in 2004 overgedragen aan de OASIS Security Joint werkgroep.

Figuur 7. Overzicht relaties tussen de verschillende security standaarden

XML Signature, XML Encryption en XKMS
Het W3C consortium heeft tezamen met IETF drie oplossingen gestandaardiseerd, te weten XML Signature, XML Encryption en XKMS. Dit zijn op XML-gebaseerde protocollen die de integriteit, authenticiteit, onweerlegbaarheid en vertrouwelijkheid kunnen waarborgen van ieder type data, XML bericht of delen van XML berichten (figuur 8).

Figuur 8. Point-to-point security versus end-to-end security en de daarbij behorende technologie

Deze initiatieven zijn de belangrijkste bouwblokken voor alle andere Webservices security protocollen. Alle drie de oplossingen introduceren géén nieuwe cryptografische algoritmes, maar maken gebruik van bestaande algoritmes zoals DSA, RSA, Diffie Hellman, DES, 3DES, AES en SHA-1. Ook zijn ze afzonderlijk te gebruiken en hoeven ze niet noodzakelijkerwijs in een Webservices omgeving gebruikt te worden.

XML Signature biedt de mogelijkheid biedt om over delen van een bericht verschillende handtekeningen te plaatsen, met als doel de integriteit te waarborgen. Het is belangrijk te onderkennen dat XML Signature in technische zin gebruikt kan worden om persoonsgebonden digitale handtekeningen te zetten, maar dat de koppeling met de identiteit van de gebruiker buiten de scope van het protocol valt. W3C meldt dit expliciet in de specificaties. Het koppelen van een eindgebruiker aan een digitale sleutel is een beslissing die in de applicatie moet plaatsvinden, aldus W3C.

Zonder credential- en sleutelmanagement hebben XML Signature en XML Encryption weinig zin. Er is een koppeling noodzakelijk met een PKI (Public Key Infrastructure) omgeving. Deze gestandaardiseerde interface wordt geleverd door XKMS (XML Key Management Services). XKMS specificeert methodes om XML-gebaseerde clients op een veilige manier gebruik te laten maken van public key gerelateerde diensten, zoals: lokalisatie, generatie, registratie, validatie en intrekking van sleutels en credentials (figuur 9). Het specifieke is dat deze communicatie plaatsvindt in XML formaat. XKMS ondersteunt verschillende type credentials, zoals bijvoorbeeld X.509 en PGP certificaten. XKMS is puur gericht op de managementaspecten van PKI en kent verschillende voordelen. XKMS schermt applicaties af van de complexiteit van een PKI. Een deel van de PKI complexiteit wordt verplaatst van de client naar een XKMS server. Op deze manier worden applicatieontwikkelaars in staat gesteld om PKI functies te gebruiken met alleen maar de kennis van wat het PKI systeem doet, maar niet hoe het PKI systeem het doet. Hiermee wordt PKI transparanter voor applicatieontwikkelaars, waardoor het eenvoudiger te gebruiken is. Verder worden cliënts “dunner” met als gevolg dat PKI technologie eenvoudiger kan worden geïmplementeerd in mobiele apparaten. Een XKMS client hoeft namelijk niets te weten van specifieke standaarden zoals PKIX, PGP, ASN.1, et cetera. Een XKMS client stuurt simpele XML-geformateerde verzoeken naar een centrale XKMS Server, die deze vervolgens vertaalt naar specifieke PKI protocollen. In figuur 9 is dit in beeld gebracht.

Figuur 9. PKI thick client architectuur versus PKI thin client architectuur met XKMS

Daarnaast komt het ten goede van de interoperabiliteit. Met XKMS wordt het eenvoudiger om PKI producten van verschillende fabrikanten te integreren. Er zijn geen aparte fabrikantspecifieke PKI plugins meer benodigd voor ieder ingezette PKI oplossing.
Het is belangrijk te onderkennen dat het daadwerkelijk uitvoeren van cryptografische functies een applicatieve aangelegenheid blijft en dit valt dus buiten de scope van het XKMS protocol.

Morgen gaat Vincent Alwicher dieper in op SAML en XACML en WS-Security