Wat is OWASP?
het Open Web Application Security Project, of OWASP, is een internationale non-profit organisatie die zich toelegt op de beveiliging van webapplicaties. Een van OWASP ‘ s kernprincipes is dat al hun materialen vrij beschikbaar en gemakkelijk toegankelijk zijn op hun website, waardoor het voor iedereen mogelijk is om hun eigen beveiliging van webapplicaties te verbeteren. De materialen die zij aanbieden omvatten documentatie, tools, video ‘ s en forums. Misschien wel hun bekendste project is de OWASP Top 10.
Wat is de OWASP Top 10?,
de OWASP Top 10 is een regelmatig bijgewerkt rapport waarin de veiligheidsproblemen voor de beveiliging van webapplicaties worden beschreven, waarbij de nadruk ligt op de 10 meest kritieke risico ‘ s. Het rapport is samengesteld door een team van beveiligingsexperts van over de hele wereld. OWASP verwijst naar de Top 10 als een ‘bewustmakingsdocument’ en beveelt aan dat alle bedrijven het rapport in hun processen opnemen om veiligheidsrisico ‘ s te minimaliseren en/of te beperken.
hieronder zijn de beveiligingsrisico ‘ s vermeld in het OWASP Top 10 2017-rapport:
1., Injectie
injectieaanvallen gebeuren wanneer niet-vertrouwde gegevens naar een code-interpreter worden verzonden via een formulier-invoer of een andere gegevensinzending naar een webapplicatie. Een aanvaller kan bijvoorbeeld SQL-databasecode invoeren in een formulier dat een gebruikersnaam in platte tekst verwacht. Als die form input niet goed beveiligd is, zou dit resulteren in het uitvoeren van die SQL code. Dit staat bekend als een SQL injectie aanval.
injectieaanvallen kunnen worden voorkomen door door de gebruiker ingediende gegevens te valideren en/of te ontsmetten., (Validatie betekent het afwijzen van verdacht uitziende gegevens, terwijl ontsmetting verwijst naar het opruimen van de verdacht uitziende delen van de gegevens. Bovendien kan een database-beheerder controles Instellen om de hoeveelheid informatie die een injectieaanval kan blootleggen te minimaliseren.
2. Defecte authenticatie
kwetsbaarheden in authenticatie (login) systemen kunnen aanvallers toegang geven tot gebruikersaccounts en zelfs de mogelijkheid om een heel systeem in gevaar te brengen met behulp van een admin account., Bijvoorbeeld, een aanvaller kan een lijst met duizenden bekende gebruikersnaam/wachtwoord combinaties verkregen tijdens een datalek en gebruik maken van een script om te proberen al die combinaties op een login systeem om te zien of er een die werken.
sommige strategieën om authenticatie kwetsbaarheden te beperken vereisen twee-factor authenticatie (2FA) en het beperken of vertragen van herhaalde aanmeldpogingen met behulp van snelheidsbeperking.
3., Blootstelling aan gevoelige gegevens
als webapplicaties gevoelige gegevens zoals financiële informatie en wachtwoorden niet beschermen, kunnen aanvallers toegang krijgen tot die gegevens en kunnen seller deze gebruiken voor snode doeleinden. Een populaire methode voor het stelen van gevoelige informatie is met behulp van een on-path aanval.
het risico van blootstelling aan gegevens kan worden geminimaliseerd door alle gevoelige gegevens te versleutelen en door het cachen* van gevoelige informatie uit te schakelen. Daarnaast moeten webapplicatie-ontwikkelaars ervoor zorgen dat ze niet onnodig gevoelige gegevens opslaan.,
* Caching is de praktijk van het tijdelijk opslaan van gegevens voor hergebruik. Webbrowsers zullen bijvoorbeeld vaak webpagina ’s cachen, zodat als een gebruiker deze pagina’ s binnen een vaste tijdspanne opnieuw bezoekt, de browser de pagina ‘ s niet van het web hoeft op te halen.
4. XML External Entities (Xee)
Dit is een aanval op een webtoepassing die XML* invoer ontleedt. Deze input kan verwijzen naar een externe entiteit, die probeert een kwetsbaarheid in de parser te exploiteren. Een ‘externe entiteit’ verwijst in deze context naar een opslageenheid, zoals een harde schijf., Een XML-parser kan worden misleid in het verzenden van gegevens naar een onbevoegde externe entiteit, die gevoelige gegevens direct kan doorgeven aan een aanvaller.
de beste manieren om Xee-aanvallen te voorkomen zijn om webapplicaties een minder complex type data te laten accepteren, zoals JSON**, of op zijn minst om XML-parsers te patchen en het gebruik van externe entiteiten in een XML-toepassing uit te schakelen.
*XML of Extensible Markup Language is een opmaaktaal die zowel voor mensen leesbaar als voor machines leesbaar is. Vanwege de complexiteit en kwetsbaarheden in de beveiliging, wordt het nu geleidelijk uit het gebruik in veel webapplicaties.,
**JavaScript Object Notation (JSON) is een eenvoudige, door mensen leesbare notatie die vaak wordt gebruikt om gegevens over het internet te verzenden. Hoewel het oorspronkelijk werd gemaakt voor JavaScript, JSON is taal-agnostisch en kan worden geïnterpreteerd door veel verschillende programmeertalen.
5. Verbroken Toegangscontrole
Toegangscontrole verwijst naar een systeem dat de toegang tot informatie of functionaliteit controleert. Gebroken toegangscontroles toestaan aanvallers om autorisatie te omzeilen en taken uit te voeren alsof ze bevoorrechte gebruikers, zoals beheerders., Een webtoepassing kan bijvoorbeeld een gebruiker toestaan om te veranderen welk account ze zijn aangemeld als gewoon door het veranderen van een deel van een url, zonder enige andere verificatie.
toegangscontroles kunnen worden beveiligd door ervoor te zorgen dat een webtoepassing autorisatietokens* gebruikt en deze streng controleert.
* veel services geven autorisatietokens uit wanneer gebruikers zich aanmelden. Elk geprivilegieerd verzoek van een gebruiker vereist dat het autorisatietoken aanwezig is. Dit is een veilige manier om ervoor te zorgen dat de gebruiker is wie ze zeggen dat ze zijn, zonder voortdurend in te voeren hun inloggegevens.
6., Foutieve beveiligingsconfiguratie
foutieve Beveiligingsconfiguratie is de meest voorkomende kwetsbaarheid in de lijst, en is vaak het gevolg van het gebruik van standaardconfiguraties of het weergeven van overdreven uitgebreide fouten. Bijvoorbeeld, een applicatie kan een gebruiker te beschrijvende fouten die kwetsbaarheden in de applicatie kunnen onthullen tonen. Dit kan worden beperkt door ongebruikte functies in de code te verwijderen en ervoor te zorgen dat foutmeldingen algemener zijn.
7., Cross-Site Scripting
cross-site scripting kwetsbaarheden optreden wanneer webapplicaties gebruikers toestaan om aangepaste code toe te voegen aan een url-pad of op een website die zal worden gezien door andere gebruikers. Deze kwetsbaarheid kan worden benut om kwaadaardige JavaScript-code uit te voeren op de browser van een slachtoffer. Bijvoorbeeld, een aanvaller kan een e-mail te sturen naar een slachtoffer dat lijkt te zijn van een vertrouwde bank, met een link naar de website van die bank. Deze link kan een aantal kwaadaardige JavaScript-code getagd op het einde van de url hebben., Als de site van de bank is niet goed beschermd tegen cross-site scripting, dan is dat kwaadaardige code zal worden uitgevoerd in webbrowser van het slachtoffer wanneer ze klikken op de link.
Mitigatiestrategieën voor cross-site scripting omvatten het ontsnappen aan niet-vertrouwde HTTP-verzoeken en het valideren en/of ontsmetten van door gebruikers gegenereerde inhoud. Met behulp van moderne web development frameworks zoals ReactJS en Ruby on Rails biedt ook een aantal ingebouwde cross-site scripting bescherming.
8. Onveilige deserialisatie
deze bedreiging richt zich op de vele webapplicaties die vaak Data serialiseren en deserialiseren., Serialisatie betekent het nemen van objecten uit de applicatie code en ze te converteren naar een formaat dat kan worden gebruikt voor een ander doel, zoals het opslaan van de gegevens op de schijf of het streamen ervan. Deserialisatie is precies het tegenovergestelde: het omzetten van serialized data terug in objecten die de toepassing kan gebruiken. Serialisatie is als het inpakken van meubels in dozen voor een verhuizing, en deserialisatie is als het uitpakken van de dozen en het monteren van de meubels na de verhuizing. Een onveilige deserialisatie aanval is als het hebben van de movers knoeien met de inhoud van de dozen voordat ze worden uitgepakt.,
een onveilige deserialisatie exploit is het resultaat van het deserialiseren van gegevens van niet-vertrouwde bronnen, en kan resulteren in ernstige gevolgen zoals DDoS-aanvallen en externe code uitvoering aanvallen. Hoewel stappen kunnen worden genomen om te proberen en te vangen aanvallers, zoals het bewaken van deserialisatie en het implementeren van type controles, de enige zekere manier om te beschermen tegen onveilige deserialisatie aanvallen is het verbieden van de deserialisatie van gegevens uit niet-vertrouwde bronnen.
9., Met behulp van componenten met bekende kwetsbaarheden
veel moderne webontwikkelaars gebruiken componenten zoals bibliotheken en frameworks in hun webtoepassingen. Deze componenten zijn stukjes software die ontwikkelaars helpen redundant werk te voorkomen en de benodigde functionaliteit bieden; veelvoorkomend voorbeeld zijn front-end frameworks zoals React en kleinere bibliotheken die gebruikt werden om share iconen of a/b-testen toe te voegen. Sommige aanvallers zoeken naar kwetsbaarheden in deze componenten die ze vervolgens kunnen gebruiken om aanvallen te orkestreren., Sommige van de meer populaire componenten worden gebruikt op honderdduizenden websites; een aanvaller het vinden van een veiligheidslek in een van deze componenten zou kunnen verlaten honderdduizenden sites kwetsbaar te exploiteren.
Componentontwikkelaars bieden vaak beveiligingspatches en updates aan om bekende kwetsbaarheden aan te vullen, maar ontwikkelaars van webapplicaties hebben niet altijd de gepatchte of meest recente versies van componenten op hun applicaties., Om het risico van het uitvoeren van onderdelen met bekende kwetsbaarheden te minimaliseren, moeten ontwikkelaars ongebruikte onderdelen uit hun projecten verwijderen, evenals ervoor te zorgen dat ze componenten ontvangen van een vertrouwde bron en ervoor te zorgen dat ze up-to-date zijn.
10. Onvoldoende Logging en Monitoring
veel webapplicaties nemen niet genoeg stappen om datalekken op te sporen. De gemiddelde ontdekktijd voor een breuk is ongeveer 200 dagen nadat het is gebeurd. Dit geeft aanvallers veel tijd om schade te veroorzaken voordat er een reactie is., OWASP raadt aan dat webontwikkelaars logging en monitoring moeten implementeren, evenals incident response plannen om ervoor te zorgen dat ze bewust worden gemaakt van aanvallen op hun applicaties.
voor een meer technische en diepgaande blik op de OWASP Top 10, zie het officiële rapport .