Even een open deur intrappen:
Zou het open source geweest zijn, dan hadden er veel mensen aan een oplossing kunnen werken, nu is het maar de vraag wat en hoe e.e.a. is opgelost.

Deur is toch open....
Kans is dat de fout dan ook al eerder gevonden was, maar niet gemeld was. Immers fouten kan je misbruiken en leveren geld op.

Dit gebeurt niet alleen met MS of Google code, maar dit kan voor alle code zo zijn, probeer het eens met PHP zonder cheatsheets ernaast!

Je kunt beter inzetten om aan te geven hoe zo'n fout in het vervolg minder vaak zal worden gemaakt, dus inzetten op coderen met veiligheid als prioriteit en niet als iets, dat ook nog moet. Dan gaan grey and black hats er niet op zitten inzetten en hoeven white hats niet zo veel moeite te doen het achteraf omhoog te krijgen. Je moet dan wel even doorgraven.

Van te voren dus bijvoorbeeld rekening houden met (random voorbeeld) bij een bepaald JavaScript rendering script - en of daarna JSRender ook wel in een bepaalde versie kan worden gebruikt of dat die reeds afgeserveerd dient te worden (retirement). Verder ook kijken naar overschreden aflooptijd = vaak verdacht.

Ik weet dat er vaak de tijd niet voor is, grondig testen en debuggen, maar het kan ook vaak door een doorgezette bepaalde vaste veiligheidshouding bereikt worden. Beveiligings update code vraagt toch wel om terdege doortesten. Neem desnoods wat autistische coders in dienst, die blijven doorgaan met een echte pitbull mentaliteit, waar anderen al afhaken en het combinatoir denken kan tot slimme niet verwachte resultaten voeren - uniciteit, want ze gebruiken geen eigen tools.

Trouwens wat vandaag nog voor veilig wordt gehouden, kan morgen al onveilig(er) zijn. Alles is hier relatief.

luntrus

En de praktijk wijst uit dat die 'vele ogen' in de praktijk aan van alles werken, maar niet of nauwelijks aan verbeteren van de beveiliging en al helemaal niet aan het vinden van kwetsbaarheden *om ze op te lossen*.

Zie oa:
https://opensource.com/article/17/10/many-eyes
https://www.zdnet.com/article/six-open-source-security-myths-debunked-and-eight-real-challenges-to-consider/

https://blog.xot.nl/2018/06/04/transparency-is-the-perfect-cover-up-if-the-sun-does-not-shine/
"The mantra assumes three things. First, that an unlimited number of eyeballs, i.e independent experts, is available to scrutinise the growing pool of open source projects. Second, that these experts have an interest or incentive to spend some of their (valuable) time on this. And third, that every open source project is equally likely to attract the attention of a sufficient number of experts.

All three assumptions are unfounded.
The number of experts is severely limited. These experts may often be inclined to start their own open source project rather than contributing to someone else’s project
….
Without sun, transparency is the perfect cover, hiding in plain sight what everyone fails to see.[/quote]

@karma4

Dan zal je daar dus niet op moeten inzetten. Je zal programmeurs moeten vinden, dus de vereiste bagage zich al veel eerder hebben moeten verschaffen, Het zal moeten gebeuren via het onderwijs en speciale training.

Dit alles, zodat niet de beveiligingsdeskundige(n) achteraf, maar de coders zelf hier al oog voor hebben. Maar dan zal je ze er wel goed voor moeten opleiden. Dan kom je er niet met een verhaaltje: "Er bestaan white, grey & black hats" en toetsjes XSS-DOM kwetsbaarheden en algemene netwerkbeveiligingsleer. Neen, laarzen aan en in de javascript loopgraven zelf gaan staan. Maak maar modderige voeten, maar je leert enorm veel en zeker ook dingen waar je dan op gaat letten. Je leert het code-gras groeien a.h.w.

In een gesprekje met een Duitse security docent bij een hogere IT opleiding heb ik het hier uitvoerig over gehad. Er zijn genoeg bereidwilligen, echter vaak "too little & too late".

Ik kan ook wel bedenken welke partijen hier niet voor te vinden zullen zijn, namelijk diegenen die goed garen spinnen bij een voortgezette onveilige situatie voor de meesten onder ons en een veilige(r) omgeving voor de kleine kring (alleen de natuurvan de voortgaande proliferatie maakt dat een streven dat onmogelijk is op den duur). Eens onveilig betekent steeds onveilig. Helaas.

Daarnaast moet onveilg geworden code steeds aangepast en/of vervangen worden. Ook staan veiligheidsmaatregelen niet op zich goed ingesteld, zowel op de server- als aan de client zijde. Hier stak ik heel veel op van Bitwipers uiteenzettingen hier.
Dank, beste Bitwiper.

Voorbeeld scan hier eens op een willekeurige website https://retire.insecurity.today/ en analyseer de kwetsbare code vervolgens eens op errors (met behulp van een linter en of een unpacker).
Test de willekeurige website na via https://sonarwhal.com/

Beide scanners, die van de Noor Erlend Oftedal en de scanner van Sonarwahl, die werkt met Snyk detectie, komen niet altijd tot het zelfde aantal kwetsbare bibliotheken. Maar het is raadzaam voor iedere website beheerder/eigenaar/tester.

Ja allemaal JQuery developers, die deze af te voeren bibliotheken hebben ontworpen. Wat je eens hebt verworven, zal je ook te zijner tijd op een zeker moment moeten afvoeren. Een wet van de IT-Meden en Perzen, zeg ik dan maar.

Ik word een beetje moe van dit steeds weer te moeten herhalen en nog luisteren er weinigen of hebben er ogen voor en oren naar. Maar, jij, karma4 weet dit inmiddels even goed als ik. Daarom geven we niet op met "preaching to the choir".

luntrus