Мы решили повторить масштабную исследовательскую работу 2015 года и проанализировали безопасность веб-ресурсов ведущих банков мира. Онлайн-банкинг с тех пор стал не просто более распространённым, а даже повсеместным явлением. Действительно, это быстро и удобно, но насколько безопасно? Следуют ли банки best practices?



Как и в прошлый раз, в процессе исследования мы отправляли обычные HTTP- и DNS-запросы, не вмешиваясь в работу банков. То есть все данные собраны так, как это мог бы сделать обычный пользователь, посетив ресурс. Для анализа мы выбрали 200 российских и 400 зарубежных банков. Под катом выдержки из исследования. Полный текст можно найти на нашем сайте.


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


Забегая вперёд, с сожалением констатируем: классические приёмы повышения уровня защищенности часто игнорируются банками, хотя не требуют глобальных финансовых и технических ресурсов. Упускать имеющиеся возможности — дело добровольное, но совершенно другое дело — использовать их неправильно. Например, в случае с Content Security Policy, настройки присутствуют у одной пятой всех рассмотренных ресурсов, и практически у каждого из них есть ошибки конфигурации. В рамках исследования мы постарались подробно рассмотреть, как работать с данным типом настроек правильно, и какие ошибки допускаются чаще всего.


Цель исследования


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


Объект исследования


Для тестирования мы взяли ТОП-200 банков России. С полным списком можно ознакомиться по ссылке: http://www.banki.ru/banks/ratings/ (актуальные данные на март 2019 г.).


Также мы выбрали по 20 банков из еще 30 стран (список)

Австрия
Беларусь
Бельгия
Болгария
Босния и Герцеговина
Бразилия
Великобритания
Венгрия
Германия
Дания
Израиль
Ирландия
Испания
Италия
Канада
Китай
Лихтенштейн
Люксембург
Мальта
Нидерланды
Норвегия
ОАЭ
Польша
Португалия
США
Финляндия
Франция
Швейцария
Швеция
Япония


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


  1. Настройки SSL — дают возможность реализовать одну из многих атак, связанных с SSL;
  2. Настройки DNS — позволяют получить информацию о поддоменах компании.

Далее приводим описание и результаты некоторых проверок. Особое внимание обратим на раздел, посвященный Content Security Policy: в нём мы постарались выделить основные ошибки и рассказать, как их можно избежать. Полное описание и результаты всех проверок — в исследовании.


Тестирование


SSL/TLS


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


Название проверки Краткое описание
Рейтинг Общий рейтинг настройки SSL, согласно ресурсу Qualys SSL Labs. Зависит от многих факторов, среди них: корректность сертификата, настройки сервера и алгоритмов, которые поддерживает сервер. Градация от F до A+.
Поддержка слабых ключей DH Для обмена ключами Диффи — Хеллмана могут быть использованы слабые параметры, что снижает безопасность ресурса.
Уязвимость POODLE Позволяет расшифровать данные пользователя. За более подробной информацией можно обратиться к публикации исследователей.
Уязвимость FREAK Заключается в том, что злоумышленник может заставить пользователя и сервер при установлении соединения и обмене данными применять “экспортные” ключи, длина которых сильно ограничена.
Подверженность атаке Logjam Так же, как и FREAK, Logjam основана на понижении уровня шифрования до “экспортного” уровня, где длина ключа составляет 512 бит. Отличие состоит в том, что Logjam атакует алгоритм Диффи — Хеллмана.
Уязвимость DROWN Позволяет дешифровать TLS-трафик клиента, если на серверной стороне не отключена поддержка протокола SSL 2.0 во всех серверах, оперирующих одним и тем же приватным ключом.
Уязвимость ROBOT Полностью нарушает конфиденциальность TLS при использовании RSA.
Уязвимость Beast Злоумышленник может расшифровать данные, которыми обмениваются две стороны, использующие TLS 1.0, SSL 3.0 и ниже.
Уязвимость CVE-2016-2107 Удаленный злоумышленник может использовать эту уязвимость для извлечения текста из зашифрованных пакетов, используя сервер TLS/SSL или DTLS в качестве padding oracle.
Уязвимость Heartbleed Получение доступа к данным, которые находятся в памяти клиента или сервера.
Уязвимость Ticketbleed Удаленный атакующий может эксплуатировать уязвимость с целью извлечения сессионных ID SSL, возможно извлечение других данных из неинициализированных областей памяти.
SSL Renegotiation Без безопасного пересогласования SSL риск DoS- или MITM-атаки будет увеличен.
Поддержка RC4 Обнаружена возможность за короткое время расшифровать данные, которые были скрыты при помощи шифра RC4.
Поддержка Forward Secrecy Это свойство определенных протоколов согласования ключей, которое дает гарантии того, что сеансовые ключи не будут скомпрометированы, даже если скомпрометирован закрытый ключ сервера.
Версия TLS Протокол TLS шифрует интернет-трафик всех видов, тем самым делая безопасным общение в интернете. Однако более ранние версии TLS 1.0 и 1.1 опираются на ненадежные алгоритмы хеширования MD5 и SHA-1 и рекомендуются к отключению
Поддержка SSL 2.0 и SSL 3.0 Оба протокола считаются устаревшими и имеют множество уязвимостей, поэтому рекомендуются к отключению на стороне сервера.
Поддержка NPN и ALPN Позволяет указать, какой протокол использовать после установления безопасного соединения SSL/TLS между клиентом и сервером.

Рейтинг


SSL/TLS имеет большое количество настроек и особенностей, которые в той или иной степени влияют на безопасность как самого соединения, так и его участников в целом. Чтобы провести общую оценку данной настройки, мы использовали функционал, предоставляемый Qualys (www.ssllabs.com). Он позволяет на основе многочисленных параметров создать общий рейтинг от A до F, где “A+” – это лучший результат, который может быть достигнут с точки зрения защищенности. Очень немногие компании, даже крупнейшие интернет-корпорации, имеют его. Соответственно, “F” – наихудший результат. Его можно получить, если сервер подвержен какой-либо критичной уязвимости, поддерживает устаревшие протоколы и обладает иными проблемами. Как и оценка “А+”, наихудший результат встречается редко, и, в основном, связан с непрофессионализмом персонала.


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


HTTP-заголовки


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


Заголовок Описание
Content-Security-Policy Позволяет явно задавать, откуда может быть подгружен тот или иной контент.
X-XSS-Protection Особенность браузеров Internet Explorer, Chrome и Safari, которая останавливает загрузку страниц при обнаружении XSS-атаки.
X-Frame-Options Разрешает или запрещает показ сайта во фрейме (iframe).
X-Content-Type-Options Данный заголовок сообщит IE/Chrome, что нет необходимости автоматически определять Content-Type, а необходимо использовать уже отданный Content-Type.
Strict-Transport-Security Позволяет предотвратить установки незащищенного HTTP-соединения на определенное время.
Set-cookie Отсутствие флагов HttpOnly и Secure в заголовке HTTP-ответа позволит украсть или обработать сеанс веб-приложения и файлы cookie.
Referrer-Policy Позволяет сайту контролировать значение заголовка Referer для ссылок, ведущих с вашей страницы.
Feature-Policy Позволяет управлять различными функциями браузера на странице.
Public-Key-Pins Позволяет уменьшить риск MITM-атаки с поддельными сертификатами.
Expect-CT Позволяет обеспечить соблюдение требований прозрачности сертификатов, что предотвращает незаметное использование неподтвержденных сертификатов для данного сайта.
X-Powered-CMS Указывает используемый CMS-движок.
X-Powered-By Указывает платформу приложений, на которой работает сервер.
Server header Указывает серверное ПО (apache, nginx, IIS или др.).

Если первые десять заголовков имеют “положительный” характер, и их желательно (правильно!) использовать, то последние три “сообщают” злоумышленнику о том, какие технологии применяются. Естественно, от подобных заголовков следует отказаться.


Рейтинг


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


Заголовок Условие настройки Баллы, если удовлетворяет условию Баллы, если не удовлетворяет условию
X-XSS-Protection присутствует, не 0 +1 -1
X-Frame-Options присутствует +1 -1
X-Content-Type-Options присутствует +1 -1
X-Content-Security-Policy / Content-Security-Policy присутствует хотя бы один +1 -1
Strict-Transport-Security присутствует и не пустой +1 -1
Server не содержит в себе версию сервера +1 -1
Set-cookie наличие флагов Secure и httponly +1 за наличие каждого 0
Referrer-Policy присутствует, >0 +1 0
Feature-Policy присутствует +1 0
Public-Key-Pins присутствует +1 0
Expect-CT присутствует +1 0
X-Powered-CMS отсутствует +1 -1
X-Powered-By отсутствует +1 -1

Рейтинг от “D” до “A+”, где “A+” – это лучший результат, который может быть достигнут с точки зрения защищенности. Наихудший результат встречался довольно редко, впрочем, как и наилучший.


Распределение рейтинга


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


Content Security Policy


“Политика защиты контента” или CSP – это один из основных способов уменьшения рисков, возникающих при эксплуатации XSS-атак. Данный инструмент позволяет администратору сайта определить, какие веб-ресурсы разрешены к использованию на страницах — шрифты, стили, изображения, JS-скрипты, SWF и так далее. Узнать, какие браузеры поддерживают CSP, можно здесь.


Благодаря CSP можно как полностью запретить браузеру подгружать, например, флэш-объекты, так и отрегулировать белый список доменов — в таком случае браузер отобразит лишь те SWF, которые размещены на разрешенном домене. Еще одно преимущество, которое предоставляет политика CSP – возможность оперативно узнавать о появлении новых XSS на просторах контролируемого ресурса. За счет применения опции “report-uri”, браузер злоумышленника или пользователя-жертвы отправляет отчет на указанный URL, как только срабатывает CSP.


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


  1. Некорректная конфигурация
    • Пропущенные директивы (script-src|object-src|default-src|base-uri)
    • Избыточные опции (unsafe-inline|unsafe-eval|https: | data: | * )
  2. Слабости хостов и «белого списка»
    • Возможность загрузки произвольных JS-файлов
    • Функции обратного вызова (“callbacks”)
    • Скрипт-гаджеты в Angular и подобных шаблонизаторах
  3. Атаки без применения JS (“scriptless”)
    • Утечка информации через незакрытые теги
    • Внедрение фишинговых форм

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


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


Strict-Transport-Security


Политика безопасности HSTS (HTTP Strict Transport Security) позволяет установить безопасное соединение вместо использования протокола HTTP. Для этого используется заголовок Strict-Transport-Security, который заставляет браузер принудительно использовать протокол HTTPS. Это позволяет предотвратить часть MITM-атак, в частности, атаку с понижением степени защиты и кражу cookies. Принцип механизма в заключается в следующем: при первом посещении сайта по протоколу HTTP(S) браузер получает заголовок Strict-Transport-Security и запоминает, что при дальнейших попытках подключения к этому сайту, нужно использовать только HTTPS.
Это позволит предотвратить сценарий, когда злоумышленник, перехватывая HTTP-запросы, перенаправляет пользователя на страницу-клон, чтобы заполучить его данные.


Процент банков, использующих HTTP-заголовок Strict-Transport-Security



Получив HTTP-запрос, сервер может отправить вместе с ответом заголовок Set-Cookie.
Cookie с флагом Secure отсылаются на сервер, только если запрос выполняется по протоколам SSL и HTTPS. Тем не менее, важные данные никогда не следует передавать или хранить в cookie, поскольку их механизм весьма уязвим, а флаг Secure не обеспечивает дополнительного шифрования или средств защиты. Cookie с флагом HTTPonly недоступны из JavaScript через свойства Document.cookie API, что помогает избежать кражи cookie у клиента в случае XSS-атаки. Следует устанавливать этот флаг для тех cookie, к которым не нужно обращаться через JavaScript. В частности, если cookie используются только для поддержки сеанса, то в JavaScript они не нужны и можно использовать флаг HTTPOnly. Без флагов HTTPOnly и Secure в заголовке HTTP-ответа можно украсть или обработать сеанс веб-приложения и файлы cookie.


Флаги Secure и HTTPonly в данном заголовке встречаются не чаще, чем на каждом втором официальном сайте банка в Боснии и Герцеговине, Японии, Китае, Бразилии, Болгарии, Люксембурге, Финляндии, Израиле, Франции, Великобритании и Испании.
Среди ДБО для физ. лиц – Китай, Ирландия, Израиль и Япония.
Среди ДБО для юр. лиц – Босния и Герцеговина, Бразилия и Китай.


Среди российских банков статистика следующая:
Официальный сайт банка — 42%;
ДБО для физ. лиц — 37%;
ДБО для юр. лиц — 67%.


Server header


Данный заголовок сообщает, на каком ПО работает веб-сервер, и может иметь следующее значение, например:


Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 
OpenSSL/1.0.1l 

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

Как показало исследование, 64% сайтов банков сообщают версию сервера, в то время как 24% этих серверов уязвимы.


Заключение


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


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


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


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

Комментарии (5)


  1. suffix_ixbt
    12.11.2019 20:51

    Зачем использовать рейтинг SSL Labs? Он так скажем для "обычных" сайтов.
    Банковский сайт должен соотвтствовать PCI DSS, HIPAA и NIST.
    Поэтому для данного исследования лучше бы вместо SSL Labs ориентироваться на www.immuniweb.com/ssl/ .


  1. squir
    12.11.2019 20:51
    +1

    Спасибо! Думаю не только банкам будет полезно провериться на эти элементарные уязвимости.


  1. qonqunano
    13.11.2019 10:48

    Ребят, анализ SSL и хидеров очень сложно закатать под исследование.
    Простите, но DSec уже не тот, хоть бы про XSS написали…


    1. pusa Автор
      13.11.2019 17:24

      т.к. поиск xss — инвазивное действие, а нам не хотелось вмешиваться в работу банков, его здесь и нет


  1. senator9991
    13.11.2019 10:49

    А что страна такая Белоруссия?