Компанія Google тестує нову функцію, яка не дозволить шкідливим публічним сайтам через браузер користувача атакувати пристрої та сервіси у внутрішніх приватних мережах.
Простіше кажучи, Google планує запобігти атакам шкідливих сайтів в Інтернеті на пристрої відвідувача (наприклад, принтери або маршрутизатори) у його будинку чи комп’ютері. Зазвичай люди вважають ці пристрої безпечними, оскільки вони безпосередньо не підключені до Інтернету і захищені маршрутизатором.
“Щоб запобігти можливості шкідливих веб-сайтів через мережеву позицію агента користувача атакувати пристрої та служби, які, як обґрунтовано передбачається, недоступні з Інтернету в цілому, оскільки знаходяться у локальній мережі користувача або на його комп’ютері”, – йдеться в описі Google. описує цю ідею у документі підтримки.
ПРОДОВЖЕННЯ ПІСЛЯ РЕКЛАМИ
Блокування небезпечних запитів до внутрішніх мереж
Пропонована функція “Захист доступу до приватної мережі”, яка в Chrome 123 працюватиме в режимі “тільки попередження”, проводить перевірку перед тим, як публічний сайт (назва “сайт A”) направить браузер на відвідування іншого сайту (названого “сайт B” ) у приватній мережі користувача.
Перевірки включають перевірку того, чи надходить запит з безпечного контексту, і відправлення попереднього запиту, щоб дізнатися, чи дозволяє сайт B (наприклад, HTTP-сервер, що працює на loopback-адресі або веб-панель маршрутизатора) доступ з публічного сайту за допомогою спеціальних запитів, які називаються CORS-запити попередньої перевірки.
На відміну від існуючих засобів захисту для ресурсів та робочих ресурсів, ця функція зосереджена саме на навігаційних запитах. Її основна мета – захистити приватні мережі користувачів від потенційних загроз.
У прикладі, наданому Google, розробники ілюструють HTML iframe на публічному сайті, який виконує CSRF-атаку, що змінює конфігурацію DNS маршрутизатора відвідувача у його локальній мережі.
Згідно з новим реченням, коли браузер виявить, що публічний сайт намагається підключитися до внутрішнього пристрою, він спочатку відправить на нього попередній запит.
Якщо відповіді немає, з’єднання буде заблоковано. Однак, якщо внутрішній пристрій відповість, він може повідомити браузеру, чи слід дозволити запит, використовуючи ‘Access-Control-Request-Private-Network’ заголовка.
Це дозволяє автоматично блокувати запити до пристроїв у внутрішній мережі, якщо пристрій явно не дозволяє з’єднання з загальнодоступними сайтами.
Поки функція перебуває на стадії попередження, навіть якщо перевірки не пройдуть, вона не блокуватиме запити. Натомість розробники побачать попередження в консолі DevTools, що дасть їм час на адаптацію до початку суворішого застосування.
Однак Google попереджає, що навіть якщо запит буде заблокований, автоматичне перезавантаження браузера дозволить йому пройти, оскільки він розглядатиметься як внутрішнє => внутрішнє з’єднання.
“Захист доступу до приватної мережі не буде застосовуватись у цьому випадку, оскільки ця функція була розроблена для захисту приватної мережі користувачів від більш публічних веб-сторінок”, – попереджає Google. попереджає Google.
Щоб запобігти цьому, Google пропонує заблокувати автозавантаження сторінки, якщо функція Private Network Access раніше її заблокувала.
У цьому випадку веб-браузер виведе повідомлення про помилку, в якому йдеться про те, що ви можете дозволити запит, перезавантаживши сторінку вручну, як показано нижче.
На цій сторінці з’явиться нове повідомлення про помилку Google Chrome “BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS”, яке повідомляє про те, що сторінка не може завантажитись, оскільки не пройшла перевірку безпеки Private Network Access.
Ідея оновлення системи безпеки
Мотивація цієї розробки полягає в тому, щоб не дати шкідливим веб-сайтам в Інтернеті використовувати недоліки пристроїв та серверів у внутрішніх мережах користувачів, які вважалися захищеними від інтернет-загроз.
Це включає захист від несанкціонованого доступу до маршрутизаторів користувачів та програмних інтерфейсів, що працюють на локальних пристроях, що стає все більш актуальним, оскільки все більше програм розгортають веб-інтерфейси, що передбачають неіснуючі засоби захисту.
Згідно з документом підтримки Google почав вивчати цю ідею в 2021 році, щоб запобігти шкідливим запитам зовнішніх веб-сайтів до ресурсів всередині приватної мережі (localhost або приватна IP-адреса).
Хоча безпосередньою метою є зниження ризиків, пов’язаних з атаками “SOHO Pharming” та вразливістю CSRF (Cross-Site Request Forgery), специфікація не націлена на захист HTTPS-з’єднань для локальних служб – необхідний крок для безпечної інтеграції публічних та непублічних ресурсів, але виходить за поточної специфікації.