-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibilidade de Fraude nos Pagamentos #8
Comments
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. |
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...
The text was updated successfully, but these errors were encountered: