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

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

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

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

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

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

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

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

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

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

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

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

SSL/TLS

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

Рейтинг

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

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

HTTP-заголовки

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

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

Рейтинг

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

Рейтинг от “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

Set-cookie

Получив 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). Польза от применения таких технологий видна не сразу, а может и вовсе быть неявной: столкнувшись с ними, злоумышленник не сможет осуществить атаку, и его действия останутся вне поля зрения тех, кто отвечает за безопасность.

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