4 рекомендации разработчикам по обеспечению безопасности электронных платежей

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

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

Команда A1QA проанализировала уязвимости, с которыми она чаще всего встречается, проводя тестирование безопасности ПО, и выработала рекомендации, которые помогут сделать продукт более защищенным.  

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

1. Надежные механизмы аутентификации
Простой аутентификации по паролю будет недостаточно, что подтверждает длинный перечень уязвимостей, которые встречаются в случае защиты с помощью одного пароля. Вот только некоторые из них:
  • Слабая парольная политика в комбинации с возможностью перебора пользователей;
  • SQL-инъекции в форме логина;
  • Не требуется повторная аутентификация для того, чтобы сменить пароль, изменить адрес доставки и т.д.
Эти прописные истины хоть и всем известны, но все еще очень часто встречаются в e-commerce решениях.
Многие владельцы таких решений считают, что можно защитить пользователей, используя дополнительный этап: высылая одноразовый код или используя биометрические данные. Но, как показывает практика, часто встречаются случаи, где даже двухфакторная аутентификация не спасает от получения доступа к кабинету пользователя:
  • Дополнительный пароль, который высылается на email или смс-кой часто можно предугадать, подобрать или использовать не 1 раз;
  • Биометрические данные (отпечаток пальца, сканер глаза) также несложно обходятся слепками или фото/видео владельца.
При проектировании приложений и систем, единственно верным и безопасным решением является учет требований безопасности не просто «для галочки», а с привлечением эксперта ИБ для изучения и корректировки технических заданий.

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

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

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

Ключ к успеху – конфигурационные недостатки.
Здесь кроется масса категорий уязвимостей:
  • Отсутствие последних обновлений компонентов. Уязвимость может появиться в любом компоненте: в библиотеке шифрования передачи данных, в CMS, на которой написан сайт, операционной системе сервера;
  • Хранение проектных артефактов в открытом доступе. Мы не раз находили исходный код приложения в публичных репозиториях подрядчика-разработчика, доступные окружения для разработки/тестирования с ключами для платежных систем.
  • Забытые файлы, которые можно даже загуглить. Google может подсказать где лежат физические карты помещений банка, внутренние отчеты о рентабельности и финансовых оборотов компании. Отдельной категорией служат конфигурационные файлы, из которых можно узнать учетную запись к базе данных.
  • Уделять внимание выбору хостингового плана или использованию серверов для нескольких приложений. На проектах мы встречали случаи, когда доступ к серверу можно получить не через непосредственный объект тестирования, а приложение-соседа, развернутое на том же сервере. Злоумышленник не ограничен в выборе методов атак, не связан договором об объекте тестирования.
3. Работа с пользователями
Любая зрелая компания должна понимать, что наиболее уязвимое звено в любой масштабной атаке – люди. Не все пользователи могут распознать атаку на них и отличить настоящее приложение от поддельного со схожим интерфейсом или работника тех. поддержки и злоумышленника им представляющимся, но абсолютно все пользователи рады делать покупки, не выходя из дома.

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

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

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

4. Лучшие практики индустрии
К счастью, сообщество обеспокоено повышением безопасности платежных систем. Появление стандарта PCI DSS регламентировало требования по безопасности для систем, обрабатывающих данные кредитных карт.

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

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

Далее следует сменить логины и пароли для доступа к панели администрирования.

И только после этого следует начать расследование: искать «узкие места» в защищенности приложения, определять другие векторы для атак, предпринять меры для того, чтобы избежать повторения такого сценария в будущем.

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

http://club.cnews.ru/blogs/entry/4_rekomendatsii_razrabotchikam_po_obespecheniyu_bezopasnosti_elektronnyh_platezhej
безопасность персональных данных платежная система уязвимость Электронные платежные системы
Alt text

a1qa

Все о тестировании и качестве ПО