что такое сервис 3d secure
Что такое 3-D Secure и как она защищает твою банковскую карту
Простота оплаты приложений, товаров и услуг сегодня позволяет нам расставаться с деньгами быстрее чем когда либо. Уважающий себя сервис сегодня должен иметь способ мгновенной оплаты своих услуг, иначе потребители уйдут к конкурентам.
К сожалению, такие технологии порождают новые возможности для мошенников. Доверия к приложениям и сайтам с каждым днем все меньше. Ты же знаешь, как могут увести данные твоей банковской карты.
Самое время вспомнить о проверенном временем способе защиты.
У клиента банка могут украсть карту или телефон, но вероятность, что в руках мошенников окажется и то и другое, гораздо меньше. Добавим к этому защиту на самом устройстве в виде пароля или биометрического сенсора и получаем довольно хороший уровень безопасности.
Как это работает
Изначально технология 3-D Secure была разработана для платежной системы Visa. Позже подобным протоколом обзавелись системы Masterсard, JCB International, AmEx, «Мир» (НСПК) и другие.
Сейчас практически все банки поддерживают 3-D Secure, но не всегда активируют защиту для клиентов по умолчанию.
Принцип работы технологии прост и знаком большинству из нас. При попытке совершения платежа от покупателя требуют не только данные карты, но и подтверждающий код, который приходит по СМС на привязанный мобильный номер.
Реже вместо СМС могут использоваться постоянные или одноразовые коды, которые известны лишь держателю карты.
Для ввода таких кодов всегда используется защищенный интерфейс банковской системы, что само по себе гарантирует безопасность оплаты.
Преимущества и недостатки
Такая двухфакторная авторизация призвана повысить защиту средств клиента, но имеет как положительные, так и отрицательные стороны.
Дополнительная защита никогда не бывает лишней, при краже карты или телефона снять деньги со счета практически невозможно. Даже если в руках злоумышленника окажется и то и другое – потребуется взломать еще и защиту смартфона.
3-D Secure снижает оперативность покупателя. СМС с паролем приходят не так быстро, как хотелось бы. Оператор может и вовсе «потерять» нужное сообщение, а если находишься в зоне неуверенного приема, проклинаешь эту защиту через пять минут.
Как еще можно защититься
Система 3-D Secure не гарантирует 100% защиту средств на карте. Для большей надежности следует придерживаться определенных правил:
Некоторые банки дополнительно предлагают застраховаться от потери денег с карты. За дополнительный процент или фиксированный ежемесячный платеж можно обезопасить себя от мошенников.
3-D Secure
3-D Secure — защищенный протокол авторизации пользователей для CNP-операций (проходящих без физического присутствия карты). Это дополнительный уровень безопасности — еще один шаг аутентификации пользователя, который расплачивается за товары или услуги онлайн. Во время покупки, чтобы подтвердить онлайн-платеж, держатель карточки вводит особый код (как правило, получает его в сообщении на привязанный телефонный номер).
Если технология поддерживается онлайн-продавцом, на его сайте есть логотипы Verified by Visa (VbV) и (или) MasterCard® SecureCode™.
3-D Secure важно отличать от кода CVV2 (находится на оборотной стороне карточки возле подписи владельца и обычно состоит из 3 цифр).
3-D Secure не гарантирует абсолютную безопасность финансов: все же остается риск, что одноразовый код украдут компьютерные вирусы. Технологию поддерживают не все банки и не все интернет-магазины. Во многих случаях для перевода денег с карты требуется указать лишь имя и фамилия владельца, номер и срок действия карточки, CVV2-код.
«Беларусбанк» предлагает совершать безопасные платежи в интернете держателям международных карт Visa, Maestro, MasterCard, БЕЛКАРТ-Maestro, а также для получивших карточки Visa Electron, Maestro, действительных на территории Беларуси.
«Белинвестбанк» подключает к 3-D Secure карточки Visa и Visa Electron.
Актуальную информацию лучше узнавать в банке, эмитировавшем карточку.
Как подключить 3-D Secure
Услуга обычно бесплатная, однако некоторые условия (список доступных карт, подключение) разнятся.
В большинстве случаев владельцу карточки надо подключить интернет-банкинг и в нем активировать услугу.
Клиентам «Беларусбанка» это следует делать в разделе «Пароль 3-D Secure»: необходимо пройти регистрацию, придумав пароль (от 9 до 15 любых символов). Предусмотрен запасной пароль. Надо придумать секретный вопрос и ответ на него. Если пароль 3-D Secure потеряется или забудется, секретный вопрос позволит задать новый пароль для безопасных покупок в Сети.
«Белинвестбанк» предоставляет пользователям право получить доступ к 3-D Secure, если пользователь карты подключен к интернет-банкингу. В банкинге надо выбрать карту и нажать кнопку «3-D Secure». Затем задать пароль, написать личное приветствие, секретный вопрос и ответ; нажать кнопку «Сохранить».
«Приорбанк» предупреждает клиентов, что 3-D Secure применяется, если у банка есть актуальный номер мобильного телефона владельца карточки.
Держатели карт, полученных в «Белагропромбанке», должны войти в банкинге в меню «Операции в сети Интернет», там выбрать карту и нажать «Активация 3D-Secure». Затем заполнить стандартные поля.
«Альфа-Банк» автоматически активизирует 3-D Secure в течение 2 банковских дней после получения карточки, если ее владелец указал в анкете номер мобильного телефона.
9 секретов онлайн-платежей. Часть 1: настройка 3-D Secure
Российский рынок e-commerce живет в условиях кризиса, сейчас то время, когда одной из ключевых задач для успешного «выживания» является настройка всех «винтиков» механизма вашего сайта. Один из таких «винтиков» — это сервис приема онлайн-платежей на сайте. При правильном подходе он может стать фактором успеха, а при неверном использовании — привести к серьезным проблемам. В данном выпуске, первом из серии «9 секретов онлайн-платежей», содержащей восьмилетний опыт работы команды PayOnline, мы поделимся правилами настройки протокола 3-D Secure для успешной обработки платежей на вашем сайте.
Краткий экскурс в историю вопроса
Создатель протокола 3-D Secure (3DS) – международная платежная система Visa (программа Verified by Visa). 3DS поддерживается ключевыми мировыми платежными системами: MasterCard SecureCode и J/Secure от JCB International.
Основная задача 3DS – защитить плательщиков и предприятия от мошенников. Поддержка протокола 3DS практически ликвидирует опасность совершения мошеннических операций с помощью банковской карты, так как является ещё одним способом подтверждения личности плательщика.
Почему 3-D Secure так называется? В обработке платежа с использованием протокола 3DS участвует три домена (3D), на которых создаются и проверяются транзакции (платежные операции по банковским картам): домен эквайера, домен эмитента и домен взаимодействия.
Как это работает?
80% банковских карт в России подписаны на протокол 3-D Secure. 30 миллионов россиян совершают покупки в Интернете. Значит, более 24 миллионов россиян хотя бы раз проходили через процесс авторизации платежа с помощью 3DS. Как это происходит с точки зрения плательщика?
Человек оформляет заказ на сайте, нажимает «Оплатить» и, заполнив платежную форму, попадает на страницу, расположенную на домене банка-эмитента (банка, выпустившего карту), для ввода уникального кода проверки.
Код в большинстве случаев поступает в виде SMS, иногда используются другие механизмы (набор кодов на карте, уточнение кода по телефону в банке и т.д.). Всё, что нужно сделать плательщику – ввести код в соответствующее поле и закончить процедуру оплаты.
С точки зрения интернет-магазина всё не так просто. Не все банковские карты в России подписаны на 3DS: ряд банков просто не поддерживает протокол, в некоторых банках решение о подключении услуги 3DS авторизации принимает плательщик. Таких карт – около 20% от общего числа. России было выпущено более 220 миллионов карт, по полторы карты на человека. Конечно, стоит учитывать, что люди, совершающие покупки в интернете, стараются защитить себя, а карты без 3DS в основном выпускаются в рамках зарплатных, пенсионных, стипендиальных проектов.
Но, все-таки, в аудитории каждого коммерческого сайта есть клиенты с картами, не подписанными на 3DS (их доля зависит от типа бизнеса компании, географии ее работы и других факторов). Нужно принять решение о том, как работать с этими клиентами, как настроить протокол 3-D Secure.
Именно здесь интернет-магазин сталкивается с вопросом безопасности и необходимостью оценки рисков. Пропускать все транзакции подряд – шаг рискованный, можно «нарваться» на мошенников, получить чарджбэки и потерять заметную часть прибыли. С другой стороны, отклонять платежи по картам, не подписанным на 3DS, значит терять лояльных клиентов и собственную прибыль.
Компромисс между безопасностью и конверсией
Настройка 3D-Secure на сайте – дело «тонкое». Она требует понимания уровня рисков в том сегменте интернет бизнеса, в котором работает компания.
Full 3DS
Full (полный) 3DS – это базовая настройка протокола 3DS, рекомендованная международными платежными системами. Эта настройка минимизирует риск возникновения мошеннических операций и, соответственно, вероятность чарджбэков и финансовых рисков для компании.
Как это работает? Очень просто. Платежи одобряются только после прохождения авторизации с помощью протокола 3DS. Действует для всех карт без исключения. Все транзакции проходят по протоколу 3DS.
Если проверка по 3DS на стороне эмитента не работает или карта не подписана на 3DS, транзакция пройдет только с согласия эмитента, в противном случае будет отклонена.
Такая настройка протокола соответствует международным стандартам безопасности и минимизирует уровень рисков возникновения мошеннических операций. В рамках нашего базового коробочного платежного решения Pay-Start (решение разработано для сайтов с оборотом до 30 тысяч рублей в сутки), используется только базовая, Full, настройка протокола 3DS. Это обеспечивает небольшим компаниям практически полную безопасность при приеме платежей. Платежный сервис несет ответственность за безопасность платежей и никогда не порекомендует клиенту «поставить себя под удар» мошенников.
Однако, в случае с крупным бизнесом, вопрос увеличения конверсии становится настолько критичным, что может заставить предпринимателя пойти на уступки в отношении безопасности. В этой ситуации часть или все платежи по банковским картам обрабатываются без проверки с помощью 3DS. Это касается минимальной и двухступенчатой настроек протокола.
Минимальный 3DS
Минимальные настройки протокола 3DS позволяют проверить карты, подписанные на 3DS, а остальные пропустить без проверки (точнее с проверкой – но с помощью других инструментов системы безопасности, так называемых фильтров безопасности).
Двухступенчатый 3DS
Эта настройка протокола 3DS похожа на минимальную, но имеет одно существенное отличие. В этом случае все запросы на одобрение транзакций направляются в банк-эмитент по протоколу 3DS. И банк-эмитент принимает решение о возможности проведения транзакции, если карта плательщика не подписана на протокол 3DS. Если банк отклоняет транзакцию, она направляется на проверку повторно, но уже не по протоколу 3DS.
Можно пойти дальше и выбрать один из трех возможных вариантов, настроив 3-D Secure ещё «тоньше», учитывая тип бизнеса и географию стран, в которых представлены интересы компании. Например, включить 3DS для определенных стран или заданного типа карт, а также в зависимости от различных параметров платежа — суммы, географии плательщика и т.д.
Нужно еще раз отметить, что минимальный и двухступенчатый 3DS при непрофессиональном использовании могут повысить уровень риска возникновения мошеннических операций и, соответственно, финансовых потерь. В общем, настройка 3DS – это совсем не игрушка.
Перед изменением настроек протокола проводится совместный анализ аудитории и специфики бизнеса компании (средний «по больнице» уровень рисков в данном сегменте, география приема платежей, размер среднего чека и т.д.). Анализ проводится специалистами платежного сервиса при участии представителей компании клиента. По результатам проведенного анализа предоставляются рекомендации по возможности изменения настроек и сопряженному с ними уровню рисков. Финальное решение принимает клиент, так как он берет на себя ответственность за возможность возникновения мошеннических операций. Стоит отметить, что изменения чаще всего внедряются в случае, если нет серьезных опасений о появлении фрода.
Что же делать?
Здесь встает вопрос, по какой же схеме удобнее, выгоднее и безопаснее работать интернет-магазину или другому сервису, принимающему платежи онлайн?
Единственная слабость Full 3DS очевидна – платежи по картам, не подписанным на 3DS (в России их около 20% и их число постоянно уменьшается), будут отклоняться. Такие карты обычно эмитируются банками, не входящими в ТОП-50, зачастую региональными. Главным плюсом же является практически полная безопасность: в соответствии с установленными международными платежными системами правилам ответственность за операции, обработанные по протоколу 3DS, несет банк-эмитент (банк, выпустивший карту).
Выбирая двуступенчатый или минимальный 3DS, интернет-магазин берет на себя риски, связанные с возможностью возникновения фрода (мошеннических операций). Однако, при профессиональном анализе рисков, тонкой настройке системы фрод-мониторинга на стороне платежного партнера доля успешных транзакций заметно увеличивается, иногда на десятки процентов.
От теории к практике
Рассмотрим кейс одного из наших клиентов, авиабилетного агентства «Посошок» (pososhok.ru). Оборот компании в 2013 году составил 4,5 млрд. рублей, на сегодняшний день компания может похвастаться полутора миллионами обслуженных пассажиров.
В марте 2014 года компания столкнулась с проблемой: авторизация покупателей с помощью протокола 3-D Secure давала высокую степень защиты, но перед компанией стояла задача увеличить конверсию в оплаты: одобрялось лишь 79% транзакций.
На тот момент использовалась двустадийная авторизация платежей. Первая стадия авторизации проводилась по протоколу 3D-Secure. Если платеж совершался с карты, не подписанной на 3DS, на второй стадии авторизации проверка выполнялась системой мониторинга мошеннических операций PayOnline (о ней будет рассказано подробнее в следующих статьях) на основании настроек её фильтров.
Проанализировав аудиторию покупателей, ядро которой составляли россияне, специалисты «Посошка» совместно с консультантом PayOnline приняли решение об изменении настроек безопасности для платежей из России, совершаемых картами, эмитированными в России. Для таких платежных операций была отключена авторизация по протоколу 3DS. Их проверяла система мониторинга мошеннических операций PayOnline, каждый из 154 фильтров, которой был настроен в соответствии со спецификой бизнеса «Посошка». Для остальных типов транзакций продолжала применяться авторизация по 3DS.
Результат не заставил себя долго ждать: уже через полгода конверсия «взлетела» до 91%, и продолжала расти.
При этом количество «чистых» операций, отклоненных системой мониторинга за этот период, можно пересчитать по пальцам – и все они впоследствии были идентифицированы и проведены вручную. А благодаря профессионализму специалистов, занимавшихся настройкой протокола 3DS, изменения не сказались на уровне безопасности.
В следующем выпуске мы расскажем, как привязать клиента к своему сервису при помощи регулярных платежей, что это такое, какие вопросы на этапе подключения могут возникнуть у вас, а в процессе использования – у плательщиков, и какой «профит» ожидает в результате. Если вы хотите подключить и настроить платежи, обращайтесь, наши специалисты помогут вам в этом.
3D Secure, или что скрывают механизмы безопасности онлайн-платежей
Электронная коммерция — одна из самых больших и быстро растущих областей, в связи с чем она привлекает внимание как исследователей информационной безопасности, так и злоумышленников. Поэтому хотелось бы разобраться в некоторых аспектах механизмов безопасности, применяемых при проведении онлайн-платежей.
Один из протоколов, используемых для увеличения безопасности онлайн-платежей — 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.
Почему протокол 3D Secure называется именно так?
Полное название этого протокола — Three Domain Secure.
Первый домен — домен эмитента — это банк, выпустивший используемую карту.
Второй домен — домен эквайера — это банк и продавец, которому выплачиваются деньги.
Третий домен — домен совместимости (interoperability domain) — инфраструктура, используемая при оплате картой (кредитной, дебетовой, предоплаченной или другими типами платежных карт) для поддержки протокола 3D Secure. Он включает в себя Интернет, подключаемый модуль продавца (merchant plug-in), сервер контроля доступа (access control server) и других поставщиков программного обеспечения.
Зачем это нужно?
3D Secure обеспечивает новый уровень безопасности путем предоставления дополнительной информации.
Еще одним важным моментом является «перенос ответственности». Это означает, что в случае мошенничества вся ответственность ложится на банк-эмитент. Этот момент является очень важным для продавца (мерчанта), т.к. до появления 3D Secure урегулированием спорных вопросов приходилось заниматься мерчанту.
Также не стоит забывать о двух важных психологических аспектах: повышении доверия к онлайн-платежам и увеличении конверсии.
Конверсия может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.
Версии протокола 3D Secure
В настоящее время большинство платежных сервисов используют версию 1.0.2 при проведении онлайн CNP-платежей, запрашивающих OTP-код.
Версия 1.0.2 была создана в 2001 году и в ней есть некоторые проблемы.
На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.
Как это устроено?
Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.
На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.
Как это работает?
Главное, что необходимо понять, — это то, что при использовании своей карты (виртуальной или реальной) для онлайн-оплаты, вы сталкиваетесь именно с протоколом 3DS. Поэтому сейчас мы проиллюстрируем все этапы совершения онлайн-платежа.
1 — Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку «Оплатить». В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.
После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.
После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.
VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.
Клиенты не могут видеть эти два типа сообщений.
2 — MPI создает PaReq (Payment Request) — запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.
Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.
3 — Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.
А поподробнее?
CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.
В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.
VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.
Pareq
Браузер клиента, совершающего оплату, может произвести достаточно много редиректов по различным компонентам, участвующим в совершении платежа. Так, в России есть некоторое количество запросов, обрабатывающихся на стороне Национальной Системы Платежных Карт. Но сегодня нас интересует только традиционный этап, описанный в спецификации протокола. А именно этап передачи PaReq.
Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD — данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq — параметр этого платежного запроса. Он содержит всю важную информацию о платеже;
3) TermUrl — URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.
Параметры TermURL и MD всегда отражаются в ответе на данный запрос. Поэтому могут встречаться имплементации ACS, уязвимые к атакам типа reflected XSS. В процессе аудита различных систем такие сервера были найдены.
Важный момент №1: ACS сервера обрабатывают все входящие PaReq!
Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq — это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.
Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).
При отправке правильно сформированного PaReq (в большинстве случаев вам не нужен полный набор запросов на оплату — требуется отправить лишь PaReq, содержащий параметры правильного типа и длины), мы получим PaRes — ответ на платеж, подобный следующему:
Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос — это попробовать выполнить XXE. И это правильный путь!
Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:
Ошибка может помочь получить дополнительную информацию о версии ACS. Некоторые из них могут также оказаться полезными для получения данных из XXE.
Раскрутим XXE
Рассмотрим следующий пример:
acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.
Еще один интересный параметр (и наиболее полезный для атаки) — это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.
Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:
Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор — это выполнить DOS через XXE-атаку «billion laughs» (проверялось на тестовом сервере).
Где это можно найти?
В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:
И распространенные имена поддоменов:
Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.
3D Secure v 2. *
Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.
Основная проблема в том, что покупатель может использовать множество разных типов устройств. Планшет, мобильный телефон, умные часы, умный чайник и т.д. Но сайт ACS не всегда разработан для взаимодействия со всеми типами устройств.
Для этого в 3DS 2.0 предусмотрели 3DS SDK.
Другая проблема состоит в том, что новый тип защиты требует дополнительного взаимодействия с клиентом. И этот момент влияет на конверсию. Решением проблемы конверсии стала возможность использования механизма управления рисками, который позволяет не заставлять пользователя вводить дополнительные секретные данные, если банк обладает достаточным количеством информации, подтверждающей личность клиента.
Следующий важный момент заключается в том, что технологии аутентификации развиваются. Соответственно, 3DS могла бы использовать не только OTP. Поэтому v2 задумывалась с возможностью расширения поддержки различных механизмов аутентификации.
Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!
Этот психологический момент послужил причиной изменения спецификации второй версии протокола для сокрытия момента перенаправления.
Как работает 3D Secure v2?
Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.
Первый и самый важный момент — это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.
Особенности работы v2
Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).
Условно, 2-ю версию можно разделить на два блока. Красный, где пользователь непосредственно влияет на передаваемую информацию, и желтый, где система сама собирает и передает информацию о пользователе.
А поподробнее?
AReq (base64url) расскажет все о вас и об устройстве, с которого совершена покупка.
Если вы задумаетесь о том, какой информацией о вас располагают рекламные агентства, то данные AReq вас не удивят. Но если вам кажется, что это плохо, рассмотрите следующий момент: банки знают все о ваших покупках и о вас. С этой точки зрения, некоторая дополнительная информация не так уж и плоха)
Это сообщение необходимо для работы системы управления рисками и упрощения покупок.
Если этой информации оказалось недостаточно, Risk Engine сперва попытается получить дополнительную информацию, и именно в этот момент клиент может получить OTP-запрос.
Что контролирует пользователь?
CReq (base64url json) — challenge request — сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.
Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).
В CReq вы можете увидеть следующие поля:
К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.
Подведем итоги
Проблемы (найденные и возможные)
На что смотреть в v1
На что смотреть в v2
Тем, кто подумывает обратить свой взгляд на платежные системы, я бы посоветовал остановиться еще и на сервисах, предоставляющих 3DS как SaaS. Там может оказаться еще достаточно много вещей, которые помогут вам понять, как устроен мир онлайн-платежей.