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.

Sterkere bescherming voor het openbare supportformulier

Beveiligingsonderzoeker 0xVicky ontdekte dat ons openbare supportformulier kon worden misbruikt om buitensporig veel verzoeken te versturen. We hebben limieten per bezoeker en voor het totale verkeer toegevoegd, het interne verzendkanaal van het formulier beschermd en de controle van bijlagen aangescherpt. Bedankt voor de verantwoorde melding.

Enabled DNSSEC

A researcher found that DNSSEC was not enabled for createyourvpn.com. We signed the DNS zone, published the DS record in .com, and verified the chain of trust.

Partnersessies kunnen nu volledig worden ingetrokken

Een beveiligingsonderzoeker ontdekte dat een kopie van een partnersessietoken na uitloggen actief kon blijven als die afzonderlijk was vernieuwd. We hebben sessies aan één serveridentiteit gekoppeld: normaal uitloggen trekt nu de volledige huidige sessie in, terwijl ‘Uitloggen op alle apparaten’ alle actieve sessies beëindigt.

MTA-STS en TLS-rapportage ingeschakeld

Een beveiligingsonderzoeker ontdekte dat MTA-STS en TLS-rapportage niet waren ingesteld voor inkomende e-mail van createyourvpn.com. We hebben een MTA-STS-beleid gepubliceerd en TLS-rapportage ingeschakeld. Het beleid werkt eerst in testmodus terwijl we het doorstuurpad van de externe partij controleren; handhaving wordt na foutloze rapporten ingeschakeld.

DMARC-handhaving ingeschakeld

Een beveiligingsonderzoeker ontdekte dat het DMARC-beleid van createyourvpn.com alleen in bewakingsmodus werkte en niet vereiste dat berichten die niet door de controle kwamen, werden afgewezen. We hebben p=reject voor het hoofddomein en sp=reject voor de subdomeinen die geen e-mail verzenden ingeschakeld. Transactionele e-mail blijft gescheiden op aparte verzendsubdomeinen met hun eigen SPF-, DKIM- en DMARC-beleid.