Михал Залевски (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 отслеживает новости и быстро реагирует, в случае необходимости.
