Security web services Inleiding Tegenwoordig zijn er allerlei applicaties te benaderen via het internet. Voor bedrijven zorgt dit dat zei de klanten snel kunnen benaderen en aanpassingen voor iedereen in een keer worden toegepast. Hier zitten echter wel wat haken en ogen aan, zoals de veiligheid van het product. Hoe zorg je dat de gegevens van de klanten veilig zijn en niet in verkeerde handen vallen?
Risico’s Als je een applicatie op het web zet dan is het goed bereikbaar voor al je klanten. Het is echter ook goed bereikbaar voor personen die het eigenlijk niet mogen bereiken. De meest grote en veel voorkomende risico’s worden de OWASP top 10 genoemd. Dit is een lijst met aandachtspunten als je een web applicatie hebt.
OWASP top 10
Insecure data Storage Weak server side control Insufficient transport layer protection Client side injection Poor authorization & authentication Improper session handling Security decisions untrusted inputs Side channel data leakage Broken cryptography Sensitive information disclosure
Insecure data Storage, dit houd in dat data niet veilig word opgeslagen. Weak server side control, er ontstaan lekken in de beveiliging door rooten of jailbraiken.
Jeffrey van Wijck| 0837734
Insufficient transport layer protection, bij het versturen van data kun je er altijd van uit gaan dat er wordt meegekeken door anderen naar de data die door jou verstuurd wordt. Client side injection, hierbij word er door de gebruiker data ingevoerd die fouten kunnen veroorzaken in jou system. Poor authorization & authentication, je kan inloggen vanaf een pc zonder eigen credentials te gebruiken. Het is niet geregeld via de server maar op de client. Improper session handling, sessies moeten niet oneindig geldig zijn. Op die manier kan, als jij even weg bent van je pc, iemand anders via jou sessie nog bij de data. Security decisions untrusted inputs, het uitvoeren van gevoelige handelingen. Dit gebeurd als er geen controle is op de input van onbetrouwbare bronnen. Side channel data leakage, als gebruik wordt gemaakt van andere libraries dan kan het zijn dat er in de voorwaarden staat dat ze data mogen uitlezen. Broken cryptography, op het moment dat je zelf security algoritmes gaat schrijven is er een kans dat deze snel en gemakkelijk worden gekraakt. Sensitive information disclosure, belangrijke gegevens staan in de code weergegeven om het voor de ontwikkelaar gemakkelijker te maken.
Beveiliging Om de beveiliging van een web applicatie zo goed mogelijk op te bouwen zijn er een aantal stappen te nemen. De stappen worden
1
hieronder verder toegelicht.
Identificatie Dit is de eerste stap in het toegangscontrole proces van een applicatie. Een gebruiker moet zijn identiteit kenbaar maken aan de applicatie voordat er toestemming gegeven kan worden de applicatie te benaderen. Zodra een applicatie een identiteit binnenkrijgt van iemand die de applicatie wil gebruiken zal er een volgend proces in werking worden gesteld.
Authenticatie Dit is het proces waarbij gecontroleerd word of een gebruiker, pc of applicatie wel is wie hij beweert te zijn. Bij dit proces word gekeken of het opgegeven bewijs van identiteit overeenkomt met echtheidskenmerken. Denk hierbij aan credentials, bestaande uit een username en password combinatie.
Autorisatie De laatste stap voor de toegangscontrole is de autorisatie. In deze fase krijgt de aanvrager rechten op het benaderen van een object. Hierbij word vaak gebruik gemaakt van het principe dat je alleen mag zien wat je nodig hebt aan functionaliteit . Vormen zijn onder andere ook het Lees- recht en het Schrijf- recht. Afhankelijk van de functie of het object zijn er meerdere rechten beschikbaar. Bij applicaties bestaat ook het Uitvoer- recht.
Encryptie De volgende stap is het beveiligen van de gegevens om in te kunnen loggen. Als dit niet gebeurd, kunnen de credentials gebruikt worden door andere om alsnog op de beveiligde pagina te komen.
bestaat er nog een volgend probleem. Dit is dat bij het versturen van de credentials van de gebruiker, deze gemakkelijk onderschept kunnen worden door personen die dit eigenlijk niet moeten kunnen. Om dit te voorkomen zijn een aantal mogelijke manieren te bedenken.
Base 64 Een van die manieren is om de gegevens te versleutelen op een base64 gecodeerde manier. Hierbij worden de credentials versleuteld zodat ze niet direct af te lezen zijn. Opzicht is dit best handig en kan het goed werken, maar dan alleen tegen personen die er geen verstand van hebben. Een base64 gecodeerde reeks karakters is namelijk gemakkelijk terug te lijden tot de oorspronkelijke waardes. Iets wat niet handig is als je gegevens wil beschermen voor andere.
Tokens Een andere manier is het versleutelen van de credentials in wat beter beschermde tokens. In de tabel op de laatste pagina staat een overzicht van de drie meest gebruikte tokens als het gaat om het beveiligen van een web applicaties of web services. SAML Het SAML token is een token gebaseerd op XML. Het is wordt gebruikt bij web applicaties die gebaseerd zijn op het SOAP protocol. Het versturen van de SAML token gaat via de HTTP body of in de request URL.
Als een gebruiker in wil gaan loggen dan
Jeffrey van Wijck| 0837734
2
Representation Geared Toward Out-of-the-box WIF Support Protocols Typical Carrier Support for Signing
Support for Encryption
SAML XML SOAP Yes
SWT HTML Form encoding REST No
JWT JSON REST No
WS-Trust and WS-Federation Http body or URL
OAuth 2.0
OAuth 2.0
HTTP Auth header(bearer) Yes, HMAC SHA-256 using symmetric key No
HTTP Auth header(bearer) Yes, both symmetric and asymmetric signing Yes
Yes, asymmetric key X509 certificate Yes
SWT SWT oftewel "Simpel web token", is een token dat gebaseerd is op HTML form encoding. het bijbehorende protocol is het OAuth 2.0 protocol dat er voor zorgt dat het gemakkelijker is toe te passen in een web applicatie. Het versturen gebeurd niet zoals de base64 gecodeerde lijst karakters via de URL, maar in de HTTP header in de vorm van een bearer token. JWT Javascript web token is het laatste token. Deze is JSON gebaseerd. Net als het SWT kan het gemakkelijk worden gebruikt met het OAuth 2.0 protocol. Het versturen gebeurd net zoals de SWT, in de HTTP header in de vorm van een bearer token. Een trend die je ziet in het ontwikkelen van web applicaties is dat ze steeds vaker op REST gebaseerd zijn en steeds minder op SOAP. Dit houd in dat ook het gebruik van een SAML steeds minder vaak voorkomt. Dit heeft te maken met performance, de SAML is XML gebaseerd, wat een zwaarder bestand is dan een JSON bestand. Een keuze tussen een SWT en JWT hangt af van de soort applicatie die je gebruikt. Gebruik je een Java Script applicatie dan is een JWT
Jeffrey van Wijck| 0837734
aan te raden, omdat die gemakkelijker te implementeren is. Voor andere applicaties is een SWT een goede oplossing.
Algoritme Het soort token dat gecreëerd moet worden staat hierboven beschreven. Nu is het echter nog de bedoeling dat hier een algoritme voor gebruikt wordt. Gebruik een algoritme dat al bestaat. Vaak zijn alle fouten en leaks hier al uitgehaald. Het is al geperfectioneerd en bijgeschaafd waar nodig. Dit kan een hoop onnodige problemen voorkomen.
Transport Na het versleutelen van de credentials moet de token ook verstuurd worden om gecontroleerd te worden. Het zou niet uit moeten maken dat de token gelezen kan worden door personen die dit eigenlijk niet mogen. Zonder een sleutel om de token terug te vormen naar de oorspronkelijke data kunnen ze er niks mee. Toch kan het zo zijn dat de code gekraakt wordt en ze toegang krijgen tot de data, die je eigenlijk veilig wil houden. Dit is mogelijk wanneer je gebruikt maakt van HTTP.
3
HTTP HTTP is een protocol voor de communicatie tussen een web client en een webserver. Het is een protocol dat niet alleen in het world wide web(www) word gebruikt, maar ook in lokale netwerken (intranet). In de HTTP staat vastgesteld wat voor soort request een client kan doen aan een server. Er staat ook in wat voor een response de server kan geven aan de client.
Denk hierbij aan een vaste tijd waarop een sessie verloopt en een gebruiker opnieuw in moet loggen om weer gebruik te kunnen maken van de applicatie. Dit geld ook voor de tokens die op dat moment actief zijn. Ook moet niet overbodig veel informatie worden opgeslagen. Alleen vereiste data moet worden opgeslagen en dan moet dit niet gebeuren op een shared of public locatie.
HTTPS
Invoer
HTTP is dus nog steeds niet geheel veilig om gegevens over te versturen. In plaats hiervan kan HTTPS worden toegepast. De “s” staat voor “secure”. Dit is hetzelfde protocol als HTTP, maar dan beveiligd.
Om de beveiliging van een web applicatie verder te verbeteren is er nog een stap die gezet kan worden.
Het is een normale verbinding, net zoals HTTP, bovenop een SSL- verbinding. Voor een SSLverbinding moet een certificaat worden aangeschaft. Dit is een certificaat dat jaarlijks betaald moet worden. Dit kan varieren van een enkel domein tot een domein inclusief de sub domeinen. De SSL-verbinding zorgt er voor dat de data versleuteld is. Dit maakt het onmogelijk om de data, als deze onderschept wordt, uit te lezen zonder het encryptie-algoritme te kraken. De persoon die de data moet ontvangen kan dit wel doen met de juiste sleutel.
Sessies Een andere stap in het beveiligen van een web applicatie is het onder controle houden van sessies. Als een gebruiker inlogt dan wil je niet dat deze dat bij elke actie opnieuw moet doen. Het gebruik van een sessie is dus een logische keuze. Dit moet echter wel op een juiste manier gebeuren om misbruik te voorkomen.
Jeffrey van Wijck| 0837734
Dit heeft te maken met de invoer van data. De gebruiker kan soms input geven, maar er kan ook data vanuit een niet vertrouwelijke bron komen. Om het invoeren, van foutieve data, door de gebruiker tegen te gaan is het gebruik van “string parameters”. Dit voorkomt dat er data ingevoerd kan worden die opdrachten uit gaat voeren die schadelijk kunnen zijn voor de applicatie. Om data van niet vertrouwelijke bronnen te weren kan het beste een check worden toegevoegd. Hierop moet een gebruiker toestemming geven. Vaak word dit gedaan met het invoeren van een tekst die in een plaatje staat weergegeven. Dit is om te bevestigen dat het niet om een zoek robot gaat die er voor gemaakt is om applicaties te zoeken en van schadelijke data te voorzien.
Data opslag De opslag van data is geen probleem. In sommige gevallen is het zelfs noodzakelijk. Het is echter wel dat dit op een bepaalde manier moet gebeuren. Sla data nooit op in een public of een shared locatie. Op deze
4
manier wordt het anders wel erg makkelijk gemaakt voor personen, die er geen recht op hebben, om het in handen te krijgen. Ook is het, net als eerder al genoemd werd, van belang dat alleen vereiste data worden opgeslagen. Sla bijvoorbeeld nooit wachtwoorden op, dit kan alleen maar misbruikt worden. Als iemand zijn wachtwoord vergeet dan krijgt diegene wel een nieuwe.
Het gebruik van HTTPS is iets wat ook zeker een plus kan zijn voor het beveiligen van je web applicatie. Maar nogmaals, hier moet je goed over nadenken of dat nodig is. Om dit te gebruiken heb je een certificaat nodig waarvoor je moet betalen en als de data, die je wil beschermen, niet veel is dan kan het ook overbodig zijn.
Verder is het van belang dat er geen gegevens/ data in de code komt te staan. De code is terug te halen, zelfs na het compileren. Dit houdt in dat dus ook de gegevens en data die hier in staat is op te halen.
Conclusie Om de gegevens van klanten veilig te houden en te zorgen dat de applicatie die zei gebruiken ook blijft werken zijn dus genoeg maatregelen voor te nemen. Wat hierbij belangrijke stappen zijn, zijn om te kijken op wat voor manier je de applicatie gaat ontwikkelen. Er moet ook gekeken worden naar water belangrijk is op het gebied van gebruik. Vervolgens moet worden bepaald met wat voor soort data je te maken hebt en wat de belangrijke data is die extra beschermd moet worden. De encryptie is ook zeker een onderdeel dat niet mag ontbreken in het beveiligen van een web applicatie.
Jeffrey van Wijck| 0837734
5
