A Conformidade com PCI e Ajax

Question

Eu tenho essa ideia, mas eu não tenho certeza se ele é compatível com PCI.Eu sou novo para a arena de conformidade com PCI e estou curioso para saber se este cenário viola PCI.

Então, vamos configurar o cenário.A empresa A é compatível com PCI e tem um serviço da web em https expor pedaços de funcionalidade em torno de processamento de pagamentos.A empresa B não é compatível, mas o seu website está seguro.

Aqui estão os passos do cenário.

1. B site contactos do webservice através de código do lado do servidor.Este serviço envia de volta um encriptado authetication token.
2. B injeta este token para uma página que contém um formulário para aceitar informações de cartão de crédito.
3. O usuário insere suas informações de cartão de crédito em B do site.
4. As informações do formulário, juntamente com o token, são enviados através de uma chamada ajax para Um webservice.
5. Um webservice processa os dados e cospe de volta um status (Aprovado/Negado/etc)

A questão é, desde o javascript vai diretamente na máquina do usuário para Uma Empresa em conformidade com os servidores, é compatível com PCI?Eu estou muito interessado em saber o que os especialistas nesta arena de pensar.

Answer 1

Panfleto no PCI DSS Todos os Padrões de PCI

O PCI DSS (padrão de segurança de dados da indústria de cartões de pagamento) possui o conceito de "escopo" - determinando quais sistemas estão sob o guarda -chuva da PCI.

Você é um comerciante ou um fornecedor de software?Se o PAN (número da conta principal), o número de cartão de crédito longo, nunca for enviado ao seu site, seu site geralmente não está no escopo do PCI. - assumindo que você é o comerciante. Se você é um fornecedor de software, seu software provavelmente estaria no escopo do PA-DSS (veja abaixo).

Pan transitando seu servidorA antiga idéia era que a panela fosse enviada para o seu site (por meio de um envio de formulário do navegador), então seu site se viraria e o enviaria para um gateway de pagamento (por exemplo, autorize.net). Nesse cenário, a panela nunca foi armazenada em seu servidor, mas fez transito seu servidor. Isso costumava significar que seus sistemas de comerciantes não estariam no escopo do PCI DSS, pois nunca armazenavam a panela. Mas esses dias estão terminando rapidamente ou já se foram. (O que depende de quão agressivo seu fornecedor de contas de adquirentes/comerciantes é sobre PCI.)

Controlando sua página da web Como sua página da Web não transmite nenhum PAN para o seu servidor, você não está no escopo do PCI. Mas como você sabe que alguém não mudou sua página da web para transmitir a panela de volta ao seu servidor (ou em outro lugar, usando técnicas JSONP)? A resposta é que você precisa garantir a si mesmo que ninguém irá adulterar sua página de formulários de pagamento.

Como você se garante disso depende de você. Você pode usar as técnicas PCI ou outras técnicas. Isso é uma questão de segurança e auditoria internas do computador.

Padrão Padrão de Segurança de Dados de Pagamento (PA-DSS) Se você vender seu SW a comerciantes, provavelmente estaria dentro do escopo do padrão PA-DSS. Veja o padrão.

PCI é político, não técnico Lembre -se de que o escopo da PCI depende de você. Se você é um comerciante grande o suficiente, também precisará trabalhar com um QSA (avaliador de segurança qualificado) que revisará e operará seu plano de conformidade e escopo de PCI.

Certamente é possível que um QSA possa dizer que, como você controla sua página da web, ele precisa estar no PCI, pois pode ser corrompido por alguém. Mas isso seria um argumento agressivo. Afinal, você pode dizer que todas as páginas da web de qualquer comerciante da Internet precisam estar no PCI, pois qualquer página da web pode ser corrompida para pedir uma panela às pessoas e depois fazer algo ruim com ela. Por outro lado, esse é exatamente o tipo de argumento que o Visa está usando para aumentar o escopo da PCI para franqueadores corporativos. Artigo.

A certificação PCI não é uma desculpa Observe também que as associações de cartas se reservam o direito de expulsá-lo se você tiver uma invasão-mesmo que fosse compatível com PCI. Então, você quer ter certeza de que é um alvo muito mais difícil do que qualquer outra pessoa em seu quarteirão.

Adicionado: Mais sobre o escopo Como você pode ver no exposto, uma questão importante é quais sistemas estão dentro ou fora do escopo da PCI. O Conselho da PCI agora possui um grupo de interesse especial (SIG) examinando toda essa questão do que está e o que está fora do escopo da PCI. E meu palpite é que eles querem que o envelope cresça, não encolhem.

Adicionado: É entre você e seu advogado Seu cenário tem o início do processamento do PAN nos navegadores de seus clientes. O PAN nunca chega aos seus sistemas, nem mesmo por um instante. Portanto, minha interpretação é que você está fora do escopo do Merchant PCI DSS. Mas você é quem assina a declaração de conformidade com PCI, que é um contrato entre você e seu adquirente. Portanto, cabe a você e seu advogado interpretar o padrão PCI DSS, não eu.

Resumindo Você nunca deve armazenar dados do PAN em seus sistemas. Você nem deveria ter seu transporte de seus sistemas. Novos protocolos de gateway de pagamento da Autorize.net e Braintree permitem a técnica sem transmissão. Dependendo do seu volume de transações com cartão de crédito, a conformidade com o PCI varia de uma lista de verificação auto-administrada a um projeto enorme.

Para mais histórias de guerra da PCI, verifique o StoreFrontbackTalk blog e deles Cobertura PCI.

Answer 2

Larry K, a resposta é boa.É, sobretudo, um político/camada de coisa.

Parece que usar um iframe para o lançamento de B para a é uma solução aceita, enquanto usando Ajax com CORS ou JSONP - é um pouco mais questionável, mas ainda assim, pelo menos para alguns grandes jogadores, aceitável.

O Informação Complementar:O PCI DSS E-commerce Diretrizes v2 costuras para dizer que esta solução (direct-pós API) é OK, mas o que você deve tome cuidado para código de segurança (apesar de que o PCI DSS não prescreve nada de concreto que você precisa fazer) - consulte a seção 3.4.3.1 de Terceiros Incorporado APIs Directo com o Post e os relacionados 3.4.3.4 Considerações de Segurança para a Gestão Partilhada de E-commerce Implementações, onde se lê:

Direto de pós-aip:Com o direct-pós abordagem da API, o comerciante é ainda responsável pela página web que é apresentada ao o consumidor e o comerciante hospeda os campos na página de pagamento que aceitar os dados, apenas os dados de portador de cartão é lançada diretamente a partir de o consumidor ao prestador de serviços.Desde as páginas de pagamento são oferecido pelo vendedor, o pagamento páginas são tão seguras quanto a o site do comerciante, e um compromisso do comerciante de sistema levar a um comprometimento de pagamento dos dados do cartão....Especificamente, para todos os cenários acima, o comerciante deve monitor para qualquer evidência de que os sistemas de ter alterado e responder rapidamente para restaurar os sistemas para um estado confiável quando não autorizadas as alterações são detectado.Os comerciantes que adotar essas compartilhado de gestão terceirizada modelos para minimizar os aplicáveis requisitos PCI DSS deve estar ciente de os potenciais riscos que são inerentes a estes tipos de sistema arquitetura.Para minimizar a chance de ataque nestes cenários, os comerciantes devem aplicar extra com a devida diligência para garantir a web a aplicação é desenvolvida de forma segura e sofre de penetração completo o teste.

Por exemplo, o Faixa gateway de pagamento usa o direct-post sobre JSONP desde 2012, em vez de o iframe abordagem, eles têm usado antes.

Por outro lado, WePay também oferece uma mesa de pós-API, mas recomenda iframe para obter livrar completamente do PCI requisitos [WP] (alegando que com o direct-pós API "[..] você ainda é necessário para estar em conformidade com o payment Card Industry Data Security Standards (PCI-DSS), e o pedido de Pagamento Padrões de Segurança de Dados (PA-DSS), sempre que aplicável."(sem especificar o que exatamente "quando aplicável" significa).

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

Answer 3

Recentemente, passei por algum trabalho de conformidade com PCI para nossos servidores, então isso está bem na minha frente. A resposta curta é não.

A conformidade com o PCI exige que cada etapa do caminho através da qual as informações sensíveis passassem atenda aos requisitos da PCI por si só. Algo pode ser seguro, mas não compatível, como você observou em relação à empresa B. porque você já declarou que a empresa B não é compatível com PCI, mas a empresa B está coletando as informações do cartão de crédito por meio de seu próprio site, depois todo o processo, logicamente é não é compatível.

Se um serviço de conformidade com PCI realmente conecta esses pontos e como eles o certificariam como aprovação ou falha, pode ser outra questão.

Answer 4

Independentemente de "tecnicamente" atender aos padrões da PCI (ou não), eu não confiava nessa maneira de fazer as coisas.

Se o formulário estiver em uma página no nome do host de B, B terá acesso completo ao que está nos campos do formulário. (O servidor de B é capaz de enviar ao usuário JavaScript malicioso, se quiser.)

A maneira mais segura de fazê -lo (em termos de proteção do número de cartão de crédito) é colocar o formulário completamente dentro do nome do host do serviço de processamento de pagamento, e não em um nome de host não confiável.

Answer 5

Aqui está o Site PCI

Fundamentalmente, se você puder ver o número do cartão ou qualquer informação de identificação sobre o cartão, precisará atender aos requisitos do PCI. Não tenho certeza se eles são necessariamente um documento legal 'ainda', mas se você for encontrado violação, sua capacidade de processar ou fazer parte de um processo de transação pode ser revogada. Além disso, como comerciante, você assina um contrato sobre sua responsabilidade e opta no processo em que as empresas de cartão de crédito podem multar você. Tudo para o privilégio de aceitar cartões de crédito.

Por diversão aqui está um link (PDF) para a página de 38 'Guia rápido.