Computest: een op de drie zakelijke webapplicaties bevat ernstige kwetsbaarheid

Bijna een op de drie zakelijke webapplicaties bevat een belangrijke of kritieke kwetsbaarheid die directe aandacht vereist. Dat blijkt uit onderzoek van beveiligingsbedrijf Computest Security. Vooral verouderde software is een oorzaak.

Computest Security baseert zich op een analyse van de resultaten van ruim driehonderd securitytests die het bedrijf gedurende een jaar uitvoerde op webapplicaties van verschillende organisaties. Daaruit blijkt dat een applicatie gemiddeld twaalf kwetsbaarheden bevat. Bijna een derde daarvan is een belangrijke of kritieke kwetsbaarheid, die grote impact kunnen hebben op organisaties.

Bij 32 procent van de tests werden cross-sitescriptingkwetsbaarheden gevonden. Daarmee kan een aanvaller kwaadaardige code injecteren in de webapplicatie, die wordt uitgevoerd als iemand de applicatie gebruikt. Aanvallers kunnen zo gevoelige data stelen of gebruikers ongemerkt doorsturen naar een malafide website. In bijna zestig procent van de gevallen kon de kwetsbaarheid misbruikt worden zonder dat er een account voor de webapplicatie nodig was.

Ook werden bij bijna dertig procent van de webapplicaties kwetsbaarheden in het autorisatiemechanisme gevonden. In die gevallen wordt niet op de juiste wijze gecontroleerd of de ingelogde gebruiker het recht heeft om een gevraagde functionaliteit te gebruiken. Bij 34 procent liet ook de beveiliging van de authenticatie te wensen over. Bij krap een op de vijf werd nog geen gebruik gemaakt van multifactorauthenticatie of was deze niet juist geïmplementeerd.

De kwetsbaarheden worden vooral veroorzaakt door het gebruik van verouderde software, het niet doorvoeren van benodigde updates en het ontbreken van sterke authenticatieoplossingen, zegt Computest. Het bedrijf adviseert organisaties om alleen software te kopen of te ontwikkelen die ontworpen is volgens het secure-by-designprincipe. Ook wordt aangeraden om in gebruik genomen software regelmatig te testen op kwetsbaarheden, sterke authenticatietools in te zetten en om updates direct te installeren als deze worden aangeboden.

Reacties (43)

[JosSchaars]

Moet het niet zijn: “één op de drie zakelijke ONLINE applicaties bevat ernstige kwetsbaarheid”?
Veel (met name oudere) applicatie hebben geen enkele connectie met het Internet.

[bzzzt]

Dan nog kunnen applicaties gevoelig zijn voor aanvallen, zoals bijvoorbeeld exploits bij het inlezen van documenten die wel van het internet kunnen komen. Of bijvoorbeeld macro virussen bevatten.

[Bux666]

Juist! Dat staat ook in het gelinkte artikel. Ik heb dit reeds als opmerking via de Feedback link doorgegeven.

[CAPSLOCK2000]

Moet het niet zijn: “één op de drie zakelijke ONLINE applicaties bevat ernstige kwetsbaarheid”?
Veel (met name oudere) applicatie hebben geen enkele connectie met het Internet.

Grote vraag is of die oudere applicaties veilger of onveiliger zijn. Ga maar uit van het laatste. Zolang ze offline blijven is dat misschien niet zo';n probleem maar tegenwoordig knopen we alles aan elkaar waardoor die oude software opeens toch online staat, direct of indirect.

[nvaert1986]

Dat hoeft niet zo te zijn dat deze geen ernstige kwetsbaarheden hebben. Ze kunnen bijv. slecht geprogrammeerd zijn en Local Privilege Escalation laten uitvoeren in een exploit keten. Vaak wordt er bij lokale programma's ook weinig / anders tot niet nagedacht over beveiliging, want ja, het draait toch lokaal is dan het perspectief is mijn ervaring.

[the_stickie]

De kwetsbaarheden worden vooral veroorzaakt door het gebruik van verouderde software, het niet doorvoeren van benodigde updates en het ontbreken van sterke authenticatieoplossingen

Het probleem is dus niet dat de software gaten heeft, maar dat het beheer te wensen overlaat?

[Kees]

Het hoeft niet het beheer te zijn. Ik gebruik ook wel wat "enterprise software", en soms valt het mij ook op dat er bijzonder oude libraries in die software zitten. Die kan ik niet updaten, dat moet de leverancier doen.

[CAPSLOCK2000]

Het hoeft niet het beheer te zijn. Ik gebruik ook wel wat "enterprise software", en soms valt het mij ook op dat er bijzonder oude libraries in die software zitten. Die kan ik niet updaten, dat moet de leverancier doen.

Ik hamer dan ook altijd op het verwijderen van embedded libraries en die te vervangen door losse packages. Onder Linux, mijn terrein, vraag ik om gebruik te maken van de packages van de distributie. Dus niet je eigen libpng embedden maar gewoon gebruiken wat het OS levert. Dan hoeft de leverancier die zelf niet meer te onderhouden maar kunnen zij (en ik) op het OS vertrouwen en hoef ik ieder probleem maar één keer te patchen.

Dat betekent wel dat je als leverancier rekening moet houden met distributies en apart testen op alle ondersteunde distributies.

De praktijk is natuurlijk minder mooi, veel softwarebouwers willen daar niks van weten en willen zelf alle libraries leveren omdat ze (onterecht) bang zijn voor onverwachte veranderingen. Helaas is "het werkt, nu afblijven!" nog steeds een heel normale insteek.
In theorie is het natuurlijk het beste als één bedrijf alle verantwoordelijkheid neemt maar in mijn ervaring doen ze dat in praktijk toch niet. Dan heb ik liever dat de software zo modulair gebouwd is dat ik zelf de libraries/dependencies kan upgraden. Ook hoor ik vaak dat ze door libs te embedden makkelijker op verschillende distro's kunnen draaien, maar typisch is dat niet ondersteunt, dus hoeveel heb je daar nu echt aan?

* enterprise betekent vooral "duur", niet te verwarren met "kwaliteiti".

[bzzzt]

veel softwarebouwers willen daar niks van weten en willen zelf alle libraries leveren omdat ze (onterecht) bang zijn voor onverwachte veranderingen.

Hoezo onterecht? Vaak genoeg gezien dat libraries een 'minor' patch krijgen die API incompatible blijkt te zijn. Support leveren wanneer klanten random versies kunnen kiezen van alle libraries is compleet onmogelijk tenzij je heel technische klanten en een te grote supportafdeling hebt...

[CAPSLOCK2000]

Hoezo onterecht? Vaak genoeg gezien dat libraries een 'minor' patch krijgen die API incompatible blijkt te zijn. Support leveren wanneer klanten random versies kunnen kiezen van alle libraries is compleet onmogelijk tenzij je heel technische klanten en een te grote supportafdeling hebt...

Dat is onterecht omdat je dat probleem niet hebt als je goed gebruik maakt van dependencies en stabiele partijen. Een distributie als Debian garandeerd een stabiele ABI/API binnen een release. Als je je applicatie in een Debian-package stopt en netjes je dependencies benoemt dan zou je nooit geconfonteerd moeten worden met incompatibiliteit.

Als dit soort problemen dreigen te ontstaan (omdat applicaties veranderen) dan gaat Debian er tussen staan en zorgt dat de compatibilteit gegarandeerd wordt. Zo hoef je dat maar één keer te doen voor iedere library en alle andere applicaties die op die distro draaien kunnen daar op vertrouwen. Dat is echt veel beter dan dat iedere applicatie z'n eigen kopie heeft en die zelf moet testen en onderhouden want de meesten doen dat gewoon niet.

Het werkt inderdaad niet als klanten/gebruikers zelf willekeurige versies van libraries gaan installeren. Je zal ergens moeten aangeven welke versies je ondersteunt. Als je dat goed doet dan kan de klant/gebruiker die zelf vervangen of, in praktijk, dat door de oorspronkelijke leverancier laten doen. Maar veel software doet die moeite niet en benoemt dependencies niet expliciet. Die weten niet met welke versies van hun dependencies ze compatibel zijn en bevriezen alles dus maar.

[bzzzt]

Als je je applicatie in een Debian-package stopt en netjes je dependencies benoemt dan zou je nooit geconfonteerd moeten worden met incompatibiliteit.

Dan beperk je je wel tot software waar Debian die garantie op geeft.
Zelfde kan je stellen voor andere leveranciers, maar op de grote OSS archieven als PyPI, Maven central, NuGet, NPM etc wordt die garantie niet gegeven. Laten dat nou net de repositories zijn waar veel ontwikkelaars spullen uit halen.

Die weten niet met welke versies van hun dependencies ze compatibel zijn en bevriezen alles dus maar.

Nee, die bevriezen de dependencies tot er bewezen is door testcases dat ze bijgewerkt kunnen worden zonder uitval van functionaliteit.
Testen tegen een n * n matrix van afhankelijkheden is totaal onbegonnen werk en helemaal niet zinvol.

[CAPSLOCK2000]

Dan beperk je je wel tot software waar Debian die garantie op geeft.
Zelfde kan je stellen voor andere leveranciers, maar op de grote OSS archieven als PyPI, Maven central, NuGet, NPM etc wordt die garantie niet gegeven. Laten dat nou net de repositories zijn waar veel ontwikkelaars spullen uit halen.

Dat is een keuze, maar dan moeten ze wel de gevolgen dragen. Als je beperkt bent dat wat er in Debian zit heb je inderdaad veel minder om uit te kiezen, maar je hebt wel de zekerheid.
Als ze geen gebruik willen maken van de garanties van Debian dan zullen ze dat zelf moeten doen, dat doen ze typisch niet.

Nee, die bevriezen de dependencies tot er bewezen is door testcases dat ze bijgewerkt kunnen worden zonder uitval van functionaliteit.
Testen tegen een n * n matrix van afhankelijkheden is totaal onbegonnen werk en helemaal niet zinvol.

Ik ben een groot voorstander van testen maar het kan geen alternatief zijn voor nadenken.
Je applicatie testen op meerdere (versies van) OS'en is heel goed te doen met automatische tools, die je toch al nodig hebt. Ja, het is wat extra werk maar het voorkomt ook dat je jezelf vastpint op een bug/feature/eigenaardigheid van een omgeving.
Je moet inderdaad niet iedere mogelijkheid van combinaties van dependencies gaan testen, maar testen voor bv Debian en Redhat is heel goed te doen.

Ik bedoel overigens niet dat leveranciers nooit libraries buiten een distro om mogen gebruiken, maar als ze dat doen zullen ze er wel zelf goed voor moeten zorgen. Liefst door ze apart te packagen zodat het mooi modulair blijft en het package vervolgens kan worden overgenomen door de distributies.

[bzzzt]

Ik ben een groot voorstander van testen maar het kan geen alternatief zijn voor nadenken.

Omgekeerd zijn er ook heel veel situaties waar mensen hard nagedacht hebben en toch nog verrast worden door onbedoelde bijeffecten die met testen wel naar boven komen. Alleen nadenken is ook niet zaligmakend.

Je moet inderdaad niet iedere mogelijkheid van combinaties van dependencies gaan testen, maar testen voor bv Debian en Redhat is heel goed te doen.

Als je software aan klanten levert is de kans groot dat ze veel meer support willen: Windows (10, 11), macOS (inclusief oudere versies), Debian, Red Hat, Ubuntu, Suse etc. Al snel heb je een giga testmatrix en als je wil garanderen dat je applicatie ook nog werkt na updates moet je dat voor elk van die distributies continu hertesten.

Liefst door ze apart te packagen zodat het mooi modulair blijft en het package vervolgens kan worden overgenomen door de distributies.

Jij denkt helemaal vanuit een Linux distributie context. Je hebt daar niets aan als je een Java applicatie levert. Dan zet je liefst alle dependencies vast. Updaten doe je dan eens per release of in noodgevallen.

[CAPSLOCK2000]

Jij denkt helemaal vanuit een Linux distributie context. Je hebt daar niets aan als je een Java applicatie levert. Dan zet je liefst alle dependencies vast. Updaten doe je dan eens per release of in noodgevallen.

Linux distributies geven het goede voorbeeld. Dat is niet gek want distributies worden gebouwd door mensen die het beheren van software als specialiteit hebben.

Zo'n beetje alle andere omgevingen hebben hun eigen oplossing gekozen maar je ziet overal dezelfde ontwikkelingen. Al die packagemanagers voor programmeertalen maken dezelfe evolutie door die Linux package managers al 20-30 jaar geleden hebben doorgemaakt. Omdat de meeste van die systemen relatief primitief zijn (en de gebruikers niet beter weten) worden ze nogal lomp ingezet om alles te bevriezen.


Beetje OT, packagemanagers en dependencies zijn een erg goed idee. Zo goed dat we zo op steeds meer niveau's implementeren. Een linux-distro bestaat uit pacakges, allerlei programmeertalen hebben hun eigen packages, docker is een vorm van packaging en heeft z'n eigen dependencysysteem en in die containers zitten ook weer packages, beheertools als Puppet en Ansible werken ook met afhankelijkheden en dependencies.
Packages en dependencies all the way down. Het is alleen jammer dat al die systemen gescheiden zijn. Het zo veel mooier zijn als er 1 universele dependencymanager is die overweg kan met alle vormen van software, zodat het niet uit maakt of je een applicatie installeert vanuit een debian package, een docker container, via pip of als browser extensie.
NixOS komt misschien wel het dichtste bij dat ideaal. Heel interessant om een keer naar te kijken als je het nog niet kent.

[bzzzt]

Het zo veel mooier zijn als er 1 universele dependencymanager is die overweg kan met alle vormen van software

Verplichte XKCD: https://xkcd.com/927/

Ik heb nergens beweerd dat packagemanagers niet handig zijn, maar mijn ervaring is ook dat er weinig structuur in zit en ook regelmatig dingen niet kloppen aan de registraties. Je kan ook niet verwachten dat bij release van package versie +1 ook gelijk alle dependencies gevalideerd zijn dus je loopt nog steeds tegen dubbelen en (hopelijk tijdelijk) verouderde versies aan.
Vastzetten van versies is volgens mij de enige optie om garanties te kunnen geven over een eindresultaat (je kan niet bewijzen dat een onbekende update geen fouten bevat). Maar dat hoeft natuurlijk niet te betekenen dat voor dat vastzetten geen updates zijn uitgevoerd.

[CAPSLOCK2000]

Verplichte XKCD: https://xkcd.com/927/

Nah, die wordt veel te veel gebruikt om veranderingen/verbeteringen tegen te houden.

Ik heb nergens beweerd dat packagemanagers niet handig zijn, maar mijn ervaring is ook dat er weinig structuur in zit en ook regelmatig dingen niet kloppen aan de registraties. Je kan ook niet verwachten dat bij release van package versie +1 ook gelijk alle dependencies gevalideerd zijn dus je loopt nog steeds tegen dubbelen en (hopelijk tijdelijk) verouderde versies aan.

Waarom niet? Misschien begrijp ik je verkeerd, maar je moet je software pas uitbrengen als je de dependencies hebt gecontroleerd. Dat gaat wel een stuk makkelijker als je gebruik maakt van officiele releases. Als je tegen een beta versie aan gaat zitten programmeren kun je inderaad in de situatie komen dat jouw applicatie klaar is maar de dependencies nog niet.

Vastzetten van versies is volgens mij de enige optie om garanties te kunnen geven over een eindresultaat (je kan niet bewijzen dat een onbekende update geen fouten bevat). Maar dat hoeft natuurlijk niet te betekenen dat voor dat vastzetten geen updates zijn uitgevoerd.

Als je dat regelmatig opnieuw doet dan is daar op zich niks mis mee. Maar in praktijk zie ik vooral dat de dependencies pas worden geupgrade als de applicatie klaar is voor een nieuwe release. Er zijn maar weinig applicaties die regelmatig nieuwe updates uitbrengen alleen vanwege bugs/updates van dependencies.

Het maakt wel veel verschil hoe je dat vastzetten doet. Debian garandeerd abi & api-compatiblity. Binnen een release doen die alleen security fixes. Dan heb je dus de garantie (voor zover dat bestaat) dat je applicatie niet zal veranderen. Ik zie het dagelijks goed gaan met duizenden applicaties, dit is geen vaag ideaal maar een heel haalbare oplossing.


PS, beetje flauw, maar fundamenteel kun je nooit bewijzen dat updates geen fouten bevatten, bekend of onbekend. Sterker nog, je kan ook niet bewijzen dat er geen bugs in de huidige versie zitten die pas later boven tafel zullen komen. Je zal altijd rekening moeten houden met het onverwachte.

[bzzzt]

Waarom niet? Misschien begrijp ik je verkeerd, maar je moet je software pas uitbrengen als je de dependencies hebt gecontroleerd.

Wat ik bedoel is dat ook 'officiële releases' soms fouten bevatten. Vaak genoeg gezien dat 'minor updates' van Java of Javascript libraries toch een API break hadden.

Er zijn maar weinig applicaties die regelmatig nieuwe updates uitbrengen alleen vanwege bugs/updates van dependencies.

Je hebt vast nog nooit van 'continuous delivery' gehoord. Is ook nog maar een 14 jaar oud concept...

Het maakt wel veel verschil hoe je dat vastzetten doet. Debian garandeerd abi & api-compatiblity. Binnen een release doen die alleen security fixes. Dan heb je dus de garantie (voor zover dat bestaat) dat je applicatie niet zal veranderen. Ik zie het dagelijks goed gaan met duizenden applicaties, dit is geen vaag ideaal maar een heel haalbare oplossing.

Dat is fijn voor Debian, maar daar heeft een Javascript front-end figuur die z'n libraries via npm naar binnen trekt dus helemaal niks aan. De wereld is groter dan Debian.

PS, beetje flauw, maar fundamenteel kun je nooit bewijzen dat updates geen fouten bevatten,

Je kan wel een unit test bouwen die bewijst dat een bepaald scenario uitgevoerd kan worden zonder crashes.

[Mellow Jack]

Moet wel zeggen dat JavaScript daar wel erg veel last van heeft. Zoals bijv https://qz.com/646467/how...ting-a-tiny-piece-of-code

Maar uiteindelijk is het een keuze. Mijn voorkeur gaat uit om vooral libraries te kiezen met een commerciële partij erachter en zo niet even goed onderzoek te doen naar de levensvatbaarheid van een pakketje. Ik ken teams die helemaal nooit externe pakketjes installeren en ik heb in mijn verleden vaak zat de meest onnozele pakketjes gezien.

Het is uiteindelijk de keuze tussen snelheid van programmeren en het gebruik maken van kennis die je zelf niet hebt vs. de voorspelbaarheid van upgrades.

Mijn voorkeur is gelijk aan die van @CAPSLOCK2000 , liever dat het nu kapot gaat dan dat ik ellende meeneem als technical dept. Uiteindelijk heb je een maand (ota patch je eerst) voordat je productie omgeving geraakt wordt en dat is voor veel issues meet dan voldoende (o.b.v. mijn ervaring). Log4J was zo'n mooi voorbeeld waar je goed kon zien welke partijen het truukje onder de knie hebben en welke niet

[moredruid]

Wat ik bedoel is dat ook 'officiële releases' soms fouten bevatten. Vaak genoeg gezien dat 'minor updates' van Java of Javascript libraries toch een API break hadden.

Dat zit bij de leverancier van Java, niet bij de distro. Die heeft hopelijk iedereen op de hoogte gebracht van het feit dat ze (vaak tegen hun eigen regels/statements in) een API break doen. Voor een distro betekent dat ofwel achter gaan lopen met security fixes (of ze moeten backporten) ofwel meegaan en hopen dat de applicatieontwikkelaars de berichten van hun dependency leverancier heeft gevolgd en zich heeft voorbereid.

[...]
Je hebt vast nog nooit van 'continuous delivery' gehoord. Is ook nog maar een 14 jaar oud concept...

CI/CD voor eigen bugfixes en features is heel normaal. Mocht er een bugfix nodig zijn vanwege een upstream dependency die iets breekt kun je die daarin meenemen. De opmerking van OP was hoe vaak dat specifiek een bugfix voor een upstream dependency nodig was.

Dat is fijn voor Debian, maar daar heeft een Javascript front-end figuur die z'n libraries via npm naar binnen trekt dus helemaal niks aan. De wereld is groter dan Debian.

RedHat en Suse doen dit ook, en zijn binnen hun releases ook ABI/API stable, inclusief het backporten van security fixes. Dat die front-end figuur een ontwikkelaar geen kennis van systeembeheer heeft is een fout van de opleiders en dat soort figuren zelf, niet die van de OS/distro leveranciers (Microsoft Windows incluis). Met hun admin/root rechten en gebrek aan systeem(beheer)kennis zomaar wat binnenhalen en dat dan niet bijhouden. Ik mag hopen dat professionele softwarehuizen hier wat serieuzer mee omgaan.

Je kan wel een unit test bouwen die bewijst dat een bepaald scenario uitgevoerd kan worden zonder crashes.

Niet elke vulnerabitliy/bugfix of update resulteert in een crash. Je hebt ook geen zicht op wat er in de buitenwereld gebeurt en er zijn hele volksstammen die allerlei dingen proberen om een kwetsbaarheid in jouw code te vinden.

[bzzzt]

[quote]
[...]
Dat zit bij de leverancier van Java, niet bij de distro. Die heeft hopelijk iedereen op de hoogte gebracht van het feit dat ze (vaak tegen hun eigen regels/statements in) een API break doen.
[quote]
Ik had het over open source Java libraries, niet het platform. Natuurlijk probeer je zo goed mogelijke upstream libraries te vinden, maar fouten komen met enige regelmaat voor. Daarnaast geeft niemand garantie dat je acuut een bugfix krijgt dus de enige manier om functioneren van je applicatie te garanderen voor zover je kan is versies meepackagen. Punt van mij is dat jouw 'oplossing' van libraries door klanten of distributies laten vervangen domweg geen optie is omdat je dan voor iedere programmeer- of administratiefout van anderen een supportverzoek krijgt.

Niet elke vulnerabitliy/bugfix of update resulteert in een crash. Je hebt ook geen zicht op wat er in de buitenwereld gebeurt en er zijn hele volksstammen die allerlei dingen proberen om een kwetsbaarheid in jouw code te vinden.

Nu verplaats je het doel. Ik heb het over garanderen van de basale functionaliteit van een applicatie, niet over het rekening houden met iedere mogelijke security issue. Security van een niet werkende applicatie is niet heel relevant.

[CAPSLOCK2000]

Wat ik bedoel is dat ook 'officiële releases' soms fouten bevatten. Vaak genoeg gezien dat 'minor updates' van Java of Javascript libraries toch een API break hadden.

Daarom hamer ik er zo op dat Debian wel de verantwoordelijkheid neemt om te zorgen dat dergelijke veranderingen de API niet veranderen, zelfs als upstream dat wel doet.

Je hebt vast nog nooit van 'continuous delivery' gehoord. Is ook nog maar een 14 jaar oud concept...

Goed punt, maar de combinatie met vastgepinde versies is dan wel wat minder logisch.

Dat is fijn voor Debian, maar daar heeft een Javascript front-end figuur die z'n libraries via npm naar binnen trekt dus helemaal niks aan. De wereld is groter dan Debian.

Zeker, het hele punt van mijn oorspronkelijk post is juist dat de oplossing van Debian superieur is en dat de rest daar nog veel van kan leren.

Dat een "javascript font-end figuur" daar geen gebruik van maakt maar zelf via NPM software binnen hengelt is het probleem van dat figuur. Die persoon zal zelf moeten zorgen voor het onderhoud en (api/abi) stabiliteit. Dat mag, maar ik raad aan om het niet te doen als het niet echt nodig is want in praktijk wordt het nogal eens vergeten. De full-service oplossing van Debian is veel fijner. Dat heeft z'n beperkingen, niet alle NPM-packages zijn beschikbaar onder Debian, maar als je binnen die beperkingen kan werken maakt dat je leven wel veel makkelijker.

Je kan wel een unit test bouwen die bewijst dat een bepaald scenario uitgevoerd kan worden zonder crashes.

[moredruid]

Jij denkt helemaal vanuit een Linux distributie context. Je hebt daar niets aan als je een Java applicatie levert. Dan zet je liefst alle dependencies vast. Updaten doe je dan eens per release of in noodgevallen.

Dus je pint je Java vast op een release en doet daarna als applicatiebouwer niets meer om nieuwere java subreleases te testen/ondersteunen. Lekker dan. Ik weet het, in de praktijk gebeurt dit vaker wel dan niet, maar juist Java (77 CVE's tot nu toe in 2024) is zo'n voorbeeld waarvan men ondertussen zou moeten weten dat je dat bij moet houden wil je geen gatenkaas maken van je beveiliging.

[bzzzt]

Waar zeg ik dat je niets moet updaten? Ik zeg alleen dat je versies vast zet als je een geteste en werkende applicatie wil garanderen. Natuurlijk zorg je er voor dat de volgende release weer up to date versies heeft en rol je zo vaak als mogelijk nieuwe versies uit.

Die Java CVEs zijn trouwens heel erg vertekend. Veruit de meeste geven geen risico als je een server-based JVM applicatie draait (of alleen maar in heel exotische configuraties). Maargoed, daarvoor moet je inhoudelijk weten waar je mee bezig bent en dat hebben mensen die niet verder komen dan CVEs tellen niet.

[Kees]

Ik zie juist de beweging de andere kant op met snaps, containers, flatpaks en appimages. Leveranciers willen steeds minder 'alles testen op alle distributies' en leveren dus zelf maar alles mee.

En inderdaad, enterprise staat voornamelijk synoniem voor duur, specifieke usecases, slecht onderhouden, gesloten en aggresieve sales. En bij enterprise software denk ik echt wel aan 'kwaliteit'. Meestal met het woord 'lage' ervoor, dat dan wel.

[CAPSLOCK2000]

Ik zie juist de beweging de andere kant op met snaps, containers, flatpaks en appimages. Leveranciers willen steeds minder 'alles testen op alle distributies' en leveren dus zelf maar alles mee.

Ik vind het een totale ramp want ze verbergen problemen. Begrijp me niet verkeerd, ik heb geen fundamenteel bezwaar tegen containertechniek, daar kun je mooie dingen mee doen, maar het wordt veel verkeerd gebruikt. Het is populair om (bij wijze van spreke) de desktop van de programmeur in een container te proppen zodat die zelfstandig kan draaien en nooit onderhouden hoeft te worden.
Als het niet hoeft dan gebeurt het vaak ook niet.

Containers kunnen heel krachtig zijn en helpen bij splitsen van verantwoordeliijkheden, bv een basis-OS container en een aparte overlay met de applicatie er in, maar in praktijk werkt het maar zelden ze dat je die zelf kan onderhouden bijwerken maar dat je van de leverancier afhankelijk blijft.
Nu moet iedere container apart onderhouden worden terwijl het voor de beheerder lastig is om te zien wat er allemaal in zo'n container zit (om het maar niet te hebben over hoe je dat zelf moet onderhouden).

Ik maak graag gebruik van containers, maar toch vooral als ik zelf bouw zodat ik ze ook zelf kan onderhouden. Upstream is vaak erg nalatig als het gaat om dependencies.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 08:46]

[nvaert1986]

Exact mijn terrein (Linux) en dat is tevens exact wat ik altijd zeg over embedded libraries

Als alternatief voor het embedden geef ik dan meestal het advies mee om evt. het pakket wat gebruikt wordt upstream via (vaak) de GIT repository bij te houden op de stable release en het daarmee te testen als je het zelf embed in je eigen software, wat je evt. nog eenvoudiger kan maken met een docker container of flatpak image.

[downtime]

Klopt. Ik heb zelfs een authenticatie oplossing in beheer gehad waar een oeroude log4j versie in werd gebruikt. De ontwikkelaar had verzuimd om het pakket bij te werken met een nieuwe versie. En zelf log4j updaten brak de applicatie.

[bzzzt]

Een echt "oeroude" versie was waarschijnlijk helemaal niet vulnerable

[downtime]

Niet voor die ene grote bug in Log4j 2. Wel voor legio minder ernstige kwetsbaarheden. Geluk bij een ongeluk I guess.

[bzzzt]

Als je nog log4j 1 gebruikte had je die bug nog niet.

[downtime]

Klopt. Maar daar zaten weer andere kwetsbaarheden in want het was ook niet de laatste versie van Log4j 1 die er gebruikt werd.

[PageFault]

Als ik die zin goed lees deels. Updates is wel een verantwoordelijkheid van beheer. Ontbreken van sterke auth. oplossingen is wel te wijten aan diegene die de software uitbrengt.

[nasdude]

In de praktijk zie ik bij ons op de zaak (grote multinational) dat het beheer (de administrators) vaak niet eens het probleem is, die willen wel, maar het patchen blijft uit omdat management het risico te groot vind, de kosten te hoog zijn of dat er andere prioriteiten zijn zoals de financiële maand/jaar einde of dat de directie een belangrijke vergadering heeft.

[bogy]

Belangrijke directievergadering... Waarom moeten die zo vaak op een golfterrein plaatsvinden?

Veel bedrijfsleiders leren hun prioriteiten pas als het goed misloopt, dat kost meestal veel meer dan de IT managers hun werk te laten doen..

[Pathogen]

Het probleem is dat de software gaten heeft, het beheer te wensen overlaat en beide activiteiten door verschillende partijen gedaan worden met een grote schutting ertussen.

[JoHnnY-Btm]

precies dit, personen / afdelingen communiceren vrijwel slecht met elkaar, dat merk ik ook in mijn werk.

en mocht er een signaal zijn of feedback dan wordt er vrijwel niks mee gedaan of navraag gedaan

[teacup]

En dan te bedenken dat de resultaten uit dit onderzoek nog niet als representatief zijn te beschouwen. De software die nu is onderzocht is door haar makers zelf ter controle aangedragen. Uit de aangehaalde analyse:

De organisaties die zijn meegenomen in het geanonimiseerde onderzoek hebben ons proactief gevraagd om een security-test en hebben daarmee al aandacht voor het periodiek uitvoeren hiervan”, zegt Dennis de Hoog, CEO van Computest Security. “Daarom vormen de resultaten niet noodzakelijk een afspiegeling van het gemiddelde niveau van applicatieveiligheid en verwachten wij dat de situatie in de praktijk slechter is dan de cijfers in ons rapport laten zien.”

Wat nu onderzocht is zou dus een "best in class" groep genoemd kunnen worden. De werkelijke situatie is dus waarschijnlijk slechter dan wat het onderzoek ons schetst.

[Reactie gewijzigd door teacup op 23 juli 2024 08:46]

[bazzi]

ja en dan te bedenken dat de meeste cross-sitescriptingkwetsbaarheden te mitigeren zijn met goede CSP regels...
(even vanuitgaand dat het een "browser" hosted applicatie is , aangezien ze daar het gevaarlijkst zijn )

[CAPSLOCK2000]

Slechts één op de drie? Zo weinig maar? Volgens mij is dat nogal een onderschatting. Ik denk dat het eerder 1 op 30 is dat geen ernstige gaten heeft. Als 1/3 XSS problemen heeft (dat lijkt mij wel te kloppen) zou ik denken dat het totaal aantal kwetsbare systemen hoger ligt. Niet ieder XSS probleem is direct ernstig, maar sites met XSS problemen hebben vaak nog veel meer problemen omdat die niet volgens veilige principes zijn gebouwd.

Die één op drie zie ik als een (eenvoudig) aantoonbare ondergrens, geen realistisch weergave van de situatie.

Paar punten:
- dit soort onderzoeken werkt typisch met een aantal min of meer vaste controles en zijn niet uitputtend
- lang niet alle problemen zijn eenvoudig van buitenaf te vinden
- software wordt typisch getest als die nieuw is en de code nog relatief schoon. Na release zie je vaak nieuwe problemen ontstaan omdat bugfixes zich op details richten en vaak minder goed overdacht worden dan het oorspronkelijke design. In praktijk is de meeste software (logiserwijs) een stuk ouder dan de systemen die nu getest worden.
- libraries en andere componenten krijgen vaak minder aandacht dan de eigen code en verouderen snel
- door kleine problemen te combineren kun je vaak grotere gaten maken, dat zie je in een dergelijk onderzoek niet terug.
- oudere software krijgt minder aandacht bij security tests, lang niet alle bugs daarin zijn gedocumenteerd.
- dit onderzoek richt zich helemaal op webapplicaties. Dat is maar een deel van het landschap, al is het maar omdat onder iedere webapplicatie ook nog een heel OS draait.
- onderzoeken als deze richten zich typisch vooral op commerciele software die actief verkocht wordt, software die intern wordt ontwikkeld/gedraaid voor gebruik komt niet snel in een onderzoek als dit terecht.

[Janbraam]

lama...

[Reactie gewijzigd door Janbraam op 23 juli 2024 08:46]

[HansvDr]

Alleen willen bedrijven met die webapplicaties vaak niet meer betalen als er wat aangepast moet worden. Nou ja, dan maar niet.

[neonite]

En dit zijn dan nog de webapplicaties van bedrijven die volwassen genoeg zijn om een extern security bedrijf in te huren voor een onderzoek..

[Reactie gewijzigd door neonite op 23 juli 2024 08:46]

[Erpenator2]

Iemand een idee hoe je een webapplicatie op de meest gangbare kwetsbaarheden kan testen?

Ik zie in mijn bot blocker dat er ook heel veel gezocht wordt op standaard WordPress en symfony of andere packages kwetsbaarheden.