Ao alterar o back-end, bloqueie ataques vindos de uploads e entradas do usuário

## Antes de alterar, rastreie os dados externos e encontre caminhos de código parecidos Presuma que arquivos enviados, conteúdo de arquivos compactados, parâmetros de solicitação, manifestos, metadados e identificadores de dispositivos podem ser controlados por invasores, mesmo quando o usuário está autenticado. Antes de alterar um caminho de código sensível: 1. Identifique por onde os dados não confiáveis entram, como são transformados e todas as operações de arquivo, processo, banco de dados, renderização, redirecionamento e rede que eles podem alcançar. 2. Procure implementações relacionadas que executem a mesma operação. Inclua formatos alternativos, visualizações de API e web, fluxos binários e de código-fonte e pontos de chamada legados. 3. Reutilize ou amplie auxiliares de segurança centralizados, em vez de espalhar verificações improvisadas por visualizações e manipuladores. 4. Analise padrões de vulnerabilidades anteriores quando estiverem disponíveis, principalmente correções incompletas que protegeram apenas um caminho. 5. Mantenha as importações e convenções locais consistentes e execute a verificação estática obrigatória e os testes específicos até que sejam concluídos com êxito. Uma correção de segurança está incompleta se um caminho equivalente ainda puder alcançar a operação vulnerável. ## Valide dados de solicitações e uploads na entrada e exija login e permissões Valide a entrada bruta antes que ela se torne um caminho, argumento de comando, valor de consulta, redirecionamento, texto renderizado ou host externo. - Use formulários ou esquemas tipados como a principal camada de validação. - Use campos com opções finitas para parâmetros que tenham um conjunto conhecido de valores válidos. - Coloque a lógica de rejeição específica de cada campo na camada de validação e retorne uma resposta de erro padrão quando a validação falhar. - Valide os identificadores de acordo com o formato exato antes de usá-los em caminhos ou pesquisas. - Verifique os bytes mágicos, os limites de tamanho e as listas de extensões permitidas dos envios; apenas a extensão não é suficiente. - Trate os valores de manifestos e metadados como entradas não confiáveis. Manipuladores sensíveis devem aplicar todos os controles pertinentes: - autenticação; - autorização por função ou permissão; - restrição explícita do método HTTP; - proteção CSRF para alterações de estado iniciadas pelo navegador. Não desative o escape de modelos nem marque conteúdo não confiável como seguro. Ao criar uma saída fora de um modelo com escape automático, codifique o valor de acordo com o contexto de destino. ## Mantenha caminhos de arquivos e a extração de ZIP/TAR dentro da pasta prevista Use duas camadas para os caminhos do sistema de arquivos: 1. Rejeite formatos brutos perigosos, como segmentos de travessia, caminhos absolutos, contornos codificados e caracteres inválidos. 2. Depois de construir o caminho, resolva-o de forma canônica e confirme que ele permanece dentro da raiz prevista. Antes de ler um objeto do sistema de arquivos, rejeite links simbólicos, pipes nomeados, arquivos de dispositivo e outros tipos inesperados quando a operação esperar um arquivo comum. Para extrair TAR: - Prefira um filtro de extração fornecido pelo ambiente de execução, aplicado por item e ciente do tipo, que rejeite travessias, caminhos absolutos, arquivos de dispositivo e links que escapem do destino. - Não dependa de uma verificação baseada apenas no nome ou em `abspath`; ela não resolve links simbólicos. - Se não houver um filtro interno seguro, rejeite links simbólicos e rígidos, resolva o destino com `realpath` e valide imediatamente antes de extrair cada item. - Evite validar todos os itens em lote e depois extraí-los em lote, pois o estado do sistema de arquivos pode mudar entre as duas etapas. Para extrair ZIP: - Valide cada nome de item para detectar travessias antes da extração. - Resolva o destino proposto e confirme que ele está contido na raiz de extração. - Extraia o item somente depois que ele passar pelas duas verificações. Toda proteção que falhar deve interromper a operação insegura com `continue`, `return` ou `raise`. Registrar um aviso sem impedir a execução não constitui um controle de segurança. ## Neutralize a entrada do usuário conforme o uso, como em SQL ou comandos de shell - Passe os argumentos do subprocesso como uma lista. Nunca insira entradas não confiáveis em uma sequência de comando do shell. - Use operações parametrizadas de ORM ou do construtor de consultas. Nunca crie SQL por meio da formatação de texto. - Aplique escape ao conteúdo controlado pelo usuário antes de renderizá-lo fora de um contexto com escape automático. - Higienize formatos ativos, como SVG, antes de exibi-los. - Remova quebras de linha e caracteres de controle dos campos de registro derivados do usuário para evitar injeção em registros. - Gere nomes de arquivo seguros antes de colocá-los nos cabeçalhos de resposta. - Permita apenas destinos relativos de redirecionamento que tenham sido validados. - Antes de realizar solicitações externas, resolva e valide o host, rejeitando endereços de loopback, privados, locais de enlace, multicast e outros intervalos proibidos. Aplique validação específica para cada contexto, em vez de um único higienizador genérico. Um valor seguro para um filtro de banco de dados ainda pode ser inseguro em um nome de arquivo, comando do shell, fragmento HTML, entrada de registro, redirecionamento ou URL. ## Termine com uma checklist de segurança e comprove cada item Para toda alteração que envolva E/S de arquivos ou entradas do usuário, verifique os itens pertinentes: - [ ] A entrada bruta é validada antes da construção do caminho. - [ ] Os caminhos construídos são contidos de forma canônica na raiz prevista. - [ ] Links, pipes e tipos de arquivo inesperados são rejeitados antes da leitura. - [ ] Os itens dos pacotes compactados são validados individualmente antes da extração. - [ ] Os argumentos do shell são passados sem interpolação de texto. - [ ] Os valores renderizados recebem escape e o conteúdo ativo é higienizado. - [ ] Os hosts externos e os destinos de redirecionamento são restringidos. - [ ] Os valores de registro derivados do usuário são higienizados. - [ ] O acesso ao banco de dados usa operações parametrizadas. - [ ] Cada ramo de rejeição impede a operação perigosa. - [ ] Caminhos de código equivalentes recebem a mesma correção. - [ ] Os testes específicos abrangem entradas aceitas, entradas rejeitadas e tentativas de contorno. - [ ] A verificação estática e os testes pertinentes terminam com código de saída zero. Apresente as evidências de cada verificação concluída e identifique qualquer caminho que não tenha sido possível verificar.