Google: безопасный хостинг изображений и текста практически невозможен
Михал Залевски (Michal Zalewski) из отдела безопасности Google разродился философской статьёй о хостинге контента в современном вебе. Компания Google занимается этим много лет и накопила большой опыт, из которого можно сделать определённые выводы. Главный вывод, который озвучивает Михал, — хостинг пользовательского контента является чрезвычайно опасным делом.
Исторически, все браузеры и плагины для браузеров проектируются таким образом, чтобы отображать несколько видов контента, игнорируя любые ошибки на веб-сайте. Во времена статического HTML и простых веб-приложений это было нормальным подходом, потому что весь контент находился под контролем веб-мастера.
Всё изменилось в середине 2000-х годов, когда обнаружилась новая проблема: умный хакер мог манипулировать браузером, подсовывая ему на первый взгляд безопасные изображения и документы в форматах HTML, Java или Flash — и получать возможность исполнять вредоносные скрипты в контексте приложения, которое отображает эти документы (межсайтовый скриптинг).
За последние годы веб-браузеры постепенно стали совершенствоваться. Например, разработчики браузеров начали вводить ограничения на различные типы изображений и неизвестные типы MIME. Однако, веб-стандарты предусматривают способы обхода такой защиты, например, игнорирование любого типа MIME при загрузке контента через <object>, <embed> или <applet> — это гораздо сложнее исправить, и такие действия ведут к появлению уязвимостей, похожих на баг GIFAR.
Отдел информационной безопасности Google в эти годы принимал активное участие в расследовании многих уязвимостей, связанных с отображением контента. В реальности, многие методы борьбы с ними были впервые реализованы в Chrome. К сожалению, проблема не решена до сих пор: для каждой закрытой дыры исследователи вскоре находят новый способ её эксплуатировать или обнаруживают новую уязвимость в браузере. Два недавних примера — уязвимость Byte Order Mark (BOM) и атаки MHTML, которые до сих пор успешно осуществляются в интернете.
Какое-то время отдел информационной безопасности Google возлагал надежды на инспекцию контента перед исполнением, но со временем они поняли, что и здесь невозможно всего предусмотреть. Например, хакер Александр Добкин продемонстрировал Flash-апплет, используя только символы алфавита и цифры, а один сотрудник Google сумел сконструировать изображение, в которое можно внедрять текстовые команды.
В конце концов, отдел безопасности Google пришёл к выводу, что пользовательский контент нужно в обязательном порядке хранить на отдельном изолированном домене, в Google это обычно *.googleusercontent.com. В этой «песочнице» файлы практически не представляют опасности для веб-приложения, и аутентификационные куки google.com тоже в безопасности.
С непубличными пользовательскими документами ситуация сложнее. В веб-приложениях Google использует три стратегии, в зависимости от уровня рисков:
- В ситуациях высокого риска (например, документы с высоким риском утечки URL в открытый доступ) Google может сочетать схему с использованием токенов в URL с кратковременными, уникальными для каждого документа куками, выданными для конкретного поддомена на googleusercontent.com. Этот механизм, известный внутри Google под названием FileComp, позволяет защититься от атак на самые критические приложения Google.
- В других ситуациях, когда риск меньше (встроенные изображения), можно ограничиться выдачей URL, привязанных к конкретному юзеру.
- В малорискованных ситуациях Google выдаёт глобально валидные, долгоживущие URL.
Исследования в области безопасности веб-браузеров продолжаются, и ситуация здесь быстро меняется. Михал Залевски говорит, что отдел безопасности Google отслеживает новости и быстро реагирует, в случае необходимости.
Подробнее: http://www.xakep.ru/post/59242/default.asp
Дайджест новых статей по интернет-маркетингу на ваш email
Новые статьи и публикации
- 2024-11-15 » Перенос сайта на WordPress с одного домена на другой
- 2024-11-08 » OSPanel 6: быстрый старт
- 2024-11-08 » Как установить PhpMyAdmin в Open Server Panel
- 2024-09-30 » Как быстро запустить Laravel на Windows
- 2024-09-25 » Next.js
- 2024-09-05 » OpenAI рассказал, как запретить ChatGPT использовать содержимое сайта для обучения
- 2024-08-28 » Чек-лист: как увеличить конверсию интернет-магазина на примере спортпита
- 2024-08-01 » WebSocket
- 2024-07-26 » Интеграция с Яндекс Еда
- 2024-07-26 » Интеграция с Эквайринг
- 2024-07-26 » Интеграция с СДЕК
- 2024-07-26 » Интеграция с Битрикс-24
- 2024-07-26 » Интеграция с Travelline
- 2024-07-26 » Интеграция с Iiko
- 2024-07-26 » Интеграция с Delivery Club
- 2024-07-26 » Интеграция с CRM
- 2024-07-26 » Интеграция с 1C-Бухгалтерия
- 2024-07-24 » Что такое сторителлинг: техники и примеры
- 2024-07-17 » Ошибка 404: что это такое и как ее использовать для бизнеса
- 2024-07-03 » Размещайте прайс-листы на FarPost.ru и продавайте товары быстро и выгодно
- 2024-07-01 » Профилирование кода в PHP
- 2024-06-28 » Изучаем ABC/XYZ-анализ: что это такое и какие решения с помощью него принимают
- 2024-06-17 » Зачем вам знать потребности клиента
- 2024-06-11 » Что нового в работе Яндекс Метрики: полный обзор обновления
- 2024-06-11 » Поведенческие факторы ранжирования в Яндексе
- 2024-06-11 » Скорость загрузки сайта: почему это важно и как влияет на ранжирование
- 2024-05-27 » Подборка сервисов для расшифровки аудио в текст
- 2024-05-27 » PostgreSQL 16. Изоляция транзакций. Часть 2
- 2024-05-06 » Как настраивать конверсионные стратегии: работа над ошибками
- 2024-04-22 » Комментирование кода и генерация документации в PHP
Кто мало хочет, тот дешево стоит |
Мы создаем сайты, которые работают! Профессионально обслуживаем и продвигаем их , а также по всей России и ближнему зарубежью с 2006 года!
Как мы работаем
Заявка
Позвоните или оставьте заявку на сайте.
Консультация
Обсуждаем что именно Вам нужно и помогаем определить как это лучше сделать!
Договор
Заключаем договор на оказание услуг, в котором прописаны условия и обязанности обеих сторон.
Выполнение работ
Непосредственно оказание требующихся услуг и работ по вашему заданию.
Поддержка
Сдача выполненых работ, последующие корректировки и поддержка при необходимости.