Взломай меня, если сможешь: топ-3 технических уязвимости онлайн-платежей
Я довольно долго не публиковал новые материалы, хотя рассказать было о чем. Главная причина – невозможность быть в ресурсе для всего и сразу. Блогинг и словесные потоки не моя сильная сторона, а вот потоки платежей совсем другая история. Меня зовут Денис Михайлюк, сейчас в команде bill_line я занимаю позицию Architect и поэтому мне особенно интересно говорить именно о стратегических вопросах безопасности и нагрузки систем, осуществляющих обработку транзакций. И сегодня я хочу привести три самых больших эксплойта в юзерфлоу онлайн-платежей, с которыми я сталкивался лично или узнал от коллег.
Как должен выглядеть безопасный платеж
Когда вы пополняете мобильный или переводите деньги, процесс кажется вам простым, почти мгновенным. Что ж, это приятно, значит, годы моей работы и моих коллег имеют свои плоды: серверы быстрые, код написан грамотно и регулярно обновляется, а дизайнер с проект-менеджером сделали качественный userflow, в котором нет лишних экранов.
Однако с точки зрения создания безопасной программной реализации процесс прохода транзакции является сложным процессом, до сих пор имеющим кучу проблем у всех, от крупных банков и psp (платежного сервис-провайдера), до новых игроков на рынке, периодически появляющихся с офферами, у которых точно будет что-то вроде “простого и удобного API” с интеграцией за 5-10 минут. Открою большой секрет – у упрощений есть свой «потолок». Комплаенс требует времени, а у бизнеса с процессами, которые сложнее простого ритейла, есть свои уникальные требования или нюансы, которые не ложатся в заготовленные сценарии.
Итак, как выглядит типичный процесс приема платежа? Для начала рассмотрим текущую реализацию токенизированных платежей, когда вы (customer) пытаетесь что-то оплатить, например через Apple Pay\Google Pay:
- Вебсайт/приложение мерчанта дает реквест на API-сервер его psp;
- Вам не нужно вводить платежные данные, потому что их в виде зашифрованного токена сервер передает назад, таким образом, пропуская вас на этап оплаты;
- Если бы вы делали это через 24Pay\monopay на сайте, то вам нужно было бы как-то проавторизироваться, но в принятом сценарии этого не нужно. Вы только подтверждаете платеж биометрией (отпечаток или лицо);
- Также токенизированные данные о заказах снова летят на API-сервер, после чего возвращаются назад, подтверждая или отменяя возможность оплаты (например, недостаточное количество средств на дебетовой карте);
- Вы видите экран удачи или ошибки.
Перед вами простая и понятная схема оплаты (на данный момент все случайные читатели посмеялись и закрыли вкладку), в которой учтена и безопасность, и максимальная бесшовность транзакции. Никакие параметры платежа не передаются явно, вместо этого используются уже стандартные токены. Благодаря им вы можете иметь рекуррентные платежи и платить в один клик. Сервер платежной системы не отправляет результаты на какую-либо URL самостоятельно: вместо этого вебсайт/приложение, с которого вы платите, делает самостоятельные реквесты и обрабатывает ответ.
Окей, что может пойти не так?
Если коротко – дьявол всегда в деталях. Детали, которые не учла команда разработки, которые зафакапили отдельные члены команды или из простого желания найти компромисс между удобством и безопасностью не в пользу последней.
#3 Уязвимость OTP-кода
Эта тема немного устарела, поэтому актуальна больше для декстоп-версий, пользование которыми падает с каждым годом. Однако проблема все еще актуальна. Всегда используйте механизм OTP-кодов (one-time password) для всех важных операций в вашем проекте. Одноразовые пароли должны жить не более 2 минут и быть привязаны четко к выполняемой операции с помощью дополнительного случайного параметра, соответствующего идентификатору операции. Это же правило применимо и к биометрии в приложениях: запрашивайте проверки на основных операциях конечного потребителя. Понятно, что последний не будет рад постоянной необходимостью вводить код из смс или показывать лицо, однако именно так вы убедитесь, что любую операцию осуществляет владелец счета.
#2 Отсутствие механизма HSTS для подключения и отсутствия защиты cookie маркерами Secure и SameSite
В современных браузерах есть ряд механизмов, помогающих защищать данные от перехвата, и HSTS один из них.
Расшифровывается он как HTTP Strict Transport Security и представляет собой механизм принудительного соединения посредством протокола HTTPS. За активацию механизма отвечает заголовок Strict-Transport-Security в ответном HTTP сервере.
Какие еще «заклинания» можно произнести:
- HPKP (HTTP Public Key Pinning) – технология привязки публичного ключа, запрещающая подключаться к веб-серверу, если кто-то подменил SSL сертификат. За активацию отвечает заголовок Public-Key-Pins;
- CSP (Content Security Policy) – тул, направленный на защиту от атак с внедрением контента, например, от «Межсайтового исполнения сценариев». Магия запускается названием Content-Security-Policy;
- X-Content-Type-Options – хедлайн, предназначенный для защиты браузера пользователя от атак с использованием замены типа переданного контента MIME;
- X-Frame-Options – хедлайн против Clickjacking-а.
А теперь о вышеупомянутых маркерах. Secure обязывает передавать cookie только по HTTPS. Отсутствие этого маркера создает угрозу перехвата cookie. Как решить? Просто: устанавливаем значение true для свойства requireSSL.
А вот использование атрибута SameSite в режиме Strict не позволит передавать cookie на сторонние ресурсы и обеспечит защиту от атак типа «Подделка межсайтового запроса».
#1 Десериализация недоверенных данных
Нельзя использовать сериализированные объекты при передаче в параметрах, которые могут быть легко подделаны злоумышленником. Самый простой способ избежать этого – использовать цифровую подпись таких объектов с проверкой на стороне сервера.
Игнорирование такой ошибки ведет как к критически опасным уязвимости типа «Выполнение произвольного кода» или «Десериализация недоверенных данных», так и к менее очевидным вещам. К примеру, коллеги во время работы на сервере онлайн-банка обнаружили интерфейс с адресом внутренней сети банка. Если знать этот адрес, хакер может производить атаки на всю корпоративную инфраструктуру и поставить под угрозу процессинг.
