Adobe Shockwave прекратит свое существование 9 апреля 2019 года

Adobe Shockwave прекратит свое существование 9 апреля 2019 года

Adobe Shockwave прекратит свое существование 9 апреля 2019 года

Adobe начала рассылку электронных писем корпоративным клиентам, в которых компания предупреждает о скором и неизбежном прекращении поддержки решения Adobe Shockwave. В письмах утверждается, что плеер Adobe Shockwave для Windows с 9 апреля 2019 года станет недоступен для скачивания.

Shockwave был выпущен в 1995 году, он подарил интернет-пространству много игр и интересного контента. В 2005 году плеер перешел в руки Adobe вместе с Flash и Shockwave.

К сожалению (или к счастью), современные разработчики стараются реализовывать свои проекты на HTML5 и WebGL, постепенно отходя от использования Flash и Shockwave. Именно это стало причиной решения Adobe полностью прекратить поддержку Shockwave 9 апреля этого года.

Чтобы предупредить корпоративных клиентов заранее, компания разослала электронные письма под заголовком «Adobe Shockwave Product Announcement».

Adobe Flash, к слову, ждет та же судьба — компания планирует прекратить поддержку плагина к концу 2020 года.

Напомним, что разработчики браузеров постепенно отказываются от использования Flash Player от Adobe. Mozilla, например, опубликовала запланированные шаги, благодаря которым браузер Firefox будет плавно отходить от поддержки Flash Player. 

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

Если атакующий успеет первым положить в кеш ответ 404, пользователи вместо главной страницы будут получать ошибку до очистки записи. Получается CPDoS — отказ в обслуживании с доставкой прямо из кеша.

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru