Os Códigos que a Página Precisava Conhecer: O Que uma Checagem no Navegador Precisa Saber
O desafio
O checkout da Brightloom confere seu código de desconto no navegador antes de incomodar o servidor, para que um cliente que digite errado seja avisado na hora. Para isso ele precisa conhecer todos os códigos, e para conhecer todos os códigos precisa receber todos eles. O banner anuncia um. A página carrega cinco, com suas datas e seus percentuais, e um deles está válido hoje e nunca deveria ter saído do depósito. Diga qual.
O que você vai aprender
- Reconhecer que a validação no lado do cliente exige enviar os dados usados na validação
- Ler uma lista de registros compactada em um campo oculto de formulário
- Eliminar candidatos usando datas fornecidas pela própria página
- Identificar qual entrada não tem checagem de elegibilidade no servidor, e por quê
- Explicar por que um campo oculto é uma publicação, não um segredo
Habilidades testadas
Pré-requisitos
- O que são um formulário HTML e um input oculto
Como funciona
Validar a entrada no navegador é bom para o usuário. Um cliente que digita o código errado deve ser avisado na hora, em vez de esperar uma ida e volta ao servidor. O problema é estrutural, não acidental: para checar uma resposta, o verificador precisa conhecer a resposta, então uma página capaz de dizer que um código é inválido recebeu todos os códigos válidos.
Isso vale para qualquer checagem no lado do cliente desse tipo. Tipos de arquivo permitidos, domínios de e-mail bloqueados, valores mínimos de pedido por região, quais recursos pertencem a qual plano: se a página decide, a página sabe. Esconder o campo não muda nada. Um input oculto não é criptografado, não é somente leitura e não é privado, ele simplesmente não é exibido na tela, e Ver código-fonte o mostra por completo.
A segunda metade é a que custa dinheiro. O comentário explica que os códigos de cliente são reconferidos contra o pedido no lado do servidor, enquanto os códigos de funcionário são aceitos só pelo código, porque os coletores da loja não têm cliente para conferir. Essa exceção é defensável no depósito e indefensável em um checkout público, e enviar a lista para o cliente web foi o que conectou as duas coisas.
Erros comuns
- Responder AUTUMN15. Está ativo, e está anunciado no banner no topo da página. Nada foi exposto.
- Responder YULE30. Quarenta não é o maior número aqui, trinta é o segundo maior, mas a janela dele começa em 1º de dezembro.
- Responder SPRING10. Expirou em 30 de junho.
- Responder WELCOME5. Está dentro da janela, mas a página registra
customer_typecomo returning, e a API confere os códigos de cliente contra o pedido. - Usar seu próprio relógio. A página envia a data do servidor em um campo oculto. Use-a.
Como se proteger
Confira no servidor, e dê ao cliente somente o que ele precisa para perguntar.
- Valide o código com uma requisição. Se o feedback instantâneo importa, envie o código digitado para um endpoint que responda válido ou não para este pedido, e não retorne mais nada.
- Se um pré-filtro é realmente necessário, envie só os códigos que já são públicos. Códigos internos e de funcionário nunca deveriam chegar a um cliente web, que é exatamente o que o ticket mencionado no comentário diz.
- Remova a exceção, não a exposição. Um código de funcionário aceito só pelo código é uma credencial bearer; vincule-o a uma sessão autenticada de funcionário ou a um terminal registrado.
- Limite a taxa de tentativas de resgate e alerte quando um código for usado fora do canal ao qual pertence. Um código de depósito resgatado no checkout público é um alerta de uma linha.