gerencianet / gn-api-sdk-php

SDK em PHP integrada às APIs da Gerencianet preparada para emissão de cobranças Pix com QR Code e Pix Copia e Cola, split/divisão de Pix, boletos, carnês, cartão de crédito, assinatura, link de pagamento, marketplance, iniciação de pagamento Pix via Open Finance, pagamento de boletos, dentre outras funcionalidades.
https://dev.gerencianet.com.br/docs/instalacao-sdk-php
MIT License
86 stars 45 forks source link

Possibilidade de Fraude nos Pagamentos #8

Closed chinnonsantos closed 8 years ago

chinnonsantos commented 8 years ago

Olá, estou analisando e fazendo a implementação da nova API GN e identifiquei uma possibilidade de burlar o esquema de recebimento de qualquer meio de pagamento que for gerado no site, devido a falta de um relacionamento entre o Client ID, Client Secret e o Domínio quer ira roda a API.

Hoje quando eu crio uma nova Aplicação para gerar um novo CID e CS no painel de APIs da GN eu não informo nenhum domínio do qual rodará a API, é deveria ter essa informação, somente para geração de CID e CS da Produção, no Playground deve continuar sem mesmo para ter a possibilidade de testar a Aplicação em qualquer lugar, porem a produção tem que esta limitada a executar somente em um único domínio.

Uma forma de burlar isso e eu identificar um site que usa os sistema de pagamento da GerenciaNet, e descobri se eles utilizam o banco de dados para armazenar o CID e CS ou se estão salvando essa informação em um arquivo .json, nem todos os desenvolvedores fazem restrição de acesso externo aos arquivos .json da hospedagem e alguns em algum momento recebe uma invasão em sua hospedagem.

Tendo conhecimento do local de armazenamento dessas informações o cracker poderia simplesmente substituir pelo CID e SC dele e todo pagamento processado será creditado na conta GN do cracker, sem que o real destinatário do crédito perceba até que seus clientes comecem a reclamar que estão pagaram e não esta sendo confirmado seus pagamentos. até lá o dinheiro já foi tirando da conta GN e cracker desaparecido do mapa...

Se existir uma relação entre os CIDs, SCs e o domínio da aplicação isso jamais poderia acontecer tendo em vista que o cracker teria que invadir a conta GN do proprietário para trocar o domínio, isso é muito menos provável de conseguir.

Eu trabalho também com outras APIs, e se não me engano vi esse nível de segurança em uma delas.

Parece também que existe essa API para Android e iOS, não vi como funciona, mas já desenvolvi projetos nas duas plataformas e acredito que para esse esquema se tornar válido para elas tb, o APP deveria comunicar com uma WebService para processar o pagamento, e seria o domínio dessa WebService que estaria relacionado aos CIDs e SCs deixando o APP mesmo só como um intermediador, depois com mais tempo vou da uma olhada nessa API pra Android e iOS e ver como funciona.

Eu já trabalhei uma agencia que tinha um gerente preguiçoso que não atualizava as versões dos WordPress instalados nas sub-contas de um dedicado, só no tempo que trabalhei lá vi esse dedicado ser hackeado 3 vezes por causa das falhas de segurança não corrigida por falta de atualizar as versões, mais de 200 sites prejudicados, em algum deles os cara trocava arquivo e deixava mensagens, com isso já da pra percebe que tiveram acesso ao FTP das contas e provavelmente os bancos de dados, imagine que desses 200 sites, 50 fossem lojas virtuais rodando a API da GN, o cara substituiria os CIDs e SCs e por alguns dias iria faturar bem nas costas dos outros...

franciscotfmc commented 8 years ago

Boa noite @chinnonsantos!

Primeiramente agradecemos o seu feedback. É sempre bom termos oportunidades de esclarecer este tipo de situação.

Nós chegamos a considerar a verificação de domínios na API da Gerencianet, porém isso inviabilizaria a utilização da API para alguns de nossos clientes que não implementam DNS reverso, ou mesmo para outros que estão atrás de uma hospedagem compartilhada.

É importante deixar claro que em momento algum esta questão de não fixar domínios às credenciais é uma brecha de segurança. O armazenamento seguro destes dados é de inteira responsabilidade do integrador.

Supondo que alguém consiga acessar o seu servidor e trocar as suas credenciais por outras, isso caracteriza uma falha de segurança do seu servidor e não da Gerencianet. Mesmo assim, o máximo que o cracker conseguiria fazer é gerar cobranças para uma conta diferente da sua, ou seja, não conseguiria NUNCA retirar o dinheiro da sua conta ou receber pagamentos em seu nome. Nessa situação, os e-mails e boletos emitidos pela Gerencianet teriam as informações do cracker.

Supondo agora que o cracker descubra as suas credenciais, porque elas não foram armazenadas de forma segura, o que ele poderá fazer é gerar cobranças para sua conta. Quando estas cobranças forem pagas, o dinheiro também irá para sua conta. Nesse cenário ele também NÃO consegue retirar o seu dinheiro.

Nós nunca orientamos ninguém a divulgar as credenciais, tampouco utilizá-las em qualquer frontend como no javascript do checkout transparente ou nas SDK's para mobile de Android/iOS. Vale ressaltar que essas SDK's fazem o papel do script de checkout, que é simplesmente gerar um payment token. Em nenhuma delas se faz necessária a utilização das credenciais de sua aplicação.

Qualquer dúvida, você pode entrar em contato com o suporte técnico da Gerencianet através do e-mail suportetecnico@gerencianet.com.br ou criar um ticket na nossa central de ajuda.