Лидеры форума

у исследования про insecurity iceberg два серьезных недостатка, с точки зрения репрезентативности и информативности: исключительная теоретичность (отсутствие собственно тестов) и сырые данные (отсутствие каких-либо понятных выводов по результатам). поэтому он и "ни о чем". тест не будет ни о чем, если четко продумать, что именно мы хотим тестировать и подобрать соответствующие критерии. так как проблема данной темы тестирования только в огромном количестве критериев и в их сложной взаимной пересекаемости. как следствие, задача продумать методологию действительно непростая. но вполне конечная, если не хвататься за все критерии одновременно и не сваливать их в кучу. вследствие этого, задачи при составлении методологии: 1. выделить несколько векторов тестирования и аккуратно разложить по ним все многочисленные критерии. 2. обеспечить системность. Что касается системности, можно сделать тест из трех частей. 1. теоретическая 2. синтетическая 3. полевая х. анализ 1. Теоретическая часть - чистый анализ статистики по уязвимостям для веб-браузеров. Собрать статистику часто используемых браузеров - по UserAgent из веб-логов сайтов по всему миру. Думаю, не будет нарушением каких-либо законов мира и справедливости взять эту статистику из приведенного john'ом исследования с указанием первоисточника, но лучше собрать самим. Собрать статистику обнаружения уязвимостей для этих браузеров, перемножить с критичностью этих уязвимостей. Собрать статистику по скорости реакции браузер-вендоров на уязвимости и по частоте обновлений. Из всего этого можно будет вывести множество полезных коэффициентов, например "наибольшой тормоз в плане обновлений", "степень уязвимости к 0day эксплойтам" (об этом см. в конце) и т.д. 2. Синтетическая часть - искусственное воспроизведение эксплуатации, исходя из анализа ситуации. Собрать статистику по веб-уязвимостям (можно запросить у АВ вендоров - любой "рука-на-пульсе" вирусный аналитик легко раскидает актуальные уязвимости по процентам) Собрать коллекцию эксплойтов (как-то провесить по частоте встречаемости) И прогнать эксплойты по браузерам. Критерий успешной эксплуатации - запущенный код. 3. Полевая часть даем Сергею Ильину IE, засекаем час и отправляем активно гулять по порно-сайтам. Тут думаю идея ясна - воспроизвести реальную ситуацию "наиболее вероятной эксплуатации" - что соответствует прогулке по сайтам dirty тематики (хак, крак, адалт, дорвеи). Можно еще нагуглить актуальных уязвимостей, которые инжектируются в "нормальные" сайты через ворованные фтп-пароли и погулять по этим сайтам тоже. х. Анализ Математическая работа по сопоставлению данных пп.1-3 в сочетании с гуманитарной работой по их сведению к каким-либо человекочитаемым показателям без существенных информационных потерь. Этот пункт надо думать, когда согласованы предыдущие. *** Что касается такого показателя, как степень пропатченности браузера. Ну можно попробовать запросить у браузер-вендоров статистику по обновлениям. Но я считаю, что этим параметром можно пренебречь - так как мы тестируем не степень легкомыслия пользователей, насколько часто они обновляются, а степень безопасности браузеров. Чтобы результатом теста безопасности браузеров можно было воспользоваться практически, тестируемые браузеры должны находиться в легко воспроизводимых состояниях. Единственное легко и вполне естественно воспроизводимое состояние для браузера, это 100% патчей. То же самое относится к вопросу о разных наборах плагинов для мозиллы. То, что у всех разные наборы плагинов - и есть причина того, что этим показателем можно пренебречь: вследствие своей непрозрачности, он представляет лишь миноритарную угрозу. Хотя можно взять Н самых популярных плагинов, такого порядка, как вьюеры документов и средства интеграции с другим популярным софтом. *** Очень важный и сложно формализуемый показатель, это степень уязвимости браузера к 0day эксплойтам. Проблема с ним в том, что ситуация 0day эксплуатации невоспроизводима. Поэтому практический тест не возможен, возможно только как-то аппроксимировать показатель "степень 0day уязвимости" из статистики прошлого. Например, так: взять плотность уязвимостей для данного браузера (количество/критичность на единицу времени), и поделить на обновляемость данного браузера (скорость/качество закрытия уязвимостей). Получится некий коэффициент, косвенно отражающий минимальный период времени, в течение которого браузер уязвим для свежих 0day. А если этот коэффициент еще скрестить с статистикой по браузерам, то получится некий показатель "глобальной веб-уязвимости". *** Также следует отдельно рассмотреть ситуации, когда эксплуатация происходит через веб, но виновник - не браузер. Примеры - кроссбраузерные плагины (flash, очень актуально) и уязвимости операционной системы (эксплуатация через картинки и курсоры). Это к теоретической части. *** Это то что совсем очевидно; думаю, можно еще много чего придумать интересного и показательного для теста.