Segurança dos pagamentos: PCI e fraude

Módulo 6: Gestão e segurança · Tempo de leitura: 11 minutos

Objetivo de aprendizagem: No final desta lição, saberá explicar porque é que uma loja nunca trata ela própria dados de cartão, o que significam o PCI DSS e o SAQ A para uma pequena loja, como proteger a página de finalização de compra e como reconhecer e limitar a fraude e o card testing.

Conceitos-chave: PCI DSS, dados de cartão, fornecedor de pagamentos, redirecionamento para a página de pagamento, formulário de pagamento incorporado (iframe), SAQ A, scripts na página de finalização de compra, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, estorno (chargeback), risco de fraude

Os dados de cartão não pertencem à sua loja

Um número de cartão de crédito, a data de validade e o código de segurança valem ouro para os criminosos. Quem os guarda ou transmite fica abrangido pelo PCI DSS (Payment Card Industry Data Security Standard), a norma de segurança das empresas de cartões. A versão atual é a v4.0.1. Para uma empresa que trata ela própria dados de cartão, isso representa um conjunto considerável de requisitos: segmentação da rede, registos, análises, testes por uma entidade reconhecida.

Uma pequena loja não quer estar nessa situação, nem precisa. A regra fixa: os dados de cartão nunca entram na sua loja. O cliente introduz-os junto do seu fornecedor de pagamentos (Mollie, Stripe, PayPal, WooPayments ou outro, lição 4.4). Depois, a loja apenas recebe a informação: pago ou não, com uma referência. Nenhum número de cartão, nenhum código. Isso significa também:

• nunca criar um campo de formulário próprio para números de cartão, nem sequer "só para uma encomenda por telefone";
• nunca aceitar dados de cartão por e-mail, chat ou telefone e registá-los numa nota da encomenda;
• não utilizar nenhum plugin que guarde dados de cartão na sua própria base de dados.

Redirecionar ou incorporar: SAQ A

As pequenas lojas demonstram que cumprem o PCI DSS com um SAQ (Self-Assessment Questionnaire, um questionário). Por vezes, o seu fornecedor de pagamentos pede-o. O mais leve é o SAQ A, para lojas que externalizam totalmente o pagamento. Há duas formas de isto funcionar numa loja:

1. Redirecionar. Depois de "encomendar", o cliente vai para a página de pagamento do fornecedor e depois regressa. A loja nunca vê os dados de cartão, nem sequer a página onde são introduzidos.
2. Formulário incorporado. O campo de pagamento está na sua página de finalização de compra, mas é um iframe (um fragmento de página) do fornecedor. Os dados de cartão vão diretamente do navegador para o fornecedor.

Desde 31 de março de 2025 aplica-se uma nova versão do SAQ A. Esta contém uma condição que afeta sobretudo a segunda forma: quem utiliza um formulário incorporado tem de confirmar que o seu site não é vulnerável a ataques com scripts que possam afetar o sistema de pagamento. O contexto é o e-skimming: um script malicioso na sua página de finalização de compra que lê o que o cliente escreve, ou que sobrepõe um campo de pagamento falso ao verdadeiro. Quem redireciona para a página do fornecedor não está abrangido por essa condição. Pergunte ao seu fornecedor de pagamentos que SAQ se aplica à sua integração; ele sabe exatamente.

O que deve fazer em qualquer caso:

• Mantenha a página de finalização de compra despojada. Qualquer script nessa página pode, em princípio, ler o que é escrito: widgets de chat, gestores de etiquetas (tag managers), píxeis de publicidade, ferramentas de testes A/B. Carregue na página de finalização de compra apenas o necessário para o pagamento. Um tag manager nessa página é uma porta através da qual qualquer pessoa com acesso a essa conta pode adicionar scripts.
• Poucos plugins, e atualizados (lição 6.2). A maior parte do e-skimming em WordPress entra através de uma falha num plugin ou de uma palavra-passe de administrador roubada.
• Uma Content-Security-Policy (um cabeçalho que indica de que domínios podem vir scripts) limita os danos se, ainda assim, algo entrar. É trabalho para alguém que o saiba testar; uma CSP errada estraga o seu botão de pagamento.

https e HSTS na página de finalização de compra

Que toda a sua loja funcione através de https é evidente (curso de WordPress, lição 3.1). Para a página de finalização de compra, juntam-se duas coisas:

• o http tem de redirecionar de imediato para https, com um redirecionamento permanente (301 ou 308). Um cliente que alguma vez escreva http://shop.example.com/afrekenen/ não pode receber uma página não cifrada.
• O HSTS (HTTP Strict Transport Security) é um cabeçalho com o qual instrui o navegador a abrir o seu site, durante algum tempo, apenas através de https. Assim evita que alguém numa rede wi-fi aberta intercete o primeiro pedido não cifrado. Um max-age de pelo menos 180 dias é um mínimo habitual. Ative o HSTS apenas quando tudo, incluindo os subdomínios que abranger, funcionar através de https: um navegador que tenha visto o HSTS recusa depois o http. O artigo KB 6752 explica como o configurar.

Conteúdo misto (um script ou uma folha de estilos via http numa página https) na página de finalização de compra é especialmente perigoso: é precisamente um ficheiro desses que pode ser substituído pelo caminho.

Card testing

No card testing, os criminosos usam a sua loja para experimentar números de cartão roubados. Fazem automaticamente centenas de pequenas encomendas. Cada pagamento bem-sucedido diz-lhes que um cartão funciona. O resultado para si é um monte de encomendas falhadas, custos por transação, estornos e, no pior dos casos, um fornecedor de pagamentos que bloqueia a sua conta.

Como reconhecer: muitas encomendas em pouco tempo, frequentemente do mesmo produto barato, com nomes diferentes mas moradas iguais ou estranhas, e muitas com o estado Falhada.

Como limitar:

• Rate limiting (um limite ao número de pedidos por período de tempo). A Store API do WooCommerce, utilizada pelos blocos do carrinho e da finalização de compra, tem rate limiting incorporado, mas este está desativado por predefinição. Em WooCommerce > Configurações > Avançado > Funcionalidades pode ativar "Rate limiting Checkout block and Store API" para a realização de encomendas. Com código (um filtro) pode definir o limite; a predefinição é de 25 pedidos por 10 segundos e só contam as encomendas e outras ações de escrita. Se a sua loja estiver atrás de um proxy ou CDN, o suporte de proxy tem de estar ativo; caso contrário, todos os visitantes contam como um só.
• Um captcha ou uma barreira semelhante na finalização da compra. O próprio WooCommerce afirma que o rate limiting e o captcha funcionam melhor em conjunto: os atacantes mudam frequentemente de endereço IP.
• As configurações do seu fornecedor de pagamentos. Os fornecedores têm os seus próprios filtros de fraude e limites. Ative-os e veja o que reportam.
• O 3-D Secure (a confirmação adicional na aplicação do banco, parte da autenticação forte do cliente na UE) dificulta a vida aos criminosos e, em caso de litígio, transfere frequentemente a responsabilidade para o banco do titular do cartão.

Outras fraudes

Nem toda a fraude é automatizada. Sinais que, somados, justificam esperar um pouco antes de enviar:

• morada de faturação e morada de entrega em países diferentes, ou uma morada de entrega num serviço de reencaminhamento;
• uma primeira encomenda apenas com produtos caros e fáceis de revender, com envio urgente;
• várias tentativas com cartões diferentes;
• um cliente que, depois de pagar, pede para enviar para outra morada.

Um estorno (chargeback) é a anulação de um pagamento com cartão pelo banco do cliente. Perde o montante, muitas vezes com custos, e o produto já foi. Por isso, guarde provas de envio e de entrega. Um pagamento iDEAL (Países Baixos) não podia até agora ser anulado desta forma; como funciona com a Wero, saberá através do seu fornecedor de pagamentos (lição 4.4). Em Portugal, os métodos de pagamento habituais são MB WAY, referência Multibanco, cartão e PayPal; pergunte também ao seu fornecedor como funcionam as contestações em cada um deles.

Resumo

• Os dados de cartão nunca entram na sua loja: nem em formulários, nem em notas, nem em e-mails. É o fornecedor de pagamentos que os trata.
• Redirecionar para a página de pagamento ou usar um campo incorporado do fornecedor mantém-no no questionário PCI mais leve (SAQ A); com um campo incorporado, a sua página de finalização de compra tem de estar protegida contra ataques com scripts.
• Mantenha a página de finalização de compra despojada, através de https com um 301 a partir de http e com HSTS de pelo menos 180 dias.
• O card testing limita-se com rate limiting (desativado por predefinição), um captcha e os filtros do seu fornecedor.
• Esteja atento a sinais de fraude e guarde provas de entrega contra estornos.

Questionário

Exercício

Exercício A6.3: A sua página de finalização de compra é segura? Introduza o endereço da sua loja e o endereço da sua página de finalização de compra. O programa verifica o certificado, pede a página de finalização de compra via http (sem seguir redirecionamentos) e via https (com o carrinho vazio, nada é encomendado). Verde se o certificado for válido, se o http redirecionar para https com 301 ou 308, se o cabeçalho Strict-Transport-Security tiver um max-age de pelo menos 180 dias, se não houver conteúdo misto e se, no máximo, cinco outros domínios carregarem scripts na página (o programa mostra-os). Laranja se não houver HSTS ou se for demasiado curto, se houver um redirecionamento temporário (302 ou 307), mais de cinco domínios de scripts ou um tag manager, ou um campo de número de cartão no HTML da própria loja em vez de no fornecedor. Vermelho se o https ou o certificado não estiverem corretos, se o http não redirecionar, ou se scripts ou folhas de estilos forem carregados via http. Nunca guarde dados de cartão. Esta verificação só vê o que está na página sem carrinho.

Pergunta para si (não verificada): o seu plugin de pagamento redireciona para o fornecedor, ou o campo de pagamento está na sua página? Que SAQ diz o seu fornecedor que se aplica?

Um visto verde significa que esta verificação está correta neste momento, não que a sua loja é segura.

Para saber mais

Os passos num painel aplicam-se ao WebOké; noutros fornecedores funciona de forma semelhante.

• Curso gratuito de WordPress 3.1: https e o certificado
• HSTS e cabeçalhos de segurança para o seu website
• Redirecionar obrigatoriamente os visitantes para https
• Manual DirectAdmin 6.4: Enviar sempre os visitantes para https
• Curso gratuito Seguro online para empresários 4.2: O seu site: https, HSTS e cabeçalhos de segurança
• Atualizações do SAQ A (PCI Security Standards Council, em inglês): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting para a Store API (developer.woocommerce.com, em inglês): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, em inglês): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/
• Segurança de pagamentos na sua loja online: PCI, card testing e o que o seu fornecedor de alojamento faz