Введены новые требования к защите персональных данных

Введены новые требования к защите персональных данных

Соответствующее постановление №1119 было подписано премьер-министром России 1 ноября текущего года и должно вступить в силу 8 ноября. В соответствии с Федеральным законом «О персональных данных», Кабинет министров РФ установил, что безопасность персональных данных при их обработке должен обеспечивать оператор системы, который использует подобные данные.

В новом постановлении объединены два проекта, один из которых определяет уровни защищенности информации, содержащей персональные данные, а второй – требования к их безопасности. Подробнее ознакомиться с текстом документа можно на сайте www.government.ru.

Постановление, вступающее в силу через 7 дней после подписания, определяет, что набор средств защиты оператор должен выбирать самостоятельно, основываясь на ранее принятых нормативных актах ФСБ и ФСТЭК.

Согласно документу, актуальными угрозами безопасности персональных данных являются условия и факторы, создающие потенциальную опасность несанкционированного доступа к базам данных при их обработке, в результате которого данные могут быть уничтожены, изменены, заблокированы или предоставлены третьим лицам, не имеющим права доступа к таким данным. Кроме того, в постановлении определены 3 типа угроз информационным системам, содержащим пользовательские базы данных, а также 4 уровня защищенности информационных систем, передает soft.mail.ru со ссылкой на Kurs.ru.

Пункт 13 постановления №1119 требует, чтобы в помещениях, где производится обработка персональных данных по 4 (минимальному) уровню защищенности, «был обеспечен режим безопасности». При выполнении этой нормы документа, становится практически невозможным использование мобильных устройств для обработки персональных данных за пределами помещения, где обеспечен режим безопасности.

Следовательно, использование сотрудниками ГИБДД, таможенниками или врачами планшетов и смартфонов за пределами своих офисов становится, мягко говоря, сомнительным.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

Правила обработки запросов при этом добавляются динамически, а фильтрация осуществляется по регулярным выражениям, соответствующим подмножествам знаков, которые могут присутствовать на определенных позициях в URL.

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

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