Beveiligingsjournaal.

Interne beoordeling vóór de lancering van het programma

Op 15 juli 2026 zijn we begonnen met een interne beveiligingsbeoordeling van CreateYourVPN. De correcties die we hebben afgerond en opnieuw geverifieerd, zijn hieronder gepubliceerd; er volgen er meer naarmate ze worden uitgerold en bevestigd.

Beveiliging toegevoegd tegen een onveilige cross-origin-configuratie

De huidige production-configuratie stond geen willekeurige origins toe, maar de code liet een gevaarlijke combinatie van parameters toe als een beheerder die verkeerd configureerde. Die combinatie wordt nu bij het opstarten geweigerd en is gedekt door een geautomatiseerde test.

Publiek oppervlak van de production-API verkleind

Interactieve technische API-documentatie was zonder authenticatie bereikbaar. Ze gaf geen toegang tot beschermde gegevens, maar maakte het bestuderen van de interne structuur van de API eenvoudiger. In production is de documentatie nu uitgeschakeld, terwijl ze beschikbaar blijft in een geïsoleerde omgeving voor ontwikkeling.

Cryptografische sleutels van het platform gescheiden op basis van doel

Een interne beoordeling wees uit dat één geheim voor twee verschillende cryptografische taken werd gebruikt. Dit leverde geen directe omzeiling op, maar vergrootte de impact van een sleutelcompromittering. De twee doelen zijn gescheiden en elk wordt nu onafhankelijk geroteerd.

Gegarandeerd wissen van de beheersleutel na verwijdering van een server

Het wissen van de versleutelde beheersleutel liep na netwerkbewerkingen op de achtergrond en werd mogelijk niet herhaald als die bewerkingen mislukten. We hebben het wissen van de sleutel losgekoppeld van de netwerkcascade en een gegarandeerde nieuwe poging toegevoegd. De scenario's van een onbereikbare server en een onderbroken proces zijn gedekt door tests.

Een ongebruikt autorisatiepad van de partner-API verwijderd

De API ondersteunde een extra op cookie gebaseerd autorisatiepad dat de huidige server-side-architectuur niet nodig had. In production is geen cross-site-aanval aangetroffen, maar het extra pad vergrootte het oppervlak voor toekomstige fouten. De API gebruikt nu één expliciet gedefinieerde autorisatiemethode, gedekt door negatieve tests.

De toegang tot het beheerpaneel van de infrastructuur is beperkt

Een externe onderzoeker meldde dat een beheerinterface voor de infrastructuur reageerde vanaf het publieke internet. De interface was beveiligd met authenticatie en er zijn geen sporen van ongeoorloofde toegang gevonden. Het rapport is aanvaard en de toegang is beperkt.

De interface is nu alleen bereikbaar vanaf goedgekeurde adressen, de authenticatie-eisen zijn aangescherpt en de betrokken componenten zijn bijgewerkt. Het resultaat is buiten ons netwerk gecontroleerd. Daarnaast hebben we ons publieke oppervlak doorgelicht en een periodieke controle toegevoegd. De beloning is op het hoogste niveau uitbetaald.

E-mailadressen van storefront-gebruikers worden niet meer bewaard

Iemand vult zijn e-mailadres in om in te loggen op de storefront van een partner, maar het adres blijft niet bij ons hangen: de mail met de code gaat eruit en het adres wordt meteen verwijderd. Het account wordt herkend aan een onomkeerbare vingerafdruk waaruit het adres niet te herleiden is, en ook de accountnaam bevat het niet.

Gebruikers kunnen hun abonnementslink zelf resetten

Een abonnementslink is een geheim: wie hem heeft, krijgt dezelfde toegang als de eigenaar. De gebruiker kan hem zelf resetten in het eigen account: de vorige link werkt niet meer en de bijbehorende toegangsgegevens worden opnieuw uitgegeven. Een zo gesloten link blijft gesloten, ook wanneer gegevens uit een back-up worden hersteld.

Beveiligingsheaders op de storefront-pagina's

De storefronts van partners stuurden de beveiligingsheaders niet die het paneel en de API al stuurden, waaronder de header die andere sites verbiedt de pagina in een iframe te tonen. Accountgegevens of sessies waren zo niet te lezen. De volledige set gaat nu mee met elke reactie van de storefronts, en bewering SR-15 noemt elke frontend die wij hosten.

Sessiebeheer en verzending van inlogcodes

Naar aanleiding van meldingen van een externe onderzoeker hebben we twee aangrenzende gebieden herzien: de levenscyclus van een partnersessie en het traject van de e-mail met de inlogcode. Geen van de bevindingen gaf toegang tot accounts, partnergegevens of gebruikersverkeer.

De wijzigingen in de verzending van inlogcodes zijn uitgerold en geverifieerd. Een aparte actie 'overal uitloggen' is in voorbereiding; tot die er is, beëindigt uitloggen de huidige sessie.