Biztonsági napló.

Belső felülvizsgálat a program indítása előtt

2026. július 15-én belső biztonsági felülvizsgálatot indítottunk a CreateYourVPN-en. A befejezett és újraellenőrzött javításokat alább közöljük; továbbiak követik majd, ahogy bevezetjük és megerősítjük őket.

Védelmi korlát bevezetve a nem biztonságos cross-origin konfiguráció ellen

A jelenlegi production konfiguráció nem engedélyezett tetszőleges origineket, a kód azonban lehetővé tett egy veszélyes paraméter-kombinációt, ha egy üzemeltető rosszul állította be. Ezt a kombinációt mostantól indításkor elutasítjuk, és automatizált teszt fedi le.

Csökkentettük a production API nyilvános felületét

Az API interaktív műszaki dokumentációja hitelesítés nélkül elérhető volt. Nem adott hozzáférést védett adatokhoz, de megkönnyítette az API belső felépítésének tanulmányozását. Production környezetben a dokumentáció mostantól ki van kapcsolva, miközben fejlesztéshez egy elszigetelt környezetben továbbra is elérhető marad.

A platform kriptográfiai kulcsai cél szerint szétválasztva

Egy belső felülvizsgálat feltárta, hogy egyetlen titkot két különböző kriptográfiai feladatra használtak. Ez nem hozott létre közvetlen megkerülést, de kiszélesítette egy kulcs kompromittálódásának hatókörét. A két célt szétválasztottuk, és mindegyik önállóan rotálódik.

Garantált a felügyeleti kulcs törlése a szerver törlése után

A titkosított felügyeleti kulcs törlése a háttérben zajló hálózati műveletek után futott, és azok meghiúsulása esetén elmaradhatott az ismétlés. A kulcstörlést leválasztottuk a hálózati kaszkádról, és garantált újrapróbálkozást adtunk hozzá. Az elérhetetlen szerver és a megszakadt folyamat forgatókönyveit tesztek fedik le.

Eltávolítottunk egy nem használt partneri API-engedélyezési útvonalat

Az API támogatott egy további, cookie-alapú engedélyezési útvonalat, amelyre a jelenlegi server-side architektúrának nem volt szüksége. Production környezetben nem találtunk cross-site támadást, de a plusz útvonal kiszélesítette a jövőbeli hibák felületét. Az API mostantól egyetlen, kifejezetten meghatározott engedélyezési módszert használ, amelyet negatív tesztek fednek le.

Korlátoztuk az infrastruktúra kezelőfelületéhez való hozzáférést

Egy külső kutató jelezte, hogy az infrastruktúra kezelésére szolgáló adminisztrációs felület válaszolt a nyilvános internetről. A felület bejelentkezéssel volt védve, jogosulatlan hozzáférésre utaló nyomot nem találtunk. A jelentést elfogadtuk, a hozzáférést korlátoztuk.

A felület mostantól csak jóváhagyott címekről érhető el, a hitelesítési követelmények szigorodtak, az érintett komponenseket frissítettük. Az eredményt a hálózatunkon kívülről ellenőriztük. Emellett áttekintettük a nyilvános felületünket, és rendszeres ellenőrzést vezettünk be rá. A jutalmat a legmagasabb szinten fizettük ki.

A kirakatok felhasználóinak e-mail-címét már nem őrizzük meg

Valaki beírja az e-mail-címét, hogy belépjen egy partner kirakatába, de a cím nálunk nem marad meg: a kódot tartalmazó levél elmegy, a cím pedig azonnal törlődik. A fiókot visszafordíthatatlan ujjlenyomat alapján ismerjük fel, amelyből a cím nem állítható helyre, és a fiók neve sem tartalmazza.

A felhasználó maga is visszaállíthatja az előfizetési hivatkozását

Az előfizetési hivatkozás titok: aki megszerzi, ugyanolyan hozzáférést kap, mint a tulajdonosa. A felhasználó a fiókjában maga is visszaállíthatja: a korábbi hivatkozás megszűnik működni, a mögötte lévő hozzáférések pedig újra kiadásra kerülnek. Az így lezárt hivatkozás lezárva marad akkor is, ha az adatokat biztonsági mentésből állítják vissza.

Biztonsági fejlécek a partnerüzletek oldalain

A partnerek üzletei nem küldték azokat a biztonsági fejléceket, amelyeket a panel és az API már küldött — köztük azt sem, amely megtiltja más webhelyeknek az oldal keretbe ágyazását. Fiókadatot vagy munkamenetet így nem lehetett kiolvasni. A teljes készlet mostantól minden üzleti válasszal kimegy, az SR-15 állítás pedig néven nevezi az összes általunk üzemeltetett frontendet.

Munkamenetek kezelése és a belépési kódok kézbesítése

Egy külső kutató jelentései nyomán két szomszédos területet tekintettünk át: a partner-munkamenet életciklusát és a belépési kódot tartalmazó e-mail útját. Egyik megállapítás sem adott hozzáférést fiókokhoz, partneradatokhoz vagy felhasználói forgalomhoz.

Erősebb védelem a nyilvános támogatási űrlaphoz

0xVicky biztonsági kutató felfedezte, hogy nyilvános támogatási űrlapunk túl sok kérés beküldésére használható. Korlátokat vezettünk be látogatónként és a teljes forgalomra, védetté tettük az űrlap belső beküldési csatornáját, és megerősítettük a mellékletek ellenőrzését. Köszönjük a felelős bejelentést.

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.

A partnerszekciók mostantól teljesen visszavonhatók

Egy biztonsági kutató felfedezte, hogy egy partnerszekció tokenjének másolata kijelentkezés után is aktív maradhatott, ha külön frissítették. A munkameneteket egységes szerveroldali azonosítóra állítottuk át: a normál kijelentkezés mostantól a teljes aktuális munkamenetet visszavonja, a „Kijelentkezés minden eszközről” művelet pedig minden aktív munkamenetet lezár.

MTA-STS és TLS-jelentések bekapcsolva

Egy biztonsági kutató felfedezte, hogy a createyourvpn.com bejövő leveleihez nem volt beállítva az MTA-STS és a TLS-jelentés. Közzétettünk egy MTA-STS-házirendet, és bekapcsoltuk a TLS-jelentéseket. A házirend először tesztmódban működik, amíg ellenőrizzük a külső szolgáltató továbbítási útvonalát; a kikényszerítést hibamentes jelentések után kapcsoljuk be.

DMARC-kikényszerítés bekapcsolva

Egy biztonsági kutató felfedezte, hogy a createyourvpn.com DMARC-házirendje csak megfigyelési módban működött, és nem követelte meg az ellenőrzésen megbukó üzenetek elutasítását. A fő domainen bekapcsoltuk a p=reject, a levelet nem küldő aldomaineken pedig az sp=reject beállítást. A tranzakciós levelek továbbra is külön küldő aldomaineken működnek, saját SPF-, DKIM- és DMARC-házirenddel.