Ons Coordinated Vulnerability Disclosure-beleidHere's the English translation of this policy

Onze afhankelijkheid van onze digitale infrastructuur wordt alleen maar groter. Dat geldt voor de maatschappij als geheel, maar ook voor onszelf. We vinden daarom dat overheden en organisaties (en wijzelf dus ook) sterk moeten inzetten op de beveiliging van onze digitale infrastructuur. We realiseren ons ook dat het, ondanks de beste bedoelingen en zorg, kan gebeuren dat er in de beveiliging van systemen een kwetsbaarheid voorkomt. Als jij een zwakke plek in één van onze systemen vindt, dan horen we dat heel graagWat onze belangrijkste afwegingen voor dit beleid waren?. Wij kunnen dan de kwetsbaarheid oplossen.

Wat wij van jou verwachten:

• Als je een kwetsbaarheid in een van onze systemen onderzoekt, hou je rekening met proportionaliteit van de aanval. Je hoeft niet aan te tonen dat als je de grootste DDoS-aanval uit de historie van het internet op onze website uitvoert, we even niet meer bereikbaar zijn. Dat weten we. Ook begrijpen we dat als je met een shovel ons kantoor inrijdt, je waarschijnlijk wel een laptop buit kunt maken.
• Die proportionaliteit speelt ook een rol bij het aantonen van de kwetsbaarheid zelf. Je bekijkt of verandert niet meer gegevens dan strikt noodzakelijk om de kwetsbaarheid aan te tonen. Als je bijvoorbeeld onze voorpagina kunt aanpassen, voeg je ergens een non-controversieel woord toe, in plaats van de volledige pagina over te nemen. Als je toegang weet te krijgen tot een database, volstaat een lijstje van de tabellen of de eerste regel uit één van die tabellen.
• Een kwetsbaarheid in een van onze systemen meld je zo spoedig mogelijk door een e-mail te sturen aan security@bitsoffreedom.nl. Bij voorkeur verstuur je de melding versleuteld met OpenPGP. Je voorziet de melding van voldoende informatie waarmee wij het probleem kunnen reproduceren en onderzoeken.

• Je deelt de kennis over de kwetsbaarheid niet met anderen zolang wij de kwetsbaarheid nog niet hebben opgelost en de redelijke oplossingstermijn niet al ruimschoots is verstreken.
• Je verwijdert alle vertrouwelijke gegevens die je hebt verkregen in je onderzoek direct nadat wij de kwetsbaarheid hebben opgelost.

Wat je van ons mag verwachten:

• We reageren binnen drie dagen inhoudelijk op je melding, inclusief de verwachte oplossingstermijn. Uiteraard houden we je ook daarna regelmatig op de hoogte van de voortgang van het oplossen van het probleem.
• We lossen de kwetsbaarheid zo snel mogelijk op. Ook hier speelt proportionaliteit een belangrijke rol: de termijn voor het oplossen van een kwetsbaarheid is afhankelijk van verschillende factoren, waaronder de ernst en de complexiteit van de kwetsbaarheid.
• Als je je aan bovenstaande verwachtingen houdt, zullen wij geen juridische stappen tegen je ondernemen ten aanzien van je melding.
• We vinden het belangrijk om je de credits te geven die je toekomen – en die je wenst. We zullen je naam bij een publicatie over de kwetsbaarheid alleen vermelden als je daarmee instemt.
• Als dank voor je hulp in het beter beschermen van onze systemen, belonen we je graag voor de melding van een tot dan toe ons nog onbekende kwetsbaarheid. De beloning is afhankelijk van de ernst van de kwetsbaarheid en de kwaliteit van de melding.
• Mocht je een kwetsbaarheid vinden in software die wij gebruiken maar die door een andere partij gemaakt wordt en die kwetsbaarheid valt onder een bug bounty program, dan is een eventuele bounty uiteraard voor jou.

Versie 1.0 van 23 juni 2017.

Hieronder vind je een overzicht van kwetsbaarheden die eerder zijn gemeld en opgelost:

• Op 16 maart 2021 meldde Mart Gil RoblesMart Gils LinkedIn-profiel een XSS-kwetsbaarheid in een van onze websites. Op ons verzoek heeft Mart Gil deze kwetsbaarheid ook gemeld bij de makers van de open source software die we op deze website draaiden, zodat deze kwetsbaarheid ook upstream opgelost werd.
• Op 21 december 2020 meldde Siva RajendranSiva's LinkedIn-profiel dat een van onze nginx-configuraties zwakke CBC-ciphers bevatte. We hebben de configuratie aangepast en de ciphers daaruit verwijderd.
• Op 30 juli 2020 meldde Ayush BadhekaAyush' LinkedIn-profiel dat een van onze sites, die via https bereikbaar zijn, http inhoud bevatte. We hebben de inhoud naar https omgezet.
• Op 17 mei 2020 meldde Pritam MukherjeePritam's LinkedIn-profiel dat twee van onze sites kwetsbaar waren voor clickjacking. We hebben dit opgelost door de goede CSP headers in te stellen in onze webserver.
• Op 27 april 2020 meldde Mohammed MidoMohammed's LinkedIn-profiel dat onze installatie van Jirafeau kwetsbaar was voor een brute-force aanval. We hebben dit verholpen door ratelimiting in te stellen.
• Op 8 april 2020 meldde Ahmet Ümit BayramAhmet Ümit's website dat een van onze systemen kwetsbaar was voor een cross-site scripting aanval. We hebben het systeem offline gehaald.
• Op 24 april 2020 meldde Syed Muhammad AsimAsim's LinkedIn-profiel dat een van onze pagina's 'mixed content' bevatte, oftewel een pagina die toegankelijk is via https, bevat inhoud die toegankelijk is via http. Omdat de link dood was, hebben we deze verwijderd.
• Op 7 november 2019 meldde Alwoares NaeemAlwoares' Twitterprofiel dat het mogelijk was de IP-adresblokkade van ons CRM-systeem deels te omzeilen. Hierdoor was een deel van de webinterface onbedoeld toegankelijk buiten ons kantoornetwerk. Het in kunnen zien van de data in het CRM-systeem is alleen mogelijk na additionele authenticatie met een geldig account, maar deze kwetsbaarheid was alsnog ongewenst. De foutieve nginx-configuratie is hierop aangepast.
• Op 4 april 2019 ontdekte Chawda MrunalChawdas LinkedIn-profiel dat het mogelijk was om een PHP-foutmelding op onze website te vertonen. Deze foutmeldingen waren namelijk slechts gedeeltelijk uitgeschakeld. Omdat er gevoelige informatie in die foutmeldingen zou kunnen zitten hebben we het tonen van foutmeldingen nu volledig uitgeschakeld.
• Op 11 augustus 2018 gaf Shivam Kamboj DattanaShivams Twitterprofiel ons een paar handige tips om onze nieuwe reverse proxy (Traefik) beter te beveiligen.
• Op 26 juli 2018 meldde Arun K. MishraAruns Twitterprofiel dat de ontwikkelaarsmodus van onze Weblate-installatie (vertaalsoftware op basis van Django) nog aan stond. Hierdoor bestaat de kans dat gevoelige informatie uitlekt. We hebben de ontwikkelaarsmodus uitgezet en uit voorzorg Django's secret_key en het administratorwachtwoord vervangen.
• Op 10 juli 2018 meldde Ashish KunwarAshishs Twitterprofiel dat de Git-configuratie op de website Mapping the Movement (deze website is niet meer toegankelijk) in te zien was. Hier stond een access token van een publieke Git repository in. Er was dus geen toegang mogelijk tot gevoelige informatie, maar uit voorzorg (ook voor andere projecten) hebben we de toegang tot de configuratie geblokkeerd en het access token vervangen.
• Op 6 juli 2018 merkte Thrivikram GujarathiThrivikrams LinkedIn-profiel op dat de WordPress-installatie van het Privacy Café al een tijdje niet geüpdatet was. Dit kwam doordat de updatenotificaties niet naar het juiste e-mailadres gestuurd werden. De installatie is inmiddels weer up-to-date.
• Op 4 juli 2018 rapporteerden Kishan Kumar, Orkhan YolchuyevOrkhans LinkedIn-profiel en Vikash ChaudharyVikash' LinkedIn-profiel enkele kwetsbaarheden in een tool die we gebruikten voor het genereren van Twitterplaatjes. We hebben de tool uit voorzorg offline gehaald.
• Op 3 juli 2018 meldden Orkhan YolchuyevOrkhans LinkedIn-profiel en Havoc GuhanGuhans Facebookprofiel een XSS kwetsbaarheid in Framadate, de datumprikker die we op https://kies.bof.nl gebruiken. Omdat we de laatste versie draaiden hebben we op 6 juli de ontwikkelaars van Framadate op de hoogte gesteld, die op 9 juli al een beveiligingsupdate hadden uitgebracht.
• Op 24 januari 2018 merkte Kirtikumar Anandrao RamchandaniKirtikumars LinkedIn-profiel op dat de HTTP Strict Transport Security-header (kortweg HSTS-header) van https://www.bof.nl verdwenen was. Dit kwam doordat de header tijdens onderhoud per ongeluk overschreven was. De HSTS-header zorgt ervoor dat browsers onthouden dat de website alleen via een versleutelde verbinding opgehaald mag worden.
• Op 1 januari 2018 wees Ifrah ImanIfrahs website ons op de mogelijkheid voor clickjacking op onze Etherpad-installatie. We schatten het risico laag in, maar hebben als voorzorgsmaatregel een X-Frame-Options header toegevoegd en zijn daarnaast bezig met het uitrollen van Content Security Policies op al onze websites.
• Op 27 november 2017 merkte RhiannonRhiannons Twitterprofiel op dat onze website verouderde scripts gebruikte die kwetsbaar waren voor Cross-Site Scripting aanvallen. We pakten dat aan door ons updatebeleid aan te passen en JavaScript-packages te beheren met YarnYarn package manager.
• Op 1 november 2017 wees Steven HamptonStevens Twitterprofiel ons op een Adobe Flash-bestand dat standaard in WordPress aanwezig is. Omdat we liever HTML5 gebruiken en er regelmatig beveiligingsproblemen zijn met Flash hebben we de toegang tot het bestand geblokkeerd.
• Op 17 oktober 2017 wees Zeeshan KhalidZeeshans Twitterprofiel ons op de mogelijkheid om informatie over de PHP-omgeving (phpinfo) van een website die word gerund door vrijwilligers in te zien. Hierop hebben we dit onmogelijk gemaakt en de webmaster ingelicht. Daarnaast vond Zeeshan een XSS-kwetsbaarheid in Framadate, de software die wij gebruiken op kies.bof.nl. Framasoft heeft op 11 april 2018 een update hiervoor uitgebracht.
• Op 12 oktober 2017 wees Jatan VoraJatans Twitterprofiel ons op een bekend probleem in GitLab waardoor in sommige gevallen de gebruiker werd doorgestuurd naar de host in de X-Forwarded-Host header. Deze configuratiefout (die door compatibiliteitsproblemen nog steeds in de standaard GitLab-code zit) kan in combinatie met een XSS kwetsbaarheid een beveiligingsrisico vormen. We hebben hierop alle X-Forwarded-Host headers statisch ingesteld.
• Op 10 oktober 2017 wees Vishal ShuklaVishals Twitterprofiel ons op een XSS kwetsbaarheid in de Discourse-installatie van het Privacy Café. De kwetsbaarheid was opgelost na het updaten naar de laatste versie.
• Op 8 oktober 2017 wees Olivier BegOliviers website via Wayback Machine ons op verkeerd geconfigureerde toegangscontrole en nog een XSS-kwetsbaarheid in onze Framadate-installatie. Beide problemen zijn verholpen.
• Op 6 oktober 2017 wees Muztahidul Islam TanimMuztahiduls Twitterprofiel ons op een XSS-kwetsbaarheid in onze Framadate-installatie. Dit probleem was opgelost na het updaten naar de laatste versie.
• Op 6 september 2017 meldde Huy KhaHuy's LinkedIn profile nog een kwetsbaarheid in onze website: het bleek mogelijk om via onze website namens ons een e-mail te verzenden. Daarbij maakte hij gebruik van een bug in een Wordpress-module. De module is nu uitgeschakeld. We hebben ook een bug report aangemaakt bij de ontwikkelaars van die module.
• Op 16 augustus 2017 heeft Huy KhaHuy's LinkedIn profile bij ons DOM XSS kwetsbaarheid gemeld op onze website. Het bleek dat een stukje custom javascript informatie uit een URL niet goed opschoonde.
• Op 15 augustus 2017 heeft Prial Islam (ErrOr SquaD BD)Prial's website ons gewezen op de inherente onveiligheid van de XMLRPC-api van Wordpress. Hij liet zien hoe makkelijk die te brute-forcen was. We hebben hem daarom uit gezet. Daarnaast meldde hij ook nog een paar kleine kwetsbaarheden met een laag risico zoals het programmatisch kunnen verhogen van het aantal likes van een video.
• Op 17 juli 2017 meldde Daan GoumansDaan's LinkedIn-profiel ons dat op een van onze websites de credentials voor toegang tot de achterliggende database gemakkelijk te achterhalen waren. Het betrof een website die beheerd wordt door vrijwilligers. De oorzaak was een fout in de configuratie van een van de gebruikte frameworks.
• Op 9 juni 2017 meldde Remy van ElstRemy's eigen website ons dat het mogelijk was om een SSL/TLS-certificaat aan te vragen voor onze domeinnaam freedom.nl. Hij had daarvoor een standaard e-mailadresRemy schreef eerder al eens over een vergelijkbaar probleem bij zijn eigen provider geregistreerd binnen dat domein. De oorzaak was een typfout bij het opstellen van de lijst met preventief geblokkeerde accounts.