Московский государственный университет имени М.В. Ломоносова

Факультет вычислительной математики и кибернетики

Кафедра информационной безопасности

Магистерская программа

"Математическое и программное обеспечение защиты информации"

Магистерская диссертация

Методы обеспечения безопасности

использования веб-приложений

Работу выполнил:

Студент вечерней формы обучения Григорьев Михаил Юрьевич Научный руководитель:

Доцент, к.ф.-м.н. Применко Эдуард Андреевич Москва 2013

ОГЛАВЛЕНИЕ

1. АННОТАЦИЯ

2. ВСТУПЛЕНИЕ

3. ЦЕЛЬ И ЗАДАЧИ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ

4. ЗАЩИТА СЕРВЕРНОЙ СТОРОНЫ

4.1 Международный опыт создания безопасных веб-приложений

4.2 Сравнение OWASP Top 10 2010 и 2013

4.3 Методы защиты серверной стороны

5. ЗАЩИТА КАНАЛА МЕЖДУ СЕРВЕРНОЙ И КЛИЕНТСКОЙ СТОРОНАМИ.............

6. ИСПОЛЬЗОВАНИЕ БАЙЕСОВСКОЙ СЕТИ ДЛЯ ЗАЩИТЫ КЛИЕНТСКОЙ

СТОРОНЫ ОТ ФИШИНГА

6.1 Существующие методы защиты

6.2 Общая информация о байесовских сетях

6.3 Байесовская сеть для защиты от фишинга

6.4 Алгоритм использования

6.5 Варианты программной реализации

6.6 Производительность

6.7 Преимущества и недостатки модели

7. ЗАКЛЮЧЕНИЕ

8. СПИСОК ЛИТЕРАТУРЫ

1. АННОТАЦИЯ В данной магистерской диссертации автором предложены методы, которые позволят обеспечить безопасность веб-приложений. Рассматривается безопасность не только серверной стороны с точки зрения разработчика веб-приложения, но и безопасность клиентской стороны с точки зрения пользователя, которой обычно не уделяется достаточно внимания. Разработаны метод определения атаки типа фишинг, который позволит снизить влияние человеческого фактора на безопасность пользователя при работе с веб-приложениями в глобальной сети Интернет, и математическая модель на основе байесовской сети для защиты пользователей веб-приложений от фишинга.

Таблицы условных вероятностей созданной модели вычислены на основе анализа актуальных статистических отчетов о фишинге за 2013 год.

2. ВВЕДЕНИЕ Разнообразные информационные системы с каждым днем играют всё большую роль в жизни человека. Банковские, медицинские, корпоративные, государственные – все они уже широко используются во всем мире, включая Российскую Федерацию. И основной формой доступа к этим информационным системам является веб-приложение, позволяющее пользователю получить доступ к конфиденциальным данным, используя всего лишь веб-браузер.

Хорошим примером веб-приложений являются системы дистанционного банковского обслуживания (интернет-банкинг) или Единый портал государственных услуг Российской Федерации [1]. Ясно, что доступ к этим веб-приложениям должен быть максимально безопасен: никто, кроме самого пользователя, не должен иметь возможности прочитать, изменить данные пользователя или же совершить действие в приложении от имени пользователя. Причем, утечка данных о банковских транзакциях человека или даже потеря небольшой суммы со счета – это не самое страшное, что может случиться: ЕПГУ позволяет гражданину совершать большое количество юридически значимых операций, например, жениться.

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

3. ЦЕЛЬ И ЗАДАЧИ МАГИСТЕРСКОЙ ДИССЕРТАЦИИ

В процессе обеспечения безопасности веб-приложений задействованы разработчики веб-приложений, специалисты по их развертыванию и интеграции, а также лица, ответственные за безопасность рабочих и личных компьютеров – основного средства доступа к веб-приложениям. Нельзя ограничиваться одной или несколькими из перечисленных областями для защиты, необходимо уделять внимание всей инфраструктуре веб-приложений. И если многие проблемы безопасности серверной стороны уже давно известны и имеют решение, то о клиентской стороне часто забывают.

Цель данной работы – провести анализ способов обеспечения комплексной безопасности веб-приложений и исследовать проблемы защиты клиентской стороны вебприложения.

Для достижения поставленной цели необходимо решить следующие задачи:

1. Рассмотреть ключевые проблемы безопасности серверной стороны вебприложений и привести методы решения этих проблем;

2. Проанализировать актуальное состояние использования протоколов безопасности транспортного уровня (SSL/TLS) связи между серверной и клиентской сторонами;

3. Разработать метод защиты пользователей веб-приложений от фишинга – ключевой угрозы клиентской стороне.

4. ЗАЩИТА СЕРВЕРНОЙ СТОРОНЫ

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

Как показывает практика, традиционных методов защиты, например, использование шифрованного соединения или «сложного» пароля для аутентификации, часто бывает недостаточно. Существует большое количество типов атак, различающихся по распространенности, опасности для атакуемой системы, сложности проведения атаки и т.п. Создавая веб-приложение, нельзя не учитывать наиболее распространенные атаки.

Основные проблемы безопасности серверной стороны веб-приложений известны, известны и соответствующие способы защиты. Однако атаки злоумышленников постоянно эволюционируют, требуются новые методы защиты от них. Найти компромисс между защищенностью и удобством использования позволяют специальные проекты, посвященные безопасности веб-приложений.

Одним из подобных проектов является OWASP – Open Web Application Security Project [2]. OWASP – это не столько актуальный список наиболее популярных атак и методов борьбы с ними, сколько руководство по обеспечению информационной безопасности на всех этапах жизненного цикла программного обеспечения. Основная цель OWASP — передать разработчикам, архитекторам ПО, менеджерам проектов и даже целым организациям знания о наиболее важных уязвимых местах в безопасности вебприложений. Разработчики могут учиться на чужих ошибках, руководители — использовать полученные данные для управлением затратами и рисками, связанными с применением защищаемого программного обеспечения в бизнесе.

OWASP Top 10 [3] — это подборка десяти наиболее распространенных уязвимостей, вызванных ошибками, допускаемыми программистами и используемыми злоумышленниками, а также описание способов защиты. В начале текущего 2013 года была выпущена новая версия этого рейтинга. Ниже приводится сравнительный анализ свежей версии с предыдущим вариантом, датируемым 2010 годом.

В следующей таблице приводятся оба рейтинга OWASP Top 10:

1. Инъекция программного кода (Injection) 1. Инъекция программного кода (Injection) 2. Межсайтовый скриптинг (Cross Site 2. Межсайтовый скриптинг (Cross Site 3. Ошибки при аутентификации и 3. Ошибки при аутентификации и управлении сессиями (Broken Authentication управлении сессиями (Broken Authentication 4. Небезопасные прямые ссылки на объекты 4. Небезопасные прямые ссылки на объекты (Insecure Direct Object References) (Insecure Direct Object References) 5. Межсайтовая подделка запросов (Cross 5. Небезопасные настройки ПО (Security 6. Небезопасные настройки ПО (Security 6. Публикация конфиденциальной Misconfiguration) 7. Небезопасная криптография (Insecure 7. Отсутсвие контроля доступа на уровне Cryptographic Storage) 8. Отсутствие контроля за доступом к URL- 8. Межсайтовая подделка запросов (Cross адресам (Failure to Restrict URL Access) Site Request Forgery) 9. Недостаточная защита транспортного 9. Использование компонентов с уровня (Insufficient Transport Layer известными уязвимостями (Using Known 10. Непроверенные редирект и форвардинг 10. Непроверенные редирект и форвардинг (Unvalidated Redirects and Forwards) (Unvalidated Redirects and Forwards) Из сравнительной таблицы видно, что за прошедшие три года первые 4 главные проблемы безопасности остались неизменными. В свою очередь, Межсайтовая подделка запросов переместилась с 5 на 8 место, что говорит о росте качества программного обеспечения веб-серверов и веб-приложений.

В версии 2013 года на 6 месте появился пункт Публикация конфиденциальной информации, который вобрал в себя пункты 7 и 9 предыдущей версии: Небезопасная криптография и Недостаточная защита транспортного уровня соответственно.

Действительно, они оба похожи по смыслу, но различаются с технической стороны.

Небезопасная криптография – это использование устаревших криптографических алгоритмов, например, MD5, в веб-приложении. Недостаточная защита транспортного уровня значит отсутствие x509-сертификата у веб-сервера, то есть, протоколы SSL/TLS не используются. Пункт Публикация конфиденциальной информации собирает в себя обе проблемы, ведь в обоих случаях критическая информация защищена недостаточно – без разделения на этапы ее использования: хранение на сервере или передача по каналу связи.

Еще одно новшество рейтинга 2013 года – это девятый пункт Использование компонентов с известными уязвимостями. Многие администраторы серверов считают, что серверное программное обеспечения ни в коем случае нельзя обновлять. Такие администраторы руководствуются принципом «Работает – не трогай!», но такой подход крайне вреден для безопасности веб-приложений. В новых версиях программного обеспечения не только появляются новые функции, но и происходит исправление ошибок предыдущих версий. А при сохранении старых версий ПО, администраторы предоставляют злоумышленникам возможность эксплуатировать известные уязвимости в устаревших программах.

Подробный анализ рейтинга OWASP Top 10 лежит за пределами данной магистерской диссертации, но и приведенной информации достаточно, чтобы сформулировать несколько методов, следуя которым разработчики веб-приложений и специалисты, занимающиеся их развертыванием и интеграцией, смогут обеспечить безопасность своих веб-приложений.

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

Следующая по важности область веб-приложения – это механизмы управления учетными записями пользователей и контроля доступа к ресурсам. Проверку прав доступа к ресурсам следует проводить на уровне программных функций, запрашивающих ресурс для дальнейшей передачи пользователю. Не стоит полагаться только на глобальные переменные пользовательской сессии или cookie-файлы – контроль доступа должен осуществляться именно на уровне функций.

Специалистам по развертыванию и интеграции веб-приложений стоит обратить внимание на те настройки программного окружения веб-приложений (ОС, библиотеки, веб-сервер и др.), значения которых остаются без изменений. Если оставлять значение поумолчанию, то это может не только привести к прямой «дыре» в безопасности, но и даст злоумышленнику дополнительное знание о защищаемой системе. Имея доступ к аналогичному программному обеспечению, также с настройками по-умолчанию, злоумышленник может создать похожую модель атакуемого веб-приложения, благодаря чему легко найдет лазейку сквозь оборону.

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

5. ЗАЩИТА КАНАЛА МЕЖДУ СЕРВЕРНОЙ И

КЛИЕНТСКОЙ СТОРОНАМИ

Требование использования новых версий относится также и к протоколам, обеспечивающим безопасность соединения между серверной стороной и клиентским веббраузером. Стандарт на протокол TLSv1.2 был опубликован в далеком 2008 году [4], однако интернет-компании и разработчики веб-приложений массово начинают использовать его только сейчас. Это обусловлено двумя причинами:

Во-первых, поддержка TLSv1.2 в популярных браузерах появилась совсем недавно.

Версии, поддерживающие эту версию протокола, стали выходить осенью 2013 года:

• Internet Explorer с версии 8 для Win 7 – март 2009;

• Chrome с версии 29 – сентябрь 2013;

• Opera: с версии 10 (июнь 2009) по 12, 14-16 – нет (переход на Blink), с 17 версии– • Firefox с версии 27 – январь 2014;

• Safari с версии 7 – октябрь 2013.

Современные версии одноименных браузеров для мобильных устройств на базе ОС Android и iOS также поддерживают протокол TLSv1.2.

Во-вторых, в связи с участившимися публикациями в СМИ о тотальной слежке в Интернете различных государственных ведомств, пользователи веб-приложений стали больше интересоваться средствами защиты конфиденциальности своих данных. Чтобы не потерять клиентов, компаниям приходится переходить на использование современных средств защиты, таких как TLSv1.2. На текущий момент, версию 1.2 протокола TLS используют в своих веб-приложениях компании Google, Facebook, Сбербанк России и другие.

Достоинство протокола TLSv1.2 заключается в том, что помимо улучшений, затрудняющих выполнение атаки Человек посередине (Man in the middle - MITM), эта версия поддерживает новые криптографические алгоритмы и режимы их использования:

SHA-256, AES128-GCM, AES256-GCM, а также ряд криптографических алгоритмов на эллиптической кривой.

В заключение отметим, что не стоит делать протокол TLSv1.2 единственным доступным средством защиты, отбросив SSL 3.0, TLS версий 1.0 и 1.1, так как не все пользователи имеют современные версии веб-браузеров.

6. ИСПОЛЬЗОВАНИЕ БАЙЕСОВСКОЙ СЕТИ ДЛЯ ЗАЩИТЫ

КЛИЕНТСКОЙ СТОРОНЫ ОТ ФИШИНГА

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

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

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

Рассмотрим пример, когда при попытке зайти на веб-сайт браузер пользователя выдает сообщение об отрицательном результате проверки сертификата сайта (вебприложения). Обычно в таком случае пользователю рекомендуется просмотреть данные сертификата и самостоятельно принять решение, продолжать работу с таким вебприложением или нет. Действительно, отрицательный результат проверки сертификата может иметь несколько причин, как криминальных, так и вполне естественных.

Сертификат может быть легальным, но в браузере может отсутствовать информация об удостоверяющем центре, выдавшем рассматриваемый сертификат. Или данный сертификат является самоподписанным. Или же истек срок его действия, но администрация ресурса не успела его вовремя обновить. Иными словами, ничего страшного не происходит. Но могут быть и другие варианты: секретный ключ сертификата был скомпрометирован, а сам сертификат находится в списке отозванных сертификатов – злой умысел налицо.

Понять, как следует поступить в подобной ситуации, сможет только человек, разбирающийся в безопасности веб-приложений, однако таких людей крайне мало.

Обычно пользователь не обращает внимания на сообщения об ошибке и старается как можно быстрее продолжить работу, зачастую попадаясь в ловушку злоумышленника. Ни антивирус, ни файрвол не смогут защитить пользователя в этом случае, а современные браузеры не способны с достаточной точностью определить, как следует поступить пользователю.

Приведенный выше пример иллюстрирует так называемый фишинг – подмену вебприложения для получения от пользователя его персональных данных или корпоративной информации. Современные браузеры используют несколько типов защиты от фишинга:

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

Белые списки: открываемые адреса из белых списков считаются доверенными, остальные адреса затем проверяются с помощью черного списка.

И черные, и белые списки содержат огромное количество записей, что создает дополнительные проблемы, связанные в первую очередь с производительностью компьютеров пользователей. Действительно, нельзя просто так взять и загрузить на компьютер пользователя черный список целиком. Во-первых, он содержит огромное количество записей и его скачивание сильно нагрузит интернет-канал пользователя. Вовторых, списки регулярно обновляются – поддерживать актуальность списков на удаленных компьютерах крайне сложно. В-третьих, даже при наличии актуального черного списка на пользовательском компьютере, поиск в нем адреса займет недопустимо большое время.

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

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

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

Облачные технологии позволяют решить проблемы полноты и оперативности.

Актуальность же достигается за счет увеличения как человеческих, так и технических ресурсов для поддержки актуальности черных списков. Согласно исследованиям компании NSS Labs [5, 6], за прошедший год среднее время добавления новых фишинговых адресов в черные списки популярных браузеров уменьшилось с 27 часов до 2.5 часов.

Крупнейшей репутационной системой является Google Safe Browsing API [5]. Её черные списки используют браузеры Chrome, Safari и Firefox. По данным компании LiveInternet [7], суммарная доля их пользователей на ноябрь 2013 года в России составляет примерно 60% от всех пользователей веб-браузеров.

Использование верификации посещаемых веб-сайтов на основе черных и белых списков – это лучшее техническое средство для защиты от фишинга (в принципе лучшая защита от фишинга для пользователя – это собственная голова на плечах), однако и у этих списков есть ряд значительных недостатков:

Во-первых, проблема актуальности не решена до конца: 27 часов, 2 часа или даже 30 минут – это не режим реального времени.

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

В-третьих, проблема оперативности тоже никуда не делась: даже облачные сервера – не «резиновые», мгновенно обслужить всех желающих они не в состоянии. Да и лишний запрос для проверки адреса при каждом обращении к новому веб-ресурсу заметно для глаза пользователя замедляет открытие новых страниц в браузере.

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

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

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

Байесовская сеть (Bayesian network), также называемая байесовой сетью или байесовской сетью доверия, - это графическая вероятностная модель, состоящая из множества переменных и вероятностных зависимостей между ними.

Байесовские сети применяются для моделирования во многих областях:

Биоинформатика;

Медицина;

Обработка данных;

Машинное обучение;

Системы поддержки принятия решений;

Защита информации.

Основная задача, решаемая байесовскими сетями – это задача диагностики:

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

Формально, байесовская сеть – это направленный граф без циклов. Вершина A называется родителем вершины B, а B называется потомком A, если существует дуга, выходящая из A в B. Если из вершины A существует ориентированный путь в другую вершину B, то B называется потомком A, а A называется предком B. Множество вершинродителей вершины Vi обозначим как parents(Vi) = PAi.

Определение [8]:

Направленный ациклический граф G называется байесовской сетью для вероятностного распределения P(v), заданного над множеством случайных переменных V, если каждой вершине графа поставлена в соответствие случайная переменная из V, а дуги в графе удовлетворяют условию: любая переменная Vi из V должна быть условно независима от всех вершин, не являющихся ее потомками, если заданы все ее прямые родители PAi в графе G, то есть Vi V справедливо: P(vipai,s) = P(vipai), где vi — значение Vi; S — множество всех вершин, не являющихся потомками Vi; s — конфигурация S; pai — конфигурация PAi.

Полное совместное распределение значений в вершинах можно удобно записать в виде произведения локальных распределений:

Если у вершины Vi нет предков, то её локальное распределение вероятностей называют безусловным, иначе условным. Если вершина - случайная переменная получила означивание, то такое означивание называют свидетельством. Если значение переменной было установлено извне, а не наблюдалось, то такое означивание называется вмешательством или интервенцией.

Пример:

Для наглядности рассмотрим пример применения байесовской сети для решения задачи диагностирования. Допустим, есть две причины, по которым трава может стать мокрой: прошел дождь или сработала поливальная установка. Допустим, вероятность дождя зависит от погоды, а поливальная установка включается регулярно по заданному расписанию. Примем также условие, что поливальная установка не работает во время дождя. Пусть «трава мокрая», «прошел дождь» и «сработала поливальная установка» - это три булевые переменные, которые могут принимать значение «Истина» или «Ложь».

Также заданы условные вероятности для этих переменных. На основе этих данных можно построить следующую байесовскую сеть:

Сработала поливальная установка Прошел дождь поливальная Сработала поливальная Прошел дождь установка Имея приведенную байесовскую сеть, мы можем ответить на вопрос «Если трава мокрая, то с какой вероятность был дождь?».

, где R – вероятность события, что прошел дождя, G – трава мокрая, а S – события, что сработала поливальная установка. T означает истинность события, F – ложность события.

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

Байесовская сеть для защиты от фишинга должна содержать переменные, соответствующие проявлению ряда свойств веб-приложения, каждое из которых может изменить свое значение при очередном обращении к веб-приложению. Под очередным обращением к веб-приложению имеется ввиду отправка очередного HTTP-запроса на сервер, где располагается веб-приложение, в результате какого-либо действия пользователя: нажатие на кнопку или гиперссылку, ввод текста, загрузка файла и тому подобное.

Вопрос, на который должна ответить байесовская сеть – с какой вероятностью ресурс, на который попал пользователь, является поддельным (мошенническим).

Байесовская сеть работает тогда и только тогда, когда построенный граф соответствует реальности, а условные вероятности вершин графа вычислены из большой выборки исходных данных. Анализ ресурса Open Web Application Security Project (OWASP) и рейтинга OWASP Top 10, де-факто являющегося точнейшим отражением международного опыта исследования вопросов безопасности веб-приложений, позволил выделить следующие свойства веб-приложений для построения модели. Для каждого свойства представлено краткое обоснование его наличия в списке для контроля. Список линеен, хотя сами свойства обладают зависимостями, которые будут показаны непосредственно в графической модели.

1. Наличие предыдущих посещений ресурса (веб-приложения);

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

2. Проверка IP-адреса веб-приложения;

Смена IP-адреса веб-приложения – первый сигнал о возможной подмене ресурса, однако смена адреса может быть вызвана работой системы распределения нагрузок.

3. Географическое расположение IP-адреса (государство);

Если IP-адрес меняется на адрес из другой страны или региона, то вероятен фишинг из-за рубежа.

4. Проверка использование протокола SSL/TLS;

Наличие SSL/TLS-сертификата – это общепринятая административно-техническая мера, применяемая организациями вроде банков или государственных ведомств для защиты своих веб-приложений от фишинга.

5. Версия протокола;

Изменение версии протокола SSL/TLS происходит нечасто и обычно от старой к более новой версии.

6. Наличие HTTP Strict Transport Security (HSTS);

HSTS – это требование веб-сервера к клиентскому ПО не использовать незащищенное соединение, т.е. при обращении пользователя к адресу http://... происходит автоматическое перенаправление на адрес https://...

7. Самоподписанность сертификата;

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

8. Действительность сертификата;

Веб-приложение с недействительным сертификатом не должно работать.

Сертификат считается недействительным, если истек срок его действия или он находится в списке отозванных сертификатов.

9. Доверие к удостоверяющему центру сертификата;

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

10. Наличие сети взаимодоверяющих УЦ (Mutually Endorsing CA Infrastructure);

Удостоверяющий центр сам должен обладать действительным сертификатом.

Наличие информации о других УЦ, которые могут подтвердить этот факт – положительный признак.

11. Смена сертификата;

Смена сертификата обычно происходит после истечения срока действия или в случае компрометации секретного ключа сертификата. Если после смены сертификата предыдущий сертификат не отозван, то это подозрительно.

12. Срок действия сертификата;

Смена сертификата задолго до конца срока действия – негативный признак.

13. Смена УЦ;

Смена УЦ – необычное явление.

14. Смена страны регистрации УЦ;

Смена УЦ на УЦ из другой страны – еще более необычное явление.

15. Проверка похожих доменных имен;

Очень часто при фишинге доменное имя поддельного веб-приложения неточно совпадает с именем подделываемого приложения. В этом случае необходимо вычислить «коэффициент похожести» доменных имен. Для этого можно, например, вычислить расстояние Дамерау-Левенштейна, использовать алгоритм Ахо-Корасик или алгоритм Бойера-Мура-Хорспула. Договоримся, что похожим доменным именем будем считать строку с расстоянием Левенштейна [9] от заданной строки (доменного имени) больше или равным 0.8.

16. Смешанные символы в доменном имени;

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

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

Далее приводятся графическая модель и таблицы условных вероятностей ее элементов.

Совместную функцию вероятности можно записать в следующем виде:

P(V0, …, V17) = P(V0) * P(V1 | V0) * P(V2 | V0) * P(V3 | V0) * P(V4 | V0) * P(V5 | V1) * * P(V6 | V1, V15, V16) * P(V7 | V1, V2) * P(V8 | V1, V2) * P(V9 | V2) * P(V10 | V2) * * P(V11 | V5) * P(V12 | V6) * P(V13 | V7) * P(V14 | V9) * P(V15 | V9) * P(V16 | V9) * * P(V17 | V15, V16) Графическая модель сформирована. До завершения модели осталось привести (условные) вероятности. Как уже было указано выше, существуют два источника значений этих вероятностей:

1. Вычисления на основе естественной выборки данных очень большого объема;

2. Экспертная оценка.

В задачах информационной безопасности обычно не бывает крупных выборок, которые можно проанализировать. И даже экспертная оценка не всегда является точной даже без учета образованности эксперта: методы злоумышленников постоянно эволюционируют и преобразуются [10, 11], причем, для каждой страны по-разному.

V0 Подмена ресурса – пожалуй, самый важный параметр во всей модели. В данном случае будем подразумевать шанс пользователя при обращении к «важному» вебприложению попасть на подмененный ресурс. Будем рассматривать в качестве источника статистики цифры, относящиеся к Российской Федерации [12, 13]. Вероятность подмены ресурса вычислена на основе данных отчета о фишинговой активности за первую половину 2013 года. Берется доля уникальных фишинговых атак в общем количестве доменных имен в зонах.ru и.рф.

V1 Повторное посещение V1 Повторное посещение SSL/TLS V6 УЦ сменился Одно из решений проблемы неточности значений вероятностей – их уточнение во время использования байесовской сети. Аккумулируя пользовательские статистические данные, можно добиться высокой точности, а при наличии достаточного количества пользователей по всему миру можно решить и проблему территориальной распределенности. К тому же, обнаруживая фишинговые ресурсы, байесовская сеть может служить источником данных для традиционных черных списков и репутационных систем.

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

P(V0 | {Vi = Правда} ) = P({Vi = Правда}, V0 = Правда ) / P({Vi = Правда}) Механизм защиты от фишинга может действовать следующим образом:

1. При каждом обращении к какому-либо доменному имени необходимо проверить, присутствует ли указанное или похожее доменное имя в списке ресурсов, которые необходимо защищать. Договоримся, что похожим доменным именем будем считать строку с расстоянием Левенштейна от заданной строки (доменного имени) больше или равным 0.8.

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

3. Проверка начинается с получения от браузера текущего состояния вебприложения, то есть, получение значений его свойств, которые используются в байесовской сети.

4. Из состояния веб-приложения получается информация о том, какие из свойств наблюдаются, а какие – нет. На основе этих данных вычисляется вероятность P того, что рассматриваемое веб-приложение поддельное.

5. В зависимости от полученной величины, следует соответствующая реакция: