Claranet's top 10 ontdekte kwetsbaarheden in webapplicaties in 2024

Webapplicaties zijn een veelvoorkomend doelwit tijdens cyberaanvallen. Cybercriminelen kiezen ze omdat:

ze gemakkelijk online zijn te ontdekken
ze vaak kwetsbaarheden bevatten uit de open-source codebibliotheken die ze gebruiken
ontwikkelaars onder druk staan om code sneller dan ooit vrij te geven en missen daardoor beveiligingskwetsbaarheden (of weten niet hoe ze deze kunnen herkennen)
veranderingen in code en nieuwe aanvalstechnieken betekenen dat nieuwe kwetsbaarheden weken of maanden onontdekt kunnen blijven als organisaties slechts eenmaal per jaar penetratietests uitvoeren

Om deze reden krijgen webapplicaties speciale aandacht van kwaadwillenden en verdienen ze evenveel aandacht van ontwikkelaars en beveiligingsteams. Claranet heeft onlangs onderzoek gedaan naar de resultaten van onze pentesten van het afgelopen jaar. Hierbij werden de meest voorkomende kwetsbaarheden in webapplicaties vergeleken die werden aangetroffen in een selecte steekproef van 500 pentests voor webapplicaties in 2024. Daarnaast spraken we met ons team van deskundige pentesters om erachter te komen welke algemene trends en beveiligingsoplossingen je kunt implementeren om dergelijke bedreigingen te beperken.

In dit artikel worden de top 10 kwetsbaarheden in webapplicaties beschreven die Claranet tijdens pentests in 2024 heeft aangetroffen. Ook worden de beveiligingsmaatregelen beschreven die je kan nemen om deze kwetsbaarheden te beperken en kijken we naar de toekomstige trends die we waarschijnlijk zullen gaan zien.

Samenvatting

Hoewel veel van de belangrijkste OWASP 10-bevindingen in onze bevindingen zijn opgenomen, ontdekte ons onderzoek enige variatie ten opzichte van die lijst. We ontdekten met name dat veel webapplicaties nog steeds gemakkelijk te exploiteren kwetsbaarheden bevatten die aan elkaar kunnen worden gekoppeld om veel krachtigere gevolgen te creëren. Het is belangrijk om laaghangend fruit voor aanvallers uit te roeien, vooral wanneer ze kunnen leiden tot het in gevaar brengen van de vertrouwelijkheid, integriteit of beschikbaarheid van een applicatie, of wanneer de applicatie kan worden gebruikt als opstapje in een grotere cyberaanval. We hopen dat ontwikkelteams deze bevindingen zullen gebruiken om de beveiliging van hun applicaties te verbeteren.

Webapplicaties hebben nog steeds last van kwetsbaarheden die al jaren bestaan. Er is een opvallende verschuiving van meer algemene exploits zoals een gebrek aan SQL-injectie en command OS-injectie, maar Cross Site Scripting (XSS) is nog steeds gangbaar. Een van onze eerste conclusies is dat de klanten van Claranet actief beveiligingen in hun webapplicatie-ontwikkelingscyclus hebben geïntroduceerd, met behulp van pentesten en Continuous Security Testing, evenals het implementeren van trainingen zoals Application Security for Developers en DevSecOps-training.

1. XSS Reflected en Stored

Claranet kon 2570 instanties van Cross Site Scripting (XSS) vinden die werden gereflecteerd en opgeslagen in de webapplicaties die we in 2024 testten. Het was ook een van de meest voorkomende kwetsbaarheden die werd gevonden in applicaties die we de afgelopen vijf jaar hebben getest. Het werd vaak gekoppeld aan een andere bevinding hieronder, zoals verouderde JavaScript-bibliotheken. XSS kan variëren van een bevinding van gemiddeld tot hoog niveau, afhankelijk van waar in de applicatie het werd gevonden.

Wat is XSS?

Reflected XSS treedt op wanneer gebruikersinvoer direct wordt gereflecteerd in de respons van de server zonder de juiste validatie of codering. Als bijvoorbeeld een zoekterm wordt weergegeven op een webpagina en die term schadelijke code bevat, kan deze worden uitgevoerd in de browser van de gebruiker.
Stored XSS treedt op wanneer schadelijke invoer op de server wordt opgeslagen (bijvoorbeeld in een database) en later aan andere gebruikers wordt aangeboden. Dit betekent dat de schadelijke invoer iedereen kan treffen die de opgeslagen content bekijkt, zoals opmerkingen of gebruikersprofielen.

Hoe je jezelf kunt verdedigen tegen XSS

Web Application Firewall (WAF) implementeren
Invoer saneren en negeren: gebruikersinvoer opschonen en valideren en speciale tekens negeren voordat ze in de browser worden weergegeven.
Content Security Policy (CSP) gebruiken: strikte regels definiëren om de bronnen van scripts en inhoud te beheren.
HTTPOnly en beveiligde cookies gebruiken: cookies beschermen tegen JavaScript-toegang en HTTPS-overdracht afdwingen.
Input valideren: zowel client-side als server-side validatie uitvoeren.
Inline JavaScript vermijden: scripts externaliseren en gebruikersgegevens niet rechtstreeks in HTML of JavaScript insluiten.
Moderne frameworks gebruiken: vertrouwen op frameworks zoals React, Angular of Vue.js die inherent input negeren.
Veilige API's gebruiken: veiligere methoden zoals textContent boven innerHTML verkiezen om HTML-injectie te voorkomen.
Open source- en third-party codebibliotheken controleren: open source- en third-party bibliotheken regelmatig controleren op beveiligingsrisico's met behulp van kwetsbaarheidsscanners.
Web Application Firewall (WAF) implementeren: een beschermingslaag tegen XSS-aanvallen toevoegen.
Beveiligingstests uitvoeren: geautomatiseerde tools en handmatige beoordelingen gebruiken om kwetsbaarheden te identificeren.
Context-specifiek negeren: negeer data op de juiste manier op basis van waar het zal worden ingevoegd (HTML, JS, URL's).
Beperk riskante functies: Schakel functies zoals eval() en innerHTML uit of beperk ze om het aanvalsoppervlak te verkleinen.

2. Verouderde JavaScript-bibliotheken

We hebben 1032 gevallen van verouderde JavaScript-bibliotheken aangetroffen in gebruik in 500 geteste webapplicaties in het jaar 2024. Het gebruik van verouderde JavaScript kan leiden tot XSS, Denial of Service-aanvallen en openbaarmaking van gevoelige informatie op de getroffen pagina.

Wat zijn verouderde JavaScript-bibliotheken?

Verouderde JavaScript-bibliotheken worden niet langer actief onderhouden, bijgewerkt of ondersteund. Het gebruik van verouderde bibliotheken kan leiden tot verschillende problemen, waaronder beveiligingskwetsbaarheden, compatibiliteitsproblemen en defecte applicatiefuncties.

Hoe te verdedigen tegen verouderde JavaScript-bibliotheken?

Afhankelijkheden regelmatig bijwerken

Monitor updates voor bibliotheken en frameworks. Gebruik tools die controleren op waarschuwingen over verouderde of kwetsbare afhankelijkheden.

Evalueer bibliotheken vóór gebruik

Onderzoek de onderhoudsstatus en community-ondersteuning van elke bibliotheek.
Controleer recente activiteit op de repository of officiële site.

Gebruik indien nodig nieuwere alternatieven

Adopteer actief onderhouden frameworks (bijv. React, Angular, Vue.js).
Gebruik ingebouwde oplossingen en native browser-API's.

Implementeer beveiligingspraktijken

Volg veilige coderingspraktijken.
Voer regelmatig beveiligingsaudits uit van code en afhankelijkheden.

Compatibiliteit behouden

Test je applicatie grondig na bibliotheekupdates, met behulp van geautomatiseerde vulnerability scanners, pentesten of continue beveiligingstesten.
Gebruik versie-pinning om afhankelijkheidsversies te beheren.

Documentatie en training

Informeer je team over het belang van het updaten van bibliotheken.
Documenteer processen voor het updaten van afhankelijkheden en het verwerken van bibliotheken.

Plan voor migratie

Ontwikkel een migratiestrategie om de overgang te maken van verouderde bibliotheken naar moderne alternatieven.

3. Clickjacking

We vonden 1226 gevallen van clickjacking in 2024, wat meer dan 80% van de 500 webapplicaties die voor dit onderzoek zijn bemonsterd, trof. Clickjacking wordt vaak gerapporteerd als een probleem met een laag risico, maar kan, afhankelijk van de context van de webapplicatie, verwoestende effecten hebben op de algehele beveiliging van die applicatie.

Wat is Clickjacking

Met Clickjacking misleiden aanvallers gebruikers om op iets anders te klikken dan wat de gebruiker waarneemt, en "kapen" zo in feite hun klikken. Dit gebeurt meestal door een transparante of ondoorzichtige laag over een legitieme webpagina te plaatsen, waardoor de gebruiker onbewust interactie heeft met verborgen elementen, zoals knoppen of links die kwaadaardige acties uitvoeren.

Hoe u zich kunt verdedigen tegen Clickjacking

Frame-busting: Websites kunnen code implementeren die voorkomt dat hun content in iframes wordt geladen, wat aanvallers vaak gebruiken om schadelijke content te overlappen.
X-Frame-Options Header: Moderne browsers ondersteunen de X-Frame-Options HTTP-header, wat websites kunnen gebruiken om te voorkomen dat hun pagina's door aanvallers in iframes worden geladen.
Content Security Policy (CSP): De CSP frame-ancestors-richtlijn kan helpen clickjacking te voorkomen door te beperken welke domeinen de site in een iframe mogen insluiten.

4. Server Header Disclosure

Vaak wordt de infrastructuur waarop de webapplicatie wordt gehost ook getest als onderdeel van een pentest. We ontdekten dat informatie over softwareversies die door de applicatie worden gebruikt, vaak te vinden is in HTTP-responsheaders. Deze informatie kan door aanvallers worden gebruikt om de software die door de applicatie wordt gebruikt beter te begrijpen en vervolgens onderzoek te doen naar bekende kwetsbaarheden in die software. Dergelijke informatie wordt ook verzameld door tools zoals Shodan en openbaar gemaakt, waardoor aanvallers passief potentiële doelen voor aanvallen in die software kunnen identificeren.

We vonden 4631 openbaarmakingen in responsheaders in de steekproefgrootte van 500 web-apps die we in 2024 hebben getest.

Wat is Server Header Disclosure?

Server Header Disclosure verwijst naar de blootstelling van informatie over de webserver en zijn software in de HTTP-responsheaders. Wanneer een server reageert op een client (meestal een browser), stuurt deze een verscheidenheid aan HTTP-headers die de respons beschrijven. Als de server verkeerd is geconfigureerd of niet goed is beveiligd, kan deze gevoelige details in deze headers bevatten, zoals de naam, versie of het type serversoftware (bijv. Apache, Nginx, IIS), het besturingssysteem en zelfs details over geïnstalleerde modules of softwareversies.

Hoe je je kunt verdedigen tegen Server Header Disclosure?

Serverinformatie onderdrukken: configureer de webserver om de serverheader volledig te onderdrukken of te verwijderen, of beperk op zijn minst de hoeveelheid gedeelde informatie.
Content Security Policy (CSP): Hoewel CSP niet direct de openbaarmaking van de serverheader aanpakt, kan het zorgen voor de juiste CSP-regels andere risico's die samenhangen met de blootstelling van servergegevens minimaliseren.
Gebruik reverse proxies of load balancers: deze kunnen fungeren als tussenpersonen tussen de client en de server, waardoor specifieke servergegevens mogelijk worden verborgen voor blootstelling.

5. Ontbrekende cookie-attributen

Bij veel geverifieerde pentesten van webapplicaties ontbraken vaak een of meer beveiligde cookie-attributen in cookies die voor authenticatie werden gebruikt. We vonden 769 ontbrekende cookie-attributen in de 500 geteste webapplicaties in 2024.

Wat zijn ontbrekende cookie-attributen?

Ontbrekende cookie-attributen verwijzen naar een beveiligingsprobleem waarbij cookies, met name wanneer ze worden gebruikt om sessiegegevens of andere gevoelige informatie op te slaan, niet zijn geconfigureerd met belangrijke beveiligingsattributen. Deze attributen helpen de cookie te beschermen tegen diefstal of manipulatie, waardoor het risico op aanvallen zoals Cross-Site Scripting (XSS) of Cross-Site Request Forgery (CSRF) wordt verminderd.

Hoe je je kunt verdedigen tegen ontbrekende cookie-attributen

Stel de kenmerken Secure, HttpOnly en SameSite altijd op de juiste manier in, met name voor cookies die gevoelige gegevens opslaan.
Gebruik Secure voor alle cookies als je site HTTPS gebruikt.
Stel HttpOnly in om client-side toegang tot gevoelige cookies te voorkomen.
Gebruik het kenmerk SameSite om te beperken wanneer cookies worden verzonden in cross-origin requests, wat helpt om CSRF-aanvallen te beperken.

6. TLS1.0 en 1.1 in gebruik

De afgelopen vijf jaar hebben we ontdekt dat de meeste webapplicaties nog steeds gebruikmaken van de oudere protocollen TLS1.0 en TLS1.1 (Transport Layer Security).

We vonden 3703 exemplaren van TSL1.0 en 4062 exemplaren van TLS 1.1 in de 500 webapplicaties in onze steekproefselectie van 2024.

Wat is TLS1.0 en 1.1?

TLS 1.0 en TLS 1.1 zijn vroege versies van het Transport Layer Security-protocol dat is ontworpen om communicatie via een computernetwerk te beveiligen, met name in webverkeer (bijv. HTTPS-verbindingen). Beide versies worden echter nu als verouderd en onveilig beschouwd vanwege verschillende kwetsbaarheden die in de loop van de tijd zijn ontdekt.

Hoe je je kunt verdedigen tegen TLS1.0 en 1.1

Schakel TLS 1.0 en TLS 1.1 uit op je webservers (bijv. Apache, Nginx, IIS) en schakel alleen TLS 1.2 en TLS 1.3 in.
Schakel sterke cipher suites in en schakel zwakke uit (bijv. RC4, DES, 3DES, SHA-1).
Gebruik Perfect Forward Secrecy (PFS) door cipher suites zoals ECDHE of DHE te prioriteren.
Upgrade naar TLS 1.3, dat betere beveiliging en prestaties biedt.
Beheer certificaten veilig met behulp van vertrouwde CA's en sterke sleutels (2048-bits RSA of hoger).
Test de TLS-configuratie van jouw server regelmatig met behulp van tools zoals Qualys SSL Labs, Nmap of Testssl.sh.
Controleer en patch jouw systemen en webapplicaties regelmatig om ze up-to-date te houden.
Zorg voor clientcompatibiliteit door applicaties en integraties te upgraden ter ondersteuning van TLS 1.2 en 1.3.
Implementeer HSTS (HTTP Strict Transport Security) om HTTPS-verbindingen te forceren.
Overweeg het gebruik van een Web Application Firewall (WAF) voor extra bescherming tegen aanvallen.

7. Geen accountvergrendeling

Hoewel er in een groot aantal webapplicaties die we de afgelopen vijf jaar hebben getest, geen accountvergrendeling werd vastgesteld, vonden we in 2024 slechts 35 gevallen van geen accountvergrendeling in de steekproef van 500 webapplicaties. Voor moderne webapplicaties is dit een essentiële beveiligingscontrole die steeds gebruikelijker wordt.

Wat is geen accountvergrendeling?

Er vindt geen accountvergrendeling plaats als er geen limiet is op het aantal wachtwoord-inlogpogingen dat door de applicatie is ingesteld. Om te beschermen tegen brute force- en credential stuffing-aanvallen, hebben veel webapplicaties een vergrendelingsbeleid waarbij, na een bepaald aantal mislukte inlogpogingen (meestal vanwege verkeerde wachtwoorden), het account van de gebruiker tijdelijk of permanent wordt vergrendeld om verdere toegang te voorkomen.

Hoe je je kunt verdedigen tegen het beleid van geen accountvergrendeling

Throttle/limit login attempts: beperk het aantal login attempts per gebruiker of IP binnen een bepaalde periode.
Progressieve vertragingen: verhoog de wachttijden tussen opeenvolgende mislukte login attempts.
Captcha of Multi-Factor Authentication (MFA): CAPTCHA en MFA moeten standaard worden geïmplementeerd voor eerste logins en opnieuw worden vereist na meerdere mislukte login attempts.
IP-adresblokkering en -bewaking: blokkeer of bewaak verdachte IP's met herhaaldelijke mislukte logins.
Meldingen over accountactiviteit: informeer gebruikers over mislukte login attempts of ongebruikelijke activiteiten.
Sterk wachtwoordbeleid: dwing complexe wachtwoorden afen verplicht regelmatige updates.
Token-based authentication: gebruik OAuth of JWT voor authenticatie in plaats van alleen wachtwoorden.
Account lockout recovery (soft lockout): vergrendel accounts tijdelijk met een hersteloptie.
Honeypots en misleiding: detecteer en blokkeer aanvallers door honeypot-accounts te gebruiken.
Apparaatherkenning: identificeer vertrouwde apparaten en vereis aanvullende verificatie voor onbekende apparaten.

8. Ontbrekende HTTP-beveiligingsheaders

We hebben ontbrekende HTTP-beveiligingsheaders aangetroffen in meer dan de helft van de webapplicatiebeoordelingen die in 2024 zijn uitgevoerd. Doordat de juiste HTTP-beveiligingsheaders niet zijn ingesteld in HTTP POST- en GET-aanvragen, zijn webapplicaties kwetsbaar voor het volgende:

Hoe je je kunt verdedigen tegen gecreëerde kwetsbaarheden in HTTP-beveiligingsheaders	Beveiligingsmaatregelen
Cross-Site Scripting (XSS): Als de Content-Security-Policy (CSP)-header ontbreekt, kunnen aanvallers schadelijke scripts injecteren en uitvoeren.	Content-Security-Policy (CSP) header Implementeer de Content-Security-Policy (CSP)-header om inhoudsbronnen te beperken.
Clickjacking: Als de X-Frame-Options-header ontbreekt, is jouw site kwetsbaar voor clickjacking. De header kan dan worden ingesloten in iframes op schadelijke sites.	X-Frame-Options header Gebruik de header X-Frame-Options om te voorkomen dat uw site in iframes wordt ingesloten.
Onveilige gegevensoverdracht: Als de Strict-Transport-Security (HSTS)-header ontbreekt, kunnen gebruikers de site via HTTP bezoeken, waardoor gegevens worden blootgesteld aan man-in-the-middle-aanvallen.	Strict-Transport-Security (HSTS) header Stel de Strict-Transport-Security (HSTS)-header in om alleen HTTPS-communicatie af te dwingen.
MIME-typeverwarring: Als de header X-Content-Type-Options ontbreekt, kunnen browsers bestanden verkeerd interpreteren, waardoor het risico op scriptuitvoering en aanvallen toeneemt.	X-Content-Type-Options Voeg de header X-Content-Type-Options: nosniff toe om verwarring over MIME-typen te voorkomen.
Cross-Site Request Forgery (CSRF): Het ontbreken van het SameSite-kenmerk in cookies kan leiden tot CSRF-aanvallen doordat cookies kunnen worden verzonden met schadelijke cross-site-verzoeken.	SameSite-kenmerk Gebruik het SameSite-kenmerk voor cookies om te voorkomen dat ze met cross-site-verzoeken worden meegestuurd.
Blootstelling aan verwijzende informatie Als de Referrer-Policy-header ontbreekt, bestaat het risico dat gevoelige URL-gegevens worden blootgesteld aan sites van derden, wat gevolgen heeft voor de privacy en beveiliging.	Controle van verwijzende informatie Stel de Referrer-Policy-header in om de verwijzende informatie die met externe sites wordt gedeeld, te beperken.
Onjuiste verwerking van inhoudstypen: Een ontbrekende Content-Type-header kan ertoe leiden dat browsers inhoud verkeerd interpreteren, wat kan leiden tot XSS- of injectieaanvallen.	Correcte verwerking van inhoudstypen: Stel altijd de Content-Type header in om een correcte interpretatie van de inhoud te garanderen.
Caching van gevoelige data: Ontbrekende Cache-Control- of Pragma-headers kunnen ertoe leiden dat gevoelige gegevens in de cache worden opgeslagen, wat kan leiden tot blootstelling van gegevens.	Voorkomen van cachen van gevoelige data: Stel Cache-Control- en Pragma-headers in om te voorkomen dat gevoelige gegevens in de cache worden opgeslagen.

9. Uitgebreide foutmeldingen binnen webapplicaties

In ongeveer 60% van de 500 webapplicaties die we voor dit onderzoek hebben onderzocht, vonden we uitgebreide foutmeldingen.

Wat zijn uitgebreide foutmeldingen?

Uitgebreide foutmeldingen geven gedetailleerde informatie over de fouten of problemen die een programma of systeem tegenkomt. In tegenstelling tot standaard foutmeldingen, die kort en vaag kunnen zijn, zijn uitgebreide foutmeldingen bedoeld om een meer diepgaande uitleg te geven om ontwikkelaars of gebruikers te helpen het probleem te diagnosticeren en op te lossen. Uitgebreide foutmeldingen zijn vaak nuttig voor aanvallers, omdat ze vaak inzicht bieden in de tech stack van de applicatie en mogelijk meer informatie over wat de applicatie doet.

Hoe je je kunt verdedigen tegen uitgebreide foutmeldingen

Het is raadzaam om ervoor te zorgen dat foutmeldingen algemeen zijn, zodat een aanvaller niet te veel te weten komt over de applicatie die hij aanvalt.

Beperk informatie in productieomgevingen: schakel uitgebreide foutmeldingen in productie uit en geef gebruikers alleen algemene berichten.
Log gedetailleerde fouten privé: log uitgebreide fouten veilig voor intern gebruik, zonder details bloot te stellen aan gebruikers.
Sanitiseer invoer: valideer en saneer gebruikersinvoer om te voorkomen dat aanvallers gedetailleerde foutreacties activeren.
Aangepaste foutpagina's: gebruik aangepaste foutpagina's die geen systeemdetails onthullen en log fouten intern.
Role-Based Access Control (RBAC): beperk de toegang tot gedetailleerde foutmeldingen en laat ze alleen zien aan geautoriseerde gebruikers (bijv. beheerders).
Stem uitgebreide niveaus af: stel geschikte uitgebreide foutniveaus in productieomgevingen in en onderdruk stack traces voor eindgebruikers.
Regelmatige beveiligingsaudits: voer audits en pentesten uit om ervoor te zorgen dat uitgebreide berichten niet onbedoeld worden blootgesteld.
Gebruik tools voor foutregistratie: implementeer tools om fouten veilig te monitoren en te loggen.
Versleutel gevoelige gegevens in logs: versleutel of maskeer gevoelige informatie in logs om ongeautoriseerde toegang te voorkomen.
Zorg dat de applicatiestack veilig is: werk software regelmatig bij en controleer configuraties om ervoor te zorgen dat de uitgebreidheid wordt beperkt.

10. Kwaadaardige bestandsupload

We hebben 574 gevallen van webapplicaties gevonden die kwetsbaar zijn voor het uploaden van kwaadaardige bestanden, van de 500 webapplicaties die we in 2024 hebben getest.

Wat is kwaadaardige bestandsupload?

Kwaadaardige bestandsupload is een type beveiligingskwetsbaarheid waarbij aanvallers de bestandsuploadfunctionaliteit van een webapplicatie misbruiken om kwaadaardige bestanden te uploaden die het systeem kunnen compromitteren of ongeautoriseerde acties kunnen uitvoeren. Deze kwaadaardige bestanden kunnen scripts, uitvoerbare bestanden of code bevatten die, wanneer ze worden geüpload en uitgevoerd, aanvallers in staat stellen om de functionaliteit van webapplicaties te beschadigen of ongeautoriseerde acties uit te voeren als onderdeel van een bredere, geënsceneerde cyberaanval.

How to defend against malicious file upload

Beperk bestandstypen: sta alleen specifieke bestandstypen toe en valideer bestandsinhoud op de server.
Bestandsnaamsanering: hernoem geüploade bestanden en verwijder schadelijke tekens uit bestandsnamen.
Beperkingen bestandsgrootte: stel limieten in voor de maximale bestandsgrootte voor uploads.
Sla bestanden op buiten de webroot: sla geüploade bestanden op buiten openbare mappen om uitvoering te voorkomen.
Gebruik bestandsscanning: integreer antivirusprogramma's om bestanden te scannen op malware.
Schakel scriptuitvoering uit: zorg ervoor dat geüploade bestanden niet als scripts kunnen worden uitgevoerd door uitvoeringsmachtigingen uit te schakelen.
Validatie van content-type en MIME-type: controleer of de MIME-typen van bestanden overeenkomen met de verwachte bestandstypen.
Gebruik beveiligde bestandsuploadbibliotheken: gebruik beveiligde bestandsuploadbibliotheken met ingebouwde beveiligingen.
Beperk uploadlocaties: beperk bestandsuploads tot specifieke mappen en controleer ze.
Implementeer sterke toegangscontroles: beperk bestandsuploadmachtigingen tot geverifieerde en geautoriseerde gebruikers.
Gebruik een Content Delivery Network (CDN): serveer geüploade bestanden via een CDN om ze te scheiden van de hoofdapplicatie.
Monitor en log uploads: log en controleer alle bestandsuploads op verdachte activiteiten. Werk software en bibliotheken regelmatig bij: zorg ervoor dat alle software en bestandsverwerkingsbibliotheken up-to-date zijn met beveiligingspatches.

Toekomst van webapplicatietesten en nieuwe problemen aan de horizon

Hoewel er regelmatig nieuwe aanvalstechnieken ontstaan, blijven kwetsbaarheden in webapplicaties vaak jarenlang hetzelfde. Denk bijvoorbeeld eens aan hoe vaak de OWASP Top 10 moet worden bijgewerkt. Als kwetsbaarheden en aanvalstechnieken sneller zouden veranderen, zou deze lijst vaker moeten worden bijgewerkt.

Nieuwe AI-chatbots zorgen ervoor dat eindgebruikers een "echt" gesprek kunnen voeren en gegevens van hen terugkrijgen. Claranet heeft een toename gezien in het aantal webapplicaties dat nu gebruikmaakt van privé-AI/LLM-modellen die binnen webapplicaties worden gebruikt.

Hoe vergroot AI/LLM het aanvalsoppervlak op een applicatie?

Onlangs hebben we een toename gezien in het aantal webapplicaties dat gebruikmaakt van privé-AI/LLM-modellen die binnen webapplicaties worden gebruikt. Claranet dit meteen onderzocht en eerste advies uitgebracht hierover. Hieronder volgt een korte lijst:
Prompt injection-aanvallen: gemanipuleerde gebruikersinvoer kan het gedrag van een model veranderen, wat leidt tot onbedoelde of schadelijke uitvoer.
Datalekkage: het model kan gevoelige gegevens blootstellen, waaronder persoonlijk identificeerbare informatie (PII) of bedrijfseigen informatie, als het niet goed wordt beheerd.
Onveilige API-eindpunten: slecht beveiligde API-eindpunten kunnen worden misbruikt voor ongeautoriseerde toegang, gegevensmanipulatie of serviceonderbreking.
Tegenstrijdige invoer: gemanipuleerde invoer kan het model misleiden of verwarren, waardoor het onjuiste of gevaarlijke uitvoer genereert.
Bias en manipulatie: ingebouwde vooroordelen kunnen worden misbruikt, wat leidt tot discriminerende of schadelijke reacties en mogelijke manipulatie van het systeem

Hoewel er meer beveiligingsonderzoek nodig is om alle mogelijke kwetsbaarheden te ontdekken die LLM's aan een applicatie kunnen toevoegen, moeten ontwikkelaars ook extra voorzichtig zijn met het gebruik ervan voor coderingsdoeleinden. Recent onderzoek heeft aangetoond dat ze kwetsbaar zijn voor typosquatting-aanvallen, pogingen om trainingsdatasets te vergiftigen, aanvallers die AI-hallucinaties targeten en het creëren van coderepositories met malware, zijn slechts enkele voorbeelden van waarom we meer middelen moeten investeren in het beveiligen van grote taalmodellen.

Analyse van resultaten en advies voor ontwikkelaars

Een belangrijk advies voor ontwikkelteams is om de JavaScript-code die ze gebruiken te monitoren om ervoor te zorgen dat ze binnen de actieve ondersteuning blijven en de nieuwste patches bevatten. Alle open-source code repositories en third-party componenten die worden gebruikt in applicatieontwikkeling, moeten worden gecontroleerd met behulp van vulnerability scanners en getest in preproductieomgevingen. Omdat ontwikkelaars vaak onder druk staanom snel nieuwe code vrij te geven, kunnen teams efficiëntiewinsten inbouwen in hun DevSecOps-processen door Continuous Security Testing te gebruiken om kwetsbaarheden in applicatiecode te ontdekken en te verhelpen zodra ze zich voordoen en het venster van kwetsbaarheid waarmee hun applicatie wordt geconfronteerd te verkleinen.

Neem vandaag nog contact met ons op voor meer informatie over hoe pentesten en Continuous Security Testing uw webapplicaties kunnen beveiligen, en hoe Application Security for Developers en DevSecOps-training uw team in staat kunnen stellen veiligere praktijken voor applicatieontwikkeling te implementeren.

Software Innovation Lunch: Cyber Security

Ben je geïnteresseerd in dit onderwerp en werkzaam bij een ISV of software/applicatieontwikkelaar? Meld je dan aan voor de Software Innovation lunch op vrijdag 14 maart!

Tijdens deze lunch bouwen we een gemeenschap waar softwareleveranciers en -partijen informeel kunnen netwerken en leren over snelle technologische vooruitgangen.