Pergunta

Atualmente, eu estou no processo de contratação de um desenvolvedor web que estará trabalhando em um site que processa cartões de crédito. Enquanto ele não tem as credenciais para fazer logon em UI do gateway de pagamento, ele terá acesso à chave de login API e transação uma vez que está embutido no código do aplicativo.

Eu gostaria de estar ciente de todos os "que se" cenários relativos ao tipo de um dano poderia fazer com essa informação. Obviamente, ele pode processar cartões de crédito, mas o dinheiro vai para a conta bancária do proprietário do local, então eu não tenho certeza de quanto dano que poderia causar. Alguém pode pensar em quaisquer outros cenários possíveis?

UPDATE:. O gateway de pagamento a ser utilizado é Authorize.net

Foi útil?

Solução

Será que eles realmente precisam de acesso aos seus locais de produção?

Não guarde a chave no seu código, armazená-lo em seu banco de dados de produção, ou em um arquivo no servidor de produção.

Outras dicas

Algumas boas respostas aqui, vou apenas acrescentar que você provavelmente tem alguns problemas com PCI.
PCI-DSS determina especificamente a separação de tarefas, isolamento de ambientes de produção de dev / teste, proteção de chaves de criptografia de qualquer um que não necessitam dele, e muito mais. Como disse @Matthew Watson, repensar isso, e acesso de produção Grant não faça para os desenvolvedores.

Como um aparte, se ele pode acessar a API diretamente, como você garantir que "o dinheiro vai para a conta bancária do proprietário do local"? para não mencionar o acesso a todos os dados do cartão de crédito ...

Se o desenvolvedor tem acesso aos números de cartão de crédito matérias que podem se tornar um problema maior que o seu site pode ser associado com atividade fraudulenta, assumindo que o desenvolvedor é uma maçã podre. (Eles poderiam redirecionar números de conta, CCV, data de expiração para um outro local, embora este deve ser spottable através de ferramentas de rede e uma revisão de código abrangente.)

A API executar o comando "$ 1,00" (ou "$ X.XX") para verificar se um cartão de crédito pode ser cobrada uma determinada quantia (e retornando assim o resultado para o chamador, como "sim" ou " não")? Se assim for, pode ser usada para automatizar a validação de números de conta de cartão de crédito negociadas na Internet e abuso de um sistema desse tipo poderia levar de volta para você.

Com qualquer gateway Eu tenho trabalhado com, os laços processador de pagamento a chave de API para o específico IP ou intervalo IP do site do comerciante. Com isso dito, a menos que o código malicioso em questão é executado no mesmo servidor que o comerciante (?) -. Não deve haver qualquer preocupação com segurança a esse respeito

Se isto não é o caso para o seu site comercial -. Contatá-los e perguntar se isso é viável

O Gateway de Pagamento permitir a reversão de encargos? Se assim for, há a possibilidade de uma série de golpes que estão sendo executados.

Será que as restituições processo site? Será que alguma vez no futuro?

Se nós estamos falando sobre os usos abomináveis, em seguida, o proprietário do site pode ser investigado se os lotes de compras não autorizadas são feitas. Como isso afetaria você se o proprietário é investigado?

De sua descrição parece que este desenvolvedor terá acesso à cartões de cliente detalhe caso em que a privacidade clientes pode ser comprometida. Você pode considerar a redação do contrato de forma adequada para se certificar de que este ângulo é coberto.

No entanto, o ponto principal é que se você estiver trabalhando em um projeto / informação sensível que é melhor para você encontrar pessoas que você pode confiar. A contratação de um software house para fazer o trabalho você pode economizar um pouco de sono mais tarde.

Em primeiro lugar, é melhor que você nunca armazenar esse tipo de informação em texto simples. Normalmente as pessoas tomam isso como conhecimento de segunda mão para números de cartão de crédito (Infelizmente, só por causa de razões legais), mas qualquer tipo de dados privados que você não quer que os outros com visualização de acesso de banco de dados / código-fonte devem ser criptografados. Você deve armazenar a algum lugar informações da conta em um formato bem criptografado, e você deve fornecer uma conta de teste para seus desenvolvedores para uso em suas estações de trabalho de desenvolvimento. Desta forma, apenas pessoas com acesso ao servidor é capaz de ver até mesmo as informações criptografadas.

Desta forma, você pode ter um banco de dados na estação de trabalho do desenvolvedor com informações API da conta de teste armazenado (espero encriptadas) em seu banco de dados local, mas quando o código é espelhado para o servidor de produção ainda vai usar o, o gateway vivo real informações armazenadas no banco de dados do servidor de produção sem código / configuração extra.

Com isto dito, eu não acho que um programador com detalhes de autenticação da API pode fazer muito. De qualquer maneira, não vale a pena o risco -. Na minha opinião

Espero que isso ajuda.

PS:. Se algo ruim não acabar acontecendo, você sempre pode gerar uma nova chave na interface web em authorize.net depois de ter tomado as precauções para se certificar de que não vai acontecer novamente

No caso específico de Authorize.Net que não seria capaz de fazer créditos para seus próprios cartões de crédito desde Authorize.Net só permite que isso seja feito em operações realizadas por eles nos últimos seis meses. A única exceção sendo permitido se você é concedido uma exceção para as restituições não vinculados. Se você tiver assinado a documentação necessária para isso e alguém tem o seu login API e chave de transação, em seguida, pode então processar créditos para seus próprios cartões de crédito. A única maneira para você pegar este seria para monitorar suas declarações com cuidado.

Para ajudar a atenuar isso, você deve alterar a chave transação imediatamente após a conclusão do trabalho que executam para você. Isso tornaria a chave que têm inúteis após 24 horas.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top