SEO и безопасность в интернете

Личный сайт Павла Медведева

Банки плохо защищают свои сайты, данные и платежи клиентов легко могут попасть к злоумышленникам

Банки плохо защищают свои сайты, данные и платежи клиентов легко могут попасть к злоумышленникам

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

Наибольший резонанс поднял вопрос утечек именно банковской информации, хотя там она по содержанию как раз не была так критична относительно других сайтов. Я показал лишь то что Сбербанк не защищает данные платежей клиентов компаний, которые пользуются его услугами, но критичная утечка на тот момент еще не успела произойти, это был лишь вопрос времени. Но к счастью, «дыру» оперативно исправили. (Правда на момент написания на некоторых других доменах Сбербанка, вижу, все еще отсутствуют файлы robots.txt)

Банки прокомментировали что никакой опасности в конкретной утечке не было (хотя это не так, о чем позже).

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

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

МДМ-Банк

Локо-Банк, пример личного кабинета для Юр. лиц

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

Методика получения информации

Взял сведения об адресах Web-сайтов кредитных организаций Российской Федерации по состоянию на 28.04.2018   с сайта ЦБ
http://www.cbr.ru/credit/CO_SitesFull.asp

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

 

51% Сайтов банков используют незащищенный протокол HTTP вместо HTTPS

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

Сейчас поступает много новостей об уязвимостях в протоколах шифрования, ключах HTTPS, SSL, нужно постоянно следить и поддерживать настройки сервера на должном уровне, но… более чем у половины банков вообще нет SSL сертификата, подтверждающего подлинность, сайты работают на HTTP и там вообще нет никакой защиты. Любой владелец WIFI-точки доступа или интернет-провайдер может с легкостью подменить любую информацию на сайте: номера телефонов, реквизиты и т.п.

Не удивительно, что интернет полон сообщений о опустошенных банковских счетах. Судя по подсказкам Яндекс/Google люди действительно испытывают проблемы с пропажей средств

Даже главная страница Сбербанка все еще работает на незащищенном HTTP.

Тут надо уточнить что имелись ввиду основные банковские сайты, а не системы банк-клиент или онлайн-банк (ниже я проведу анализ отдельно и у онлайн-банков). Но все равно, это полный провал и позорище. Защищенный протокол создавался как раз для безопасности конфиденциальных и личных данных в интернете, сохранности банковской тайны, тоесть кому если не банкам нужно было первыми перейти на него? Если брать e-Commerce в РФ, по опыту клиентов, думаю процентов 80 сайтов там уже работают на HTTPS, остальные собираются или в процессе. Получается у частных небольших компаний в этом плане дела лучше чем у банков.

Почему сайты в 2018 году должны использовать HTTPS:

  • Конфиденциальность
    В открытой среде, такой как Интернет, он защищает коммуникации между двумя сторонами. Например, в отсутствие HTTPS владелец точки доступа WiFi может видеть приватные данные, такие как кредитные карты, если пользователь этой точки доступа совершает покупки в онлайне.
  • Целостность
    Он гарантирует, что информация достигнет адресата в полном и нетронутом виде. Например, наш друг с точкой доступа WiFi может добавить дополнительную рекламу на наш сайт, снизить качество изображений для экономии трафика или изменить содержимое статей, которые мы читаем. HTTPS гарантирует, что веб-сайт не может быть изменён.
  • Подлинность
    Он гарантирует, что веб-сайт в реальности является тем, за кого себя выдаёт. Например, тот же самый владелец точки доступа WiFi мог бы отправлять браузеры на поддельный сайт. HTTPS гарантирует, что веб-сайт, который представляется как example.com, действительно является example.com. Некоторые сертификаты даже проверяют правовую идентичность владельца веб-сайта, так что вы знаете, что yourbank.com принадлежит YourBank, Inc.

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

Цитата из вики:

Совместное использование HTTP и HTTPS
Когда сайты используют смешанный функционал HTTP и HTTPS, это потенциально приводит к информационной угрозе для пользователя. Например, если основные страницы некоторого сайта загружаются, используя HTTPS, а CSS и JavaScript загружаются по HTTP, то злоумышленник в момент загрузки последних может подгрузить свой код и получить данные HTML-страницы. Многие сайты, несмотря на такие уязвимости, загружают контент через сторонние сервисы, которые не поддерживают HTTPS. Механизм HSTS позволяет предотвратить подобные уязвимости, заставляя принудительно использовать HTTPS соединение даже там, где по умолчанию используется HTTP. 

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

Еще пример со Сбербанка:

Обращение юр.лиц в службу Омбудсмена Сбербанка

Как видно из сообщения браузера — данные не защищены и могут перехватываться, подменяться злоумышленниками.
Еще примеры:

Мособлбанк — заявка на кредит для Юр.Лиц — соединение не защищено

 

Заявка на ипотеку

 

Банк — Возрождение, отправка персональных данных на незащищенной стороне сайта

 

Элитные клиенты, но обслуживание не совсем элитное — на SSL сертификат денег почему-то пожалели

Примеры можно находить бесконечно. Здесь хоть и не передаются какие-то данные банковских транзакций, не происходит оплата, но я считаю что на перечисленных выше страницах обязательно должно быть установленно защищенное соединение. Уверен что скоро все основные браузеры будут просто блокировать все перечисленные выше страницы из-за нарушения конфиденциальности данных.  Цена вопроса тут — покупка SSL-сертификата и настройка всех протоколов безопасности и шифрования на сервере. Стоимость SSL-сертификата в надежных центрах сертификации от 1500 — до 100.000 рублей в год, в зависимости от необходимого пакета услуг и числа доменов.

По поводу закрытых зон сайта — онлайн.банков, личных кабинетов: ситуация получше, почти все работают на HTTPS-протоколе. Хотя и HTTPS HTTPS’у рознь, ниже приведу результаты анализа защищенности HTTPS-соединения у банков из топ-500.
Хотя были и особо отличившиеся банки, у которых даже личный кабинет работает по незащищенному протоколу HTTP:

Специально опубликовал подробную инструкцию по переходу сайтам на протокол HTTPS без потери трафика.

21% банковских сайтов вообще не содержат файл robots.txt

Напомню, что недавно обнаруженная утечка персональных данных покупателей интернет магазинов, сайтов авиабилетов, отелей, логистических компаний и др. была из-за отсутствия или некорректно составленного файла robots.txt, который указывает поисковым системам какие разделы сайта нельзя индексировать, а какие можно. На самом деле robots.txt это лишь базовая защита, его директивы являются достаточно строгими, но не 100% запретом для поисковиков. В некоторых известных случаях, они могут проигнорировать директивы, файл может быть составлен с ошибками, сохранен в неправильной кодировке и т.п. Но в любом случае  — это защита персональных разделов сайта от индексации  на 99%+. Есть дополнительные методы защиты, такие как мета теги noindex, защита страниц по авторизации, блокировка роботов по user-agent и др.

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

Пример когда robots.txt не сработал, хотя все закрыто корректно.

Но повторюсь,  корретная настройка файла robots.txt хоть и не полная панацея, способна на 99% защитить нежелательные для общего доступа файлы и  разделы от индексации.

Провел анализ топ 500 бакновских сайтов на наличие файла robots.txt (даже без разбора насколько корректно он составлен)

Более 100 из проверенных сайтов (21%) вообще не имеют файла robots.txt или он пустой, полностью неработоспособен.
Банки могут утверждать что никаких персональных данных, личных документов с коммерческой тайной, случайно загруженных сотрудником или программистами на них не хранится — но это глупо. Сбербанк тоже так думал пока не произошла утечка персональных данных о которой я писал ранее:

Данные с платежами третьих компаний утекли в сеть через один из доменов Сбербанка

Если robots.txt  отсутствует у 21% главных банковских сайтов, можно предположить что и у дополнительных, сайтов через которые проходят платежи, оплата картами, и другие операции есть проблемы.  Причем, как оказалось, даже то что вы заказали сайт в топовой студии не гарантирует автоматически того что вам составят файл robots.txt.

Разработка сайта — Студия Лебедева. Наверное на создание и размещение файла robots.txt бюджета не хватило…

Онлайн-Банки уязвимы? Найдены сторонние скрипты

Путем просмотра главных страниц из своего списка топ-500 банковских сайтов получил список страниц входа в банк-клиент, онлайн-банков, личных кабинетов, страниц перевода с карты на карту,  с вводом данных карты/CVC — в общем наиболее чувствительных зон сайтов с банковской информацией.

Проверил наличие сторонних скриптов в этих чувствительных зонах.  В личных кабинатах найдены системы веб-аналитики: Google Analytics, Яндекс.Метрика, Adobe Analytics, диспетчер тегов Google Tag Manager.

Что это за скрипты, какую опасность они могут представлять?

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

Что делать?
Банки в приватных зонах сайта должны использовать только собственные скрипты, которые они контролируют на 100%. Понятно, что разработать систему уровня Google Analytics стоит сотни миллионов долларов и разработку не потянет даже Сбербанк, но и непонятно зачем личным кабинетам такая глубокая аналитика? Достаточно простых счетчиков.

Впрочем, я не первый кто заметил эту проблему. Ранее пользователи уже замечали о сторонних скриптах в личном кабинете Сбербанка.
На что специалисты Сбербанка ответили что постоянно следят за содержанием сторонних скриптов, проблемы нет (Что, кстати, не очень внушило доверие у аудитории Хабра, судя по рейтингу поста и автора).
Так же находил пример у другого банка, где все таки пошли на уступки и после жалоб пользователя все таки удалили сторонние счетчики — вероятно признав потенциальную угрозу.
Да, все уверены что скрипты и данные на серверах  Яндекс, Google, Adobe под надежной защитой, это топовые IT-компании с высококлассными специалистами, но проблема в осном заключается в том что к этим счетчикам имеют доступ аналитики сайта, маркетологи. В личных кабинетах могут быть данные, которые они видеть не должны. Например, уникальные URL с платежками, выписками, доступные без авторизации.  Эти данные могут просмотреть третьи лица, если у них есть доступ к аккаунту со счетчиками.

Ну и доступ к счетчику могут получить третьи лица. Виноват в этом случае будет не Google или Яндекс, а Банк.

Из найденных по ссылкам с главных страниц банка личных кабинетов получается такая статистика:

25% сайтов содержат хотя бы один из трех кодов (GA/Метрика/GTM)
GA ~20%, GTM~15%, метрика ~10% , вебвизор ~5%.

Возможность утечки через запись всех данных вводимых пользователем

Бинбанк. Вводимые пользователем данные записываются и хранятся в системе аналитики

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

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

Опять уточню — вебвизор это отличный инструмент аналитики, никак не связанный с мошенничеством. Просто он не должен быть включен на конфиденциальных страницах. В нем даже есть возможность отключать запись некоторых полей или форм целиком с помощью атрибута ym-disable-keys или закрытых звездочками полей типа password (на сайтах где я проверил — поля не помечены метками запрета записи).
Да даже с ограничением записываемой информации. Это вообще, нормально, что кто-то может просматривать что делают клиенты банка в личном кабинете? Там не должно быть никаких сторонних систем.

Еще примеры:

Россельхоз. Спасибо хоть что CVC закрыли звездочками 🙂

Вот тут ребята заморочились, с клавиатуры запрещено вводить пароль, только через специальную вслывающую цифровую панель.
Но какой смысл, когда все клики записываются? (((

Попытка создать безопасный вход в личный кабинет

Кроме вебвизора на описанном выше примеме я думаю может как-то сработать и просто карта-кликов по элементам в Метрике/GA, если правильно сегментировать пользовател, подобрать его уникальную сигнатуру.

GTM — возможность полного управления содержимым страницы третьими лицами

Некоторые рискуют еще больше, размещая в приватных зонах Google Tag Manager.
Tag Manager — сервис который упрощает размещение на сайте сторонних кодов. Например, скриптов аналитики, различных событий при нажатиях кнопок — незаменим в продвинутой аналитике. Но… не в личных кабинетах банков!

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

  • GTM содержится примерно на ~15% главных страниц личных кабинетов

Пример демо-версии личного кабинета ЛокоБанка. Можно предположить что набор скриптов в основном кабинете такой же.
По крайней мере боевая версия формы авторизации содержит тэг менеджер.

Демо личного кабинета содержит GMT

Проверка надежности HTTPS в защищенных разделах банк-клиент, онлайн-банк и тп.

Для тестирования использовались сервисы скоринга безопасности соединения сайтов.
https://www.htbridge.com/ssl/
https://www.ssllabs.com/ssltest/

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

 

Пример банка с максимальной оценкой.

 

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

Личный кабинет подвержен практически всем видам уязвимостей

Всего было проверено 313 сайтов личных кабинетов, сайтов, результат тестов:

Некоторые «защищенные» банковские сайты вообще не имеют валидного сертификата, либо их уровень безопасности настолько плох что браузеры полностью блокируют сайт:

Больше трети сайтов имеют проблемы с безопасностью, причем больше 10% — критические.

Тот момент, когда твой личный сайт, созданный на коленке за 1 час, по скорингу уровня надежности выше чем 75% сайтов банков.

 

Pavel