Zoeken
Generic filters
nl Dutch
Zoek op rubiek

Verbeteren van de beveiliging van op maat web-applicaties.

Vaak denken bedrijven dat zijn webapplicaties goed beveiligd zijn waar ze toch vaak vergeten belangrijkste veiligheidsrisico’s te verhelpen. Er worden veel web-applicaties ontwikkeld door diverse bedrijven. Binnen deze bedrijven zijn er soms veel werknemers met verschillende niveau van programmeren. De beveiliging is niet altijd het meest en best aangepakte onderdeel bij het ontwikkelen van een applicatie. Er worden veel applicaties ontwikkeld waar de applicatie niet goed is beveiligd. Zelfs de meest voorkomende beveiligingsaanvallen worden niet gedicht bij de applicaties.

Dit artikel verteld informatie over de meest voorkomende beveiligingsaanvallen voor webapplicaties en hoe deze aanvallen beveiligd kunnen worden. Dit artikel is dus gefocust op het verbeteren van de meest voorkomen top beveiligingsaanvallen. Door dit onderdelen die ik op zal noemen in dit artikel te realiseren kan een webapplicaties zo eenvoudig mogelijk – goed (genoeg) – beveiligd worden.

Door te lezen van dit artikel hoop ik bedrijven op de hoogste te stellen van de meest voorkomende beveiligingsaanvallen en de oplossingen ervan.

Hoofdvraag:
“Ik onderzoek de meest voorkomende beveiligingsaanvallen, omdat ik wil weten hoe deze voorkomen kunnen worden teneinde een verbetering te zijn om een beter beveiligde webapplicaties te ontwikkelen?”

Met dit artikel geef ik aandacht naar de meest voorkomende beveiligingsaanvallen en hoe deze aanvallen voorkomen kunnen worden die relevant zijn voor de bedrijven. Er zijn veel soorten beveiligingsaanvallen die vaak voorkomen bij webapplicaties zoals injection, broken authentication and session management, cross-site scripting enzovoorts. Daarbij worden de top tien voorkomende beveiligingsaanvallen en de oplossingen per beveiligingsaanvallen in kaart gebracht.
Voor de meest voorkomende beveiligingsaanvallen zal gebruik gemaakt worden van de literatuur die beschikbaar is binnen OWASP. Open Web Application Security Project (OWASP) is een open source-project rond computerbeveiliging. Individuen, scholen en bedrijven delen via dit platform informatie en technieken.

Uit een kort vooronderzoek naar de OWASP top tien beveiligingsaanvallen zijn de volgende meest voorkomende beveiligingsaanvallen vastgesteld. Dit is een overzicht van de kwetsbaarheden die onder beveiligingsexperts worden gezien als het meest kritisch met betrekking op de webapplicaties. Het is geen compleet lijst met alle beveiligingsaanvallen. Het OWASP Top 10 project is een lijst van de 10 gevaarlijkste en meest voorkomende veiligheidsrisico’s op het internet, gebaseerd op meer dan 500000 kwetsbaarheden in meer dan 1000 applicaties [fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][1].

Hieronder zal ik beschrijven welke deze meest voorkomende veiligheidsrisico’s zijn, wat deze inhouden en hoe deze eventueel voorkomen kunnen worden bij de webapplicaties die ontwikkeld worden.

1. Injection

Dit is het meest voorkomende beveiligingsaanval. Injection ook wel SQL-injectie genoemd is een methode om aanvallen te verrichten naar SQL-gebaseerde databases via een webapplicatie.

Hoe werkt een injection dan precies?

Door binnen een webapplicatie in een formulier een aanpassing te doen kan hacker toegang krijgen tot de database als deze niet goed beveiligd is. Bij een SQL-injectie wordt een webapplicatie gekraakt om een achterliggende database bloot te leggen. Door bepaalde vragende query’s toe te passen, kan een hacker ervoor zorgen dat een database onbedoeld gevoelige data begint op te hoesten. Die gevoeligheid ontstaat doordat de database ontworpen is om via een webapplicatie (legitieme) commando’s te verwerken die (onschuldige) gegevens toont.

Een SQL-injectie heeft tot gevolgen dat hackers bedrijfsdata kunnen ontvreemden zoals intellectueel eigendom of klantgegevens. Ook kan het wachtwoord van de beheerder achterhaald worden, waardoor de hacker de backend database in zijn geheel kan overnemen en er bijvoorbeeld een malware-applicatie in kan plaatsen. Tot slot is ook het platleggen of omvormen (defacing) van de website mogelijk [2].

Hoe kan je ”Injection” beveiligen?

Allereerst kun je een SQL-injectie voorkomen door variabelen in de SQL-query niet te isoleren of te quoten. GET en POST variabelen (dynamisch SQL) dienen niet in query’s voor te komen. Werk liever met reguliere expressies en kijk naar het gebruik van de Escape-string. Dat laatste kun je automatiseren door prepared statements te gebruiken [2].

2. Broken Authentication and Session Management

Veel websites voorzien een mechanisme waarmee men zich kan inloggen, het geen vaak werkt met behulp van cookies, kleine gegevenspakketjes die worden opgeslagen op de computer. Sessie cookies kunnen gebruikt worden om een bepaald ID in op te slaan, wat de website vervolgens gebruikt om een bezoeker te identificeren. Als men het ID van een bepaalde bezoeker kan achterhalen kan men zich voordoen als die bezoeker en toegang krijgen tot diens gegevens [3].

Doordat bijvoorbeeld een webapplicatie niet via een beveiligde SSL-verbinding communiceert of vatbaar is voor Cross-Site Scripting, zou een kwaadwillende bijvoorbeeld cookies kunnen onderscheppen met de benodigde Session informatie. Met die informatie zou de aanvaller de sessie kunnen overnemen (Session Hijacking). [1]

3. Cross-Site Scripting (XSS)

Websites kunnen scripts bevatten die in de browser worden uitgevoerd, bijvoorbeeld JavaScript. Deze zorgen er bijvoorbeeld voor dat dynamische handelingen mogelijk zijn zoals het tonen van nieuwe meldingen op Facebook. Indien men de website niet goed beveiligt, is het mogelijk dat een kwaadwillige gebruiker zelf scripts kan toevoegen, bijvoorbeeld om de sessie cookie van iemand anders te stelen [3].

Uit een scan uitgevoerd door een Amerikaans beveiligingsbedrijf in 2009 bleek dat 39% van de onderzochte websites niet beveiligd was tegen cross-site scripting [4].

Hoe kan je “Cross-Site Scripting” beveiligen?

Het belangrijkste begin van een oplossing is dat je je webapplicatie kent. Overal waar een bezoeker informatie of bestanden kan meegeven in de URL (of informatie, als $_GET-, $_POST- of $_REQUEST-variabele), moet je bepalen of de bezoeker dat op die plek mag, en (zo ja) wat hij precies mag. Overal waar een bezoeker informatie achter kan laten op de website.
Je kunt bestanden of informatie uitsluiten van opname. Men noemt dat een blacklist. Echter, de mogelijkheden zijn ontelbaar en daarom kun je het beste opgeven wat wel opgegeven mag worden (een whitelist genaamd) [5].

4. Insecure Direct Object Reference

Vaak bevatten websites onderdelen die niet publiek toegankelijk zijn voor iedereen. Er moeten dus veilige mechanismen aanwezig zijn die ervoor zorgen dat deze afgeschermd blijven van iedereen zonder de juiste toestemming [3].
Een klant kan bijvoorbeeld zijn eigen factuur bekijken via de link: “https://www.example.com/?factuur=1234”. Maar zodra de eindgebruiker het getal “1234” aanpast krijgt hij het factuur te zien van iemand anders. [1]

Hoe kan je “Insecure Direct Object Reference” beveiligen?

Er zouden sterke toegangscontrole mechanismen aanwezig moeten zijn die de rechten van een bezoeker nagaan en die aftoetsen of hij de resource mag bekijken.

Deze risico kan echter gemitigeerd worden door gebruikt te maken van goede toegangscontrole mechanismen. Enkel het verbergen van functionaliteit niet voldoende. Er moeten achterliggend in het systeem ook sterke mechanismen aanwezig zijn die nagaan welke rechten een bepaalde gebruiker heeft en of hij de juiste rechten heeft voor het uitvoeren van bepaalde acties [6].

5. Security Misconfiguration

Goede beveiliging vereist een correcte configuratie die wordt afgestemd op de applicatie, frameworks, applicatieserver, webserver, databaseserver en platform. Beveiligingsinstellingen moeten worden gedefinieerd, geïmplementeerd en onderhouden omdat deze standaards vaak onveilig zijn. Daarnaast moet alle software up-to-date zijn [7].
Doordat bijvoorbeeld onnodige features ingeschakeld zijn, de standaard gebruikersnaam en wachtwoord nog actief zijn of bij een fout een uitgebreide “foutrapportage” wordt laten zien, heeft een aanvaller respectievelijk meer invalshoeken, mogelijkheid om te authentiseren of extra informatie over de werking van de webapplicatie [1].

Hoe kan je “Security Misconfiguration” beveiligen?

Hierbij aantal belangrijke punten die relevant zijn voor Security Misconfiguration:
– Verzekeren dat de software up-to-date is (besturingssysteem, web or app server, database-, code bibliotheken, enz.)
– Het uitschakelen of verwijderen van onnodige functies, havens, diensten, pagina’s, rekeningen of privileges.
– Foutafhandeling configureren en stacktraces voorkomen.
– Het begrijpen en correct configureren van beveiligingsfuncties.
– Het ontwikkelen van een herhaalbaar verharding proces en een proces voor het houden van op de hoogte over de nieuwste software releases en ze te installeren op een snelle manier.
– Implementeren van een software-architectuur die de beveiliging handhaaft tussen softwarecomponenten
– Met behulp van periodieke scannen en software audits om onjuiste en ontbrekende updates te detecteren.
– Het verwijderen van een achterdeur accounts, speciale wijze of onjuiste instellingen van de rechten.
– En verzekeren dat de instellingen in de configuratie bestanden zijn beveiligd.

6. Sensitive Data Exposure

Veel applicaties beschermen gevoelige gegevens onvoldoende. Denk hierbij aan creditcardnummers, belasting-id’s en autorisatiegegevens. Kwaadwillende kunnen deze stelen of wijzigen voor creditcardfraude, identiteitsdiefstal of andere misdrijven. Gevoelige gegevens moeten extra worden beschermt door middel van versleuteling of andere speciale voorzorgsmaatregelen.
Als een kwaadwillende op de een of andere manier toegang heeft tot de database of een kopie/back-up hiervan, kan men alle data inzien. Vaak bevatten databases gevoelige data zoals login gegevens, credit card gegevens, BSN-nummers van klanten, telefoonnummers, etc. [1]

Hoe kan je “Sensitive Data Exposure” beveiligen?

De eerste punt dat relevant is het selecteren van de gegevens die extra beveiligd moeten worden. Vervolgens kunnen voor deze gegevens de volgende punten belangrijk zijn:
– Alle gegevens encrypted inclusief de back-ups van deze gegevens.
– Alle internet verbindingen moeten geencrypt zijn
– Een streng encryptie algoritmiek moet gebruikt worden.
– Juiste browser richtlijnen en headers moeten ingesteld zijn ter bescherming van gevoelige gegeven die door verzonden worden naar de browser.

7. Missing Function Level Access Control

De meeste applicaties controleren autorisaties voordat de gevraagde data zichtbaar wordt in de gebruikersinterface. Applicaties moeten echter bij elke functie die wordt benaderd dezelfde controle uitvoeren op de server. Indien deze niet worden geverifieerd, zijn aanvallers in staat om verzoeken na te bootsen die toegang geven tot functionaliteit waarvoor zij geen autorisatie hebben.

Hoe kan je “Missing Function Level Access Control” beveiligen?

Dit aanval is sterk gerelateerd aan Insecure Direct Object References maar meer gericht is functionaliteit. De oplossing van dit is zelfde als van Insecure Direct Object References.

8. Cross-Site Request Forgery (CRFS)

Een CSRF aanval dwingt de browser van een aangemelde slachtoffer om een vervalst HTTP-verzoek naar een kwetsbare webapplicatie te verzenden, inclusief sessie-cookie en autorisatie-gerelateerde informatie. Hierdoor kan de hacker de browser dwingen om verzoeken te genereren waarvan de kwetsbare applicatie denkt dat ze legitiem zijn.

Als een niets vermoedende gebruiker op een besmette site komt, die onderwater verzoeken stuurt naar bijvoorbeeld een social-network site om een “update” te plaatsen en deze gebruiker heeft in een ander tabblad/zelfde browser-sessie nog ingelogd bij die social-network site, zal er een “update” worden geplaatst als die gebruiker zijnde [1].

Hoe kan je “Cross-Site Request Forgery” beveiligen?

CSRF kwetsbaarheden worden meestal verholpen door zogenaamde anti-CSRF tokens, de welke aan de gebruiker gekoppeld zijn en meegestuurd worden bij het uitvoeren van bepaalde kritieke functionaliteit. Indien een verzoek geen correct token bevat, wordt het genegeerd [6].

9. Using Components with Known Vulnerabilities

Dit is misschien wel de meest voor de hand liggende kwetsbaarheid: gebruik maken van bekende lekken. Vele webapplicaties bestaan uit meerdere componenten die extra functionaliteiten bieden, waardoor de programmatuur door vele derden partijen ontwikkeld zijn. Als er bekend wordt dat er kwetsbaarheden zijn, kan men deze makkelijk opzoeken en misbruiken [1].

Hoe kan je “Using Components with Known Vulnerabilities” beveiligen?

Het is van groot belang dat de componenten worden nagezien op beveiliging voordat ze beschikbaar worden gesteld aan het publiek. Daarnaast is het ook belangrijk dat deze blijvend onderhouden worden door de ontwikkelaar, zodat eventuele veiligheidsrisico’s opgelost worden. Het blijft wel aan degene die de website onderhoudt om alle toegevoegde componenten up to date te houden zodat de website veilig blijft [6].

10. Unvalidated Redirects and Forwards

Applicaties leiden gebruikers vaak naar andere pagina’s en websites en gebruiken niet gevalideerde gegevens om de bestemming hiervan te bepalen. Zonder de juiste validatie kunnen aanvallers slachtoffers omleiden naar phishing- of malware sites of forewards gebruik voor toegang tot ongeautoriseerde pagina’s.

Stel een klant krijgt in zijn mailbox een link om zijn bestelling te bekijken “https://www.example.com/?order=1234”. De sessie is al enige tijd verlopen dus de klant moet opnieuw inloggen, komt op de pagina “https://www.example.com/?login&redirect=https://www.example.com/?order=1234”. Zodra de klant ingelogd is zal de website de klant doorsturen naar “https://www.example.com/?order=1234” zoals dat netjes in de URL staat. [1]

Hoe kan je Unvalidated Redirects and Forwards beveiligen?

Er moet voorzichtig met deze omleidingen omgegaan worden, zeker indien de omleidingslocatie gebaseerd is op gegevens die door de gebruiker kunnen worden aangepast (bijvoorbeeld in een GET parameter van de URL). Er moet vooral opgepast worden indien deze omleidingslocatie een extern domein betreft. De webpagina op deze externe locatie zou mogelijk gegevens kunnen stelen van de gebruiker. Verder moet er opgepast worden dat de gebruiker de juiste rechten heeft om naar de pagina omgeleid te mogen worden. Anders zou het bijvoorbeeld mogelijk kunnen zijn dat de toegangscontrole mechanismen omzeild kunnen worden en er rechtstreeks toegang verstrekt kan worden tot administratieve functionaliteit [6].

Conclusie

Geen één applicatie kan 100% beveiligd worden omdat er te veel verschillende soorten aanvallen kunnen zijn en zullen ontstaan in de toekomst. Maar door te analyseren van de meest voorkomende aanvallen en deze te beveiligen of voorkomen kan een groot deel van de aanvallen geblokkeerd worden. Hierdoor is het webapplicatie veiliger en betrouwbaarder.

Aanbeveling

Om een beter beveiliging te hebben is het wel aan te raden om te kijken naar de overige bekende beveiligingsaanvallen die van toepassing kunnen zijn op het webapplicatie.

Bibliografie

[1] ICT Radar, „Info over hacken,” 2013. [Online]. Available: https://ict-radar.nl/info/hack_info. [Geopend 15 Juni 2014].
[2] K. v. Tuil, „Wat is een SQL-injectie?,” 28 September 2011. [Online]. Available: https://computerworld.nl/beveiliging/75015-wat-is-een-sql-injectie. [Geopend 6 Juni 2014].
[3] S. Bottelbergs, „De veiligheid van WordPress, Joomla en Drupal onder de loep,” 2013. [Online]. Available: https://www.scriptiebank.be/scriptie/comparative-study-security-open-source-web-content-management-systems. [Geopend 6 Juni 2014].
[4] Redactie, „60% websites bevat ernstig beveiligingslek,” Security.nl, 20 Mei 2009. [Online]. Available: https://www.security.nl/posting/25165/. [Geopend 15 Juni 2014].
[5] J. Reilink, „Cross site scripting (XSS) beveiligingsproblemen tegengaan in websites,” SaoTN, 2013. [Online]. Available: https://www.saotn.org/cross-site-scripting-tegengaan/#.U51TbPl_v5A. [Geopend 14 Juni 2014].
[6] S. Bottelbergs, „A comparative study on the Security of open source web Content Management Systems,” Unicersiteit Hasselt, 2013.
[7] WhiteHats, 2014. [Online]. Available: https://www.whitehats.nl/owasp-top-10. [Geopend 15 Juni 2014].[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Reacties

comments

Scroll to Top