Соответствие PCI и Ajax

Question

У меня есть такая идея, но я не уверен, совместима ли она с PCI.Я новичок в области соблюдения требований PCI, и мне интересно узнать, нарушает ли этот сценарий PCI.

Итак, давайте настроим сценарий.Компания А соответствует требованиям PCI и имеет веб-сервис по протоколу https, предоставляющий некоторые функциональные возможности обработки платежей.Компания Б не соответствует требованиям, но ее веб-сайт безопасен.

Вот этапы сценария.

1. Веб-сайт B связывается с веб-сервисом A через код на стороне сервера.Эта служба отправляет обратно зашифрованный токен аутентификации.
2. Б вставляет этот токен на страницу, содержащую форму для приема информации о кредитной карте.
3. Пользователь вводит данные своей кредитной карты на веб-сайте B.
4. Информация о форме вместе с токеном отправляется через ajax-вызов веб-сервису A.
5. Веб-сервис А обрабатывает данные и возвращает статус (Одобрено/Отказано/и т. д.)

Вопрос в том, что, поскольку javascript передается непосредственно с компьютера пользователя на совместимые серверы компании А, совместим ли он с PCI?Мне очень интересно узнать, что думают эксперты в этой области.

Answer 1

Брошюра по PCI DSS Все Стандарты PCI

PCI DSS (Стандарт безопасности данных индустрии платежных карт) имеет концепцию «объема» — определения того, какие системы подпадают под эгиду PCI.

Вы торговец или поставщик программного обеспечения?Если PAN (основной номер счета), длинный номер кредитной карты, никогда не отправляется на ваш веб-сайт, то ваш веб-сайт обычно не попадает в сферу действия PCI.-- Предполагая, что вы торговец.Если вы являетесь поставщиком программного обеспечения, то ваше программное обеспечение, вероятно, будет подпадать под действие PA-DSS (см. ниже).

PAN, проходящий через ваш серверСтарая идея заключалась в том, что PAN будет отправлен на ваш веб-сайт (через отправку формы в браузере), затем ваш веб-сайт развернется и отправит его на платежный шлюз (например, Authorize.Net).В этом сценарии PAN никогда не хранился на вашем сервере, но транзит ваш сервер.Раньше это означало, что ваши торговые системы не будут подпадать под действие PCI DSS, поскольку они никогда не хранили PAN.Но эти дни быстро заканчиваются или уже прошли.(Это зависит от того, насколько агрессивно ваш эквайер/поставщик торгового счета относится к PCI.)

Управление вашей веб-страницей Поскольку ваша веб-страница не передает PAN на ваш сервер, вы не находитесь в области действия PCI.Но как узнать, что кто-то не изменил вашу веб-страницу, чтобы передать PAN обратно на ваш сервер (или куда-либо еще, используя методы JSONP)?Ответ заключается в том, что вам необходимо убедиться, что никто не будет вмешиваться в вашу страницу с формами оплаты.

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

Стандарт безопасности данных платежных приложений (PA-DSS) Если вы продаете свое программное обеспечение торговцам, то оно, вероятно, будет подпадать под действие стандарта PA-DSS.См. стандартный.

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

Вполне возможно, что QSA может сказать, что, поскольку вы контролируете свою веб-страницу, она должна находиться под PCI, поскольку она может быть кем-то повреждена.Но это был бы настойчивый аргумент.В конце концов, тогда вы могли бы сказать, что каждая веб-страница любого интернет-торговца должна находиться под PCI, поскольку любая веб-страница может быть повреждена, чтобы запросить у людей PAN, а затем сделать с ним что-то плохое.С другой стороны, это именно тот аргумент, который Visa использует для расширения возможностей PCI для корпоративных франчайзеров. Статья.

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

Добавлен: Подробнее об определении области действия Как видно из вышеизложенного, ключевой вопрос заключается в том, какие системы находятся в области PCI, а какие нет.В Совете PCI теперь есть Специальная группа по интересам (SIG), которая изучает весь этот вопрос о том, что находится в сфере PCI, а что нет.И я предполагаю, что они захотят, чтобы конверт рос, а не сжимался.

Добавлен: Это между вами и вашим адвокатом В вашем сценарии обработка PAN начинается в браузерах ваших клиентов.PAN никогда не достигает ваших систем, даже на мгновение.Я считаю, что вы выходите за рамки PCI DSS для продавцов.Но именно вы подписываете заявление о соответствии PCI, которое представляет собой контракт между вами и вашим покупателем.Таким образом, толкование стандарта PCI DSS зависит от вас и вашего юриста, а не от меня.

Нижняя граница Никогда не следует хранить данные PAN в своих системах.Вы даже не должны пропускать его через свои системы.Новые протоколы платежных шлюзов от Authorize.Net и Braintree позволяют использовать технику отсутствия транзита.В зависимости от объема ваших транзакций по кредитным картам, соответствие PCI варьируется от самостоятельного контрольного списка до огромного проекта.

Чтобы узнать больше о военных историях PCI, проверьте Витрина магазина блог и их покрытие PCI.

Answer 2

Ответ Ларри К. хорош.В основном это политический/слойный вопрос.

Кажется, что использование iframe для публикации из B в A является общепринятым решением, тогда как использование Ajax - с CORS или JSONP - несколько более сомнительно, но все же, по крайней мере, для некоторых крупных игроков, приемлемо.

А Информационное дополнение:Рекомендации PCI DSS по электронной коммерции v2 говорит о том, что это решение (API прямой публикации) в порядке, но вы должен позаботьтесь о безопасном кодировании (хотя PCI DSS не предписывает ничего конкретного, что вам нужно будет делать) - см. раздел 3.4.3.1 Сторонние встроенные API с прямой публикацией и связанные с этим 3.4.3.4 Вопросы безопасности для реализации электронной коммерции с совместным управлением, который гласит:

API-подход с прямой публикацией:С подходом API прямого пост продавец все еще несет ответственность за веб-страницу, представленную потребителю, и продавец проводит поля на странице платежей, которые принимают данные-только данные владельца карты размещаются непосредственно от потребителя до Поставщик услуг.Поскольку страницы оплаты размещаются торговцем, страницы оплаты столь же безопасны, как и веб -сайт продавца, и компромисс системы продавца может привести к компромиссу данных платежных карт....В частности, для всех вышеперечисленных сценариев продавец должен контролировать любые доказательства того, что системы изменились и быстро реагируют на восстановление систем в доверенное состояние, когда обнаруживаются несанкционированные изменения.Торговцы, которые применяют эти модели общего управления, чтобы минимизировать применимые требования PCI DSS, должны знать о потенциальных рисках, которые присуща этим типам системной архитектуры.Чтобы свести к минимуму вероятность атаки в этих сценариях, торговцы должны применять дополнительную проверку, чтобы обеспечить безопасное разработку веб -приложения и пройти тщательное тестирование на проникновение.

Например, Платежный шлюз Stripe использует прямую отправку через JSONP с 2012 года вместо подхода iframe, который они использовали раньше.

С другой стороны, WePay также предоставляет API прямой почтовой рассылки, но рекомендует iframe, чтобы полностью избавиться от требований PCI [WP] (утверждая, что с помощью API прямой почтовой рассылки «[..] вы по-прежнему обязаны соблюдать стандарты безопасности данных индустрии платежных карт (PCI-DSS) и стандарты безопасности данных платежных приложений (PA-DSS), когда это применимо.(без уточнения, что именно означает «всякий раз, когда это применимо»).

[WP] Ссылка на WePay: https://www.wepay.com/developer/tutorial/tokenization

Answer 3

Я недавно прошел через работу PCI-соответствия для наших серверов, так что это прямо перед собой. Короткий ответ: нет.

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

Будет ли услуга PCI-соответствия фактически соединяет эти точки и о том, как они подтверждают его, так как прохождение или недостаток может быть другим вопросом.

Answer 4

Независимо от того, «технически» встречает стандарты PCI (или нет), я бы не доверился таким образом, чтобы делать вещи.

Если форма находится на странице в пределах имени хоста B, B имеет полный доступ к тому, что находится в полях формы. (B'S-сервер способен отправлять пользовательский злобный JavaScript, если он хочет.)

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

Answer 5

Здесь Веб-сайт PCI

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

Для забавности здесь есть ссылка (PDF) на страницу 38 'Краткое пособие.