Мы решили повторить масштабную исследовательскую работу 2015 года и проанализировали безопасность веб-ресурсов ведущих банков мира. Онлайн-банкинг с тех пор стал не просто более распространённым, а даже повсеместным явлением. Действительно, это быстро и удобно, но насколько безопасно? Следуют ли банки best practices?
Как и в прошлый раз, в процессе исследования мы отправляли обычные HTTP- и DNS-запросы, не вмешиваясь в работу банков. То есть все данные собраны так, как это мог бы сделать обычный пользователь, посетив ресурс. Для анализа мы выбрали 200 российских и 400 зарубежных банков. Под катом выдержки из исследования. Полный текст можно найти на нашем сайте.
В этот раз мы расширили область исследования, добавив в скоуп онлайн-ресурсы зарубежных банков. Это позволяет сравнить отношение к веб-безопасности в России и в других странах мира.
Забегая вперёд, с сожалением констатируем: классические приёмы повышения уровня защищенности часто игнорируются банками, хотя не требуют глобальных финансовых и технических ресурсов. Упускать имеющиеся возможности — дело добровольное, но совершенно другое дело — использовать их неправильно. Например, в случае с Content Security Policy, настройки присутствуют у одной пятой всех рассмотренных ресурсов, и практически у каждого из них есть ошибки конфигурации. В рамках исследования мы постарались подробно рассмотреть, как работать с данным типом настроек правильно, и какие ошибки допускаются чаще всего.
Цель исследования
Главная цель исследования — оценить уровень безопасности публично доступных банковских ресурсов: официального сайта и ДБО, в соответствии с лучшими практиками по настройке веб-ресурсов. Мы выбрали ряд пунктов, соответствие которым можно проверить, исключая какой-либо технический ущерб и не вмешиваясь в работу банка. Важно отметить, что вся собранная нами информация находится в открытом доступе, а манипуляции с этими данными не требуют углубленных навыков: при желании к подобным результатам может прийти любой заинтересованный пользователь.
Объект исследования
Для тестирования мы взяли ТОП-200 банков России. С полным списком можно ознакомиться по ссылке: http://www.banki.ru/banks/ratings/ (актуальные данные на март 2019 г.).
Австрия
Беларусь
Бельгия
Болгария
Босния и Герцеговина
Бразилия
Великобритания
Венгрия
Германия
Дания
Израиль
Ирландия
Испания
Италия
Канада
Китай
Лихтенштейн
Люксембург
Мальта
Нидерланды
Норвегия
ОАЭ
Польша
Португалия
США
Финляндия
Франция
Швейцария
Швеция
Япония
Первым шагом мы определили все официальные сайты и интернет-ресурсы ДБО для физических и юридических лиц. Затем для каждого банка осуществили проверки несколькими стандартными запросами по протоколам HTTP/HTTPS/DNS, схожими с обычными запросами от клиентов банка. Список с разбивкой по группам:
- Настройки SSL — дают возможность реализовать одну из многих атак, связанных с SSL;
- Настройки 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-политикой, можно выделить следующие категории:
- Некорректная конфигурация
- Пропущенные директивы (script-src|object-src|default-src|base-uri)
- Избыточные опции (unsafe-inline|unsafe-eval|https: | data: | * )
- Слабости хостов и «белого списка»
- Возможность загрузки произвольных JS-файлов
- Функции обратного вызова (“callbacks”)
- Скрипт-гаджеты в Angular и подобных шаблонизаторах
- Атаки без применения 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). Польза от применения таких технологий видна не сразу, а может и вовсе быть неявной: столкнувшись с ними, злоумышленник не сможет осуществить атаку, и его действия останутся вне поля зрения тех, кто отвечает за безопасность.
Рассмотрев веб-ресурсы российских банков с разных сторон, мы выяснили, что достаточно известные уязвимости и проблемы безопасности до сих пор присутствуют в них. Это позволяет злоумышленникам рассчитывать на успешную реализацию атак на данные финансовые организации. И чем больше проблем, тем выше финансовые и репутационные риски банков.
Ситуация в мире в целом не особо отличается. Среди явно отстающих в плане безопасности можно выделить банковские онлайн-ресурсы следующих стран: Китай, Япония, Бразилия, Израиль, Испания. Как ни парадоксально, в большинстве случаев зарубежные банки уделяют больше внимания безопасности основных страниц, нежели ДБО. Стоит отметить, что доля анализа зарубежных банков в исследовании является не столь обширной и носит, скорее, ознакомительный характер.
