В связи с разработкой Internet Explorer 8 наша команда разработчиков, занимающихся вопросами безопасности, проанализировала распространенные сегодня виды атак и общие тенденции, указывающие направление, в котором в будущем будут развиваться атаки. Конечно же, на протяжении всего периода разработки IE8 мы также тесно работали с представителями секьюрити-сообществ, чтобы всегда оставаться в курсе последних новостей о новых классах компьютерных угроз.
На сегодняшний день одной из наиболее интересных уязвимостей веб-приложений является Cross Site Request Forgery (CSRF). Исследователь по вопросам безопасности ИеримияГроссман (Jeremiah Grossman) называет CSRF "спящим гигантом" среди веб-уязвимостей. Как он отмечает, CSRF-атаки очень сложно предотвратить, поскольку обнаружить их очень и очень непросто. Основы архитектуры модели безопасности браузера разработаны таким образом, чтобы учесть одновременную работу с множеством сайтов и плавные переходы между несвязанными друг с другом сайтами, но именно с этими возможностями как раз и связаны CSRF-атаки. Учитывая то, что сегодня наблюдается активный процесс передачи личных данных и другой важной информации от компьютеров пользователей к популярным веб-приложениям, интерес к CSRF и другим уязвимостям веб-приложений будет только расти.
Во время разработки IE8 мы должны были быть очень осторожными, что не увеличивать поверхность для CSRF-атак на наш браузер. Новый объект IE8 XDomainRequest, например, позволяет производить коммуникацию различных доменов после получения явного разрешения от сервера, но при этом содержит определенных ограничения, которые гарантируют невозможность появления новых типов CSRF-атак. Конечные пользователи могут уменьшить опасность CSRF-атак, для чего они могут выходить из-под своего логина на чувствительных к данным видам атак сайтах, когда они ими не используются, или же пользуясь режимом InPrivate Browsing (в данном режиме браузер начинает работу с чистыми cookie, так что кэшированные cookie не могут быть использованы в CSRF-атаках).
В конечном счете, чтобы полностью исключить возможность CSRF-атак, нужно, чтобы веб-приложения были встроенными. Грамотно спроектированные веб-приложения часто могут самостоятельно защитить себя путем использования маркеров вызова (от англ. challenge tokens) или других похожих стратегий, которые позволяют обнаруживать вредоносные запросы, непреднамеренно посланные атакованными пользователями. К сожалению, эти стратегии также подвержены уязвимостям. Главной из них является XSS (cross-site scripting). Если веб-приложение, имеющее token-защиту, содержит в себе XSS-уязвимость, это означает, маркер безопасности может быть украден, что в свою очередь позволяет провести CSRF-атаку. К счастью, Internet Explorer 8 включает в себя XSS Filter и несколько других особенностей, которые помогают предотвратить XSS-атаки, нацеленные на кражу маркеров вызова, блокирующих CSRF.
Прошлой осенью исследователи Роберт Хансен (Robert Hansen) и Иеримия Гроссман сделали доклад о втором векторе CSRF-атак, называемом ClickJacking. ClickJacking - это термин, который обозначает множество методов, которые могут быть использованы для того, чтобы обманом заставить пользователя сделать щелчок по затененному или скрытому веб-элементу, обычно приводящий к нежелательной транзакции. Успешная ClickJacking-атака способна обойти CSRF-защиту, которая пытается добиться подтверждения транзакции пользователем. К примеру, рассмотрим простой веб-магазин, который использует cookie для аутентификации и позволяет делать покупки одним щелчком мыши.
Вредоносный сайт из сети может создать страницу, которая вызывается атакованной страницей веб-магазина в IFRAME и закрывает большую часть этой страницы вводящим пользователей в заблуждение текстом и изображениями.
В этом случае пользователь может сделать клик на странице веб-магазина, и, если пользователь уже зашел в этот веб-магазин под своим логином, то может произойти нежелательная транзакция.
Очевидно, что это довольно примитивный пример ClickJacking-атаки, однако в сети существуют и более сложные ее версии.
Хотя уже были предложены различные способы предотвращения ClickJacking-атак, каждый из них несет с собой ряд изменений, которые могут сказаться на совместимости и удобстве работы пользователей или же потребовать внесения существенных изменений в существующие стандарты. В настоящее время самым простым и наиболее широко используемым механизмом для победы над ClickJacking-атаками является frame-busting - он просто препятствует созданию страниц, уязвимых для такого рода атак. К сожалению, типичные примеры механизмов frame-busting полагаются на скрипты, а это означает, что они могут быть взломаны.
Как было сообщено другим производителям браузеров в начале декабря, в Internet Explorer 8 Release Candidate был представлен новый встроенный механизм, который позволяет веб-приложениям уменьшить риск ClickJacking-атак для уязвимых страниц путем вывода сообщения, что эти страницы не могут быть созданы.
Веб-разработчики могут посылать с HTML-страницами response-заголовок, называемый X-FRAME-OPTIONS, которые ограничивает набор способов, которыми может быть создана страница. Если X-FRAME-OPTIONS содержит маркер DENY, IE8 будет препятствовать визуализации страницы, если она будет содержаться в пределах фрейма. Если он содержит маркер SAMEORIGIN, IE будет блокировать визуализацию только если точка отсчета координат для просматриваемого содержимого страницы верхнего уровня будет отличаться от точки отсчета контента, прописанной в директиве X-FRAME-OPTIONS. Например, если http://shop.example.com/confirm.asp содержит директиву DENY, то эта страница не будет визуализироваться в подфрейме, независимо от того, где расположен родительский фрейм. Напротив, если директива X-FRAME-OPTIONS содержит маркер SAMEORIGIN, эта страница может содержаться в фрейме любой страницы с такой же как и у http://shop.example.com точкой отсчета координат.
Когда визуализация заблокирована политикой X-FRAME-OPTIONS, локальная страница с сообщением об ошибке содержит объяснения ограничения и ссылку, которая открывает фрейм в новом окне. Когда он открывается в новом окне, а не в подфрейме, контент, содержащийся на нем больше не является предметом ClickJacking-атак.
Используя директиву X-FRAME-OPTIONS, веб-разработчики могут напрямую уменьшить вероятность атак на веб-приложения для пользователей IE8. Я надеюсь, что директива X-FRAME-OPTIONS будет использоваться другими браузерами в качестве легкого в развертывании, обладающего высокой степенью совместимости средства для уменьшения угрозы ClickJacking-атак. В дальнейшей перспективе я надеюсь, что исследователи по вопросам безопасности продолжат вносить инновационные изменения в механизм политик безопасности веб-приложений, организованный средствами браузера. Мы рассчитываем на их совместную работу с нами в этой области и над последующим улучшением защиты от ClickJacking-атак в будущих версиях браузера.