Скритите опасности в твоите CDN зависимости: Как domain takeover може да срине сигурността на сайта ти

Всеки уебсайт е комбинация от код, който пишеш ти, и код, на който разчиташ без да се замисляш. Сигурността на първия обикновено получава цялото ни внимание. За втория обаче често дори не си спомняме да проверим кога е писано последно.

Наскоро видяхме ситуация, която показва точно колко опасно може да бъде това.

Историята на един domain, който никой не искаше

Представи си следното: услуга за CDN, която захранва хиляди WordPress сайтове с десетилетие, изведнъж затваря врати. Компанията е придобита, операциите приключват и накрая регистрацията на domain-а изтича. Нов човек го регистрира и вече контролира всички поддомейни, към които още сочат стари линкове.

Това не е хипотетичен сценарий. Точно това се случи с netdna-ssl.com — домейнът зад MaxCDN, услуга за статично съдържание, която много клиенти на WP Engine използваха. Когато MaxCDN беше погълната от StackPath и после закрита, домейнът не беше подновен. През юли 2025 обаче някой го регистрира отново.

Новият собственик веднага получи контрол върху wildcard DNS за цялото пространство *.wpengine.netdna-ssl.com. Всеки хеширан поддомейн, към който сайтът ти все още сочи? Вече се контролира от напълно непознат човек, който управлява сайт за сваляне на Instagram съдържание с Google AdSense.

Защо това е по-сериозно, отколкото си мислиш

Може би си казваш: "Е, и какво от това? Никой вече не го използва. Това е наследствена инфраструктура." Но тук интуицията ни подвежда.

Проучвания показват, че около 4 000 файла в GitHub все още съдържат препратки към тези изоставени домейни. Не става дума за изоставени хранилища — проекти като Mozilla's webxr-polyfill, както и сайтове на Kong, Nextcloud, Yale Daily News и много други организации, все още теглят активи от тези deprecated крайни точки.

Още по-обезпокоително? Cloudflare Radar класира netdna-ssl.com в топ 20 000 домейна в световен мащаб. Това означава, че реални браузъри все още разрешават това име, в значителни обеми. Тези препратки не са археологически артефакти — те са активни, живи зависимости.

Проблемът с „заряден пистолет"

Ето какво прави тази ситуация особено опасна. В момента тези legacy URL адреси към активите са просто счупени. Новият собственик е настроил Cloudflare със стандартен SSL сертификат, който покрива apex домейна и някои proxy поддомейни, но не и wildcard шаблона за наследствените хостове. Когато браузър се опита да зареди скрипт или шрифт от поддомейн като xyz123.wpengine.netdna-ssl.com, TLS ръкостискането се проваля.

В краткосрочен план това защитава потребителите. Браузърът блокира съдържанието вместо да го изпълни. Но помисли какво означава това: нападателят вече има пълен DNS контрол. Вече има монетизационна инфраструктура. Вече има хостинг. Единственото нещо, което разделя това от катастрофа, е една единствена конфигурационна настройка в Cloudflare Advanced Certificate Manager.

Това, което експертите по сигурност наричат „зареден пистолет" — уязвимост, която в момента не е експлоатируема, но може да стане катастрофална с минимално усилие от страна на нападателя.

Вече сме виждали това

Ако този сценарий ти се струва познато, то е защото наблюдавахме същото през юни 2024 с polyfill.io. Домейн, на който целият уеб се беше научил да се доверява, смени собственика, и над 100 000 сайта изведнъж се оказаха в позиция да сервират код от оператор с напълно различни намерения. Моделът на доверие се счупи, защото объркахме „този домейн винаги е сервирал безопасно съдържание" с „този домейн винаги ще сервира безопасно съдържание".

Неприятната истина е, че ние базираме сигурността си на домейни, а не на код. Когато домейните сменят собственици, всеки сайт, който им се е доверявал, наследява намеренията на новия собственик — каквито и да са те.

Какво да направиш ВЕДНАГА

Провери зависимостите си незабавно. Претърси кодовите си бази, базите данни и документацията за всякакви препратки към deprecated или трети страни CDN домейни. Не предполагай, че защото дадена услуга е спряла, нейните домейни са инертни.

Помисли за self-hosting на критични активи. Ако шрифт, скрипт или stylesheet е от съществено значение за приложението ти, премести го вкъщи. Минорните инфраструктурни разходи са незначителни в сравнение с риска потребителите ти да теглят код от недоверен източник.

Имплементирай Subresource Integrity (SRI). Когато трябва да използваш third-party CDN ресурси, добави криптографски хешове към <script> и <link> таговете си. SRI гарантира, че дори нападател да получи контрол върху домейн, не може да сервира модифициран код, без да счупи integrity проверките ти.

Мониторирай своя supply chain. Услуги като Report URI и различни CSP мониторинг инструменти могат да те известят за неочаквани домейни, появяващи се в сигурностните ти репорти. Настрой тези аларми и ги восприемай сериозно.

По-голямата картина

Този инцидент подчертава фундаментално напрежение в съвременната уеб разработка: ние строим върху доверие, но рядко го преразглеждаме с времето. Зависимост, която беше напълно безопасна миналата година, може да сервира malware догодина, ако домейнът смени собственика.

В NameOcean говорим много за domain сигурност — DNSSEC, SSL сертификати, registrar locks. Но истории като тази ни напомнят, че истинското предизвикателство не е само да пазиш собствените си домейни; то е да бъдеш внимателен към домейните, на които избираш да се доверяваш, и да имаш системи за откриване кога това доверие може да е било поставено погрешно.

Уебът работи на доверие. Увери се, че твоето е поставено разумно.