Соответствие PCI и Ajax - PullRequest
       5

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

9 голосов
/ 19 ноября 2010

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

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

Вот шаги сценария.

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

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

Ответы [ 5 ]

13 голосов
/ 19 ноября 2010

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

PCI DSS (стандарт безопасности данных в индустрии платежных карт) имеет концепцию "Scoping" - определение того, какие системы попадают под зонтик 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 (Qualified Security Assessor), который проверит и одобрит ваш план соответствия требованиям PCI и области охвата.

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

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

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

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

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

Для получения дополнительной информации о PCI войдите в блог StorefrontBacktalk и их покрытие PCI .

6 голосов
/ 04 марта 2014

Ларри К ответ хорош.Это в основном политическая штука.

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

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

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

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

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

[WP] WePay link: https://www.wepay.com/developer/tutorial/tokenization

3 голосов
/ 19 ноября 2011

Недавно я прошел некоторые работы по обеспечению соответствия PCI для наших серверов, так что это прямо передо мной. Краткий ответ - нет.

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

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

1 голос
/ 19 ноября 2010

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

Если форма находится на странице с именем хоста B, B имеет полный доступ к тому, что находится в полях формы. (Сервер B может отправлять пользователю вредоносный JavaScript, если он этого хочет.)

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

0 голосов
/ 19 ноября 2010

Вот сайт PCI

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

Для развлечения вот ссылка (pdf) на 38 страницу «Краткое» руководство .

...