Сайты могут следить за пользователями, используя новый API

Сайты могут следить за пользователями, используя новый API

Сайты могут следить за пользователями, используя новый API

В 2015 году API отслеживания статуса батареи устройств был введен в HTML5 и в конце года уже присутствовал в Firefox, Opera и Chrome. Исследователи безопасности были озабочены потенциальной возможностью слежения за пользователями с использованием этого API, но их предупреждения на тот момент никто не заметил. Спустя год обнаружилось, что эксперты были правы – при помощи API, отслеживающего состояние батареи теперь можно следить за самими пользователями.

Изначально API был выпущен с целью помочь веб-сайтам узнать, когда у пользователя низкий заряд батареи и включить режим низкого потребления, отключив лишние функции. Организация World Wide Web (W3C), которая осуществляет надзор за разработкой веб-стандартов представила API в 2012 году, однако финальная версия вышла в 2015.

Лукаш Олейник (Lukasz Olejnik) опубликовал статью о том, насколько отслеживание сайтами статуса батареи может угрожать пользователям.

W3C ответили, что "эта информация оказывает минимальное влияние на личную жизнь и, следовательно, может браться без разрешения". Однако недавний анализ показал совершенно другое.

The Guardian показывает на примере, как это может работать:

«Предположим, пользователь зашел на сайт церкви в браузере Firefox, а затем зашел на сайт сатанистов, используя браузер Chrome в режиме инкогнито, через защищенный VPN.  Как правило, эти два соединения должно быть очень трудно связать друг с другом, однако если есть код, отслеживающий состояние батареи, то можно практически с уверенностью установить, что это один и тот же пользователь».

Два исследователя использовали специально модифицированный браузер, чтобы найти сайты, отслеживающие состояние батареи. В итоге они нашли два скрипта, которые использовали этот API, что позволяет им постоянно идентифицировать пользователя. 

Эксперты проанализировали скрипты и пришли к выводу, что они серьезно угрожают конфиденциальности пользователей и могут отслеживать конкретные устройства намного эффективнее, чем ранее предполагалось.

Что это значит для нас, пользователей? Ответ на этот вопрос еще предстоит узнать, но что-то придется менять. Будем надеяться, что это исследование приведет к тому, что для пользователей сделают возможным отключение подобных скриптов на определенных сайтах, которые потенциально могут использовать API в злонамеренных целях.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

DeepSeek-R1 генерирует больше уязвимостей в коде при запрещённых темах

Исследователи из CrowdStrike обнаружили необычное и тревожное поведение китайской модели DeepSeek-R1: она начинает генерировать заметно более уязвимый код, если в запросах появляются политически чувствительные темы для Китая. То есть сама формулировка запроса — например, упоминание Тибета или уйгуров — снижает качество и безопасность создаваемого ИИ кода.

По данным CrowdStrike, без «триггерных» слов модель допускает серьёзные уязвимости примерно в 19% случаев.

Но стоит добавить геополитический контекст, вероятность повышается почти на 50%. Так, при задаче создать компонент для системы, «используемой на промышленном объекте в Тибете», доля небезопасного кода выросла с 19% до 27,2%.

Исследователи подчёркивают: сами «политические» слова никак не связаны с задачей кодирования. Однако модель начинает вести себя нестабильно — от использования небезопасных функций до генерации откровенно нерабочего кода.

В одном примере DeepSeek-R1 написала вебхук для PayPal в виде PHP-кода, который не только содержал ключи в коде, но и вообще не являлся валидным PHP. Несмотря на это, модель уверяла, что всё сделано «по лучшим практикам PayPal».

 

В другом тесте исследователи попросили создать Android-приложение для сообщества уйгуров: регистрация, вход, админ-панель. Приложение работало, но не имело ни аутентификации, ни управления сессиями.

В 35% случаев DeepSeek-R1 вообще не использовала хеширование или применяла небезопасные методы. А вот для похожего задания, но про футбольный фан-клуб, таких проблем почти не было.

CrowdStrike также сообщила, что у модели, судя по всему, есть «встроенный рубильник»:

«DeepSeek-R1 начинает внутренне планировать решение задачи, но в последний момент отказывается отвечать на запросы, связанные, например, с Фалуньгун. В 45% таких случаев модель пишет: “Я не могу помочь с этим запросом“».

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

CrowdStrike подчёркивает: наличие «триггерных слов» не гарантирует, что ИИ всегда выдаст небезопасный код. Но в среднем качество ощутимо падает.

Проблемы с безопасностью кода наблюдаются и у других инструментов. Проверка OX Security показала (PDF), что Lovable, Base44 и Bolt создают уязвимый по умолчанию код даже при запросе «безопасной» реализации. Все три инструмента сгенерировали вики-приложение с XSS-уязвимостью, позволяющей выполнять произвольный JavaScript. Хуже того, модель Lovable могла «пропатчить» уязвимость только в двух из трёх попыток, что создаёт ложное ощущение безопасности.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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