Uma única função, uma ampla superfície de ataque
Imagine o seguinte: você está construindo um microsserviço que processa inscrições de usuários. Em algum ponto do fluxo de trabalho, você corta um endereço de e-mail usando substring_index em SQL para obter o domínio. É simples, curto e funciona bem em staging. Então, na produção, os logs começam a ser preenchidos com nomes completos e domínios de e-mail em texto simples, um vazamento acidental de uma chamada SQL aparentemente inofensiva.
Esse é o problema: índice de substring SQL é uma daquelas funções de string em SQL que parecem seguras até serem usadas no lugar errado. Em aplicativos SaaS multilocatários ou sistemas que lidam com dados confidenciais, o uso indevido pode expor registros privados ou até mesmo permitir a escalada de privilégios sem disparar alertas óbvios. Em ambientes críticos, especialmente plataformas multilocatários, onde uma única consulta pode atender a vários clientes, um pequeno erro de lógica delimitadora em substring_index em SQL pode levar à exposição de dados entre locatários, vazando informações entre conjuntos de dados isolados.
Compreendendo SUBSTRING_INDEX em código real
No MySQL e no MariaDB, a função SQL substring_index recebe três argumentos: a string a ser processada, um delimitador e uma contagem. Ela retorna parte da string antes ou depois desse delimitador.
É comumente usado em consultas de aplicativos para dividir rapidamente valores estruturados armazenados em um único campo, por exemplo, dividindo um e-mail em nome de usuário e domínio, extraindo um subdomínio de uma URL ou isolando um prefixo de uma chave composta. Os desenvolvedores costumam escolher substring_index em SQL em vez da análise sintática do lado do aplicativo porque é concise, evita processamento extra fora do banco de dados e pode ser usado diretamente em filtros, junções e operações de agrupamento.
Exemplo: Extraindo nome de usuário e domínio do e-mail
sql
SELECT
SUBSTRING_INDEX(email, '@', 1) AS username,
SUBSTRING_INDEX(email, '@', -1) AS domain
DE usuários;
Casos de uso comuns para substring_index em SQL incluem:
- Extraindo nomes de usuários para mensagens de boas-vindas
- Validando domínios de e-mail em relação a listas de permissão/recusa
- Agrupando usuários por domínio em consultas analíticas
Porque Índice de substring do SQL é concise rápido, os desenvolvedores costumam usá-lo diretamente em funções de string em SQL para filtragem, validação ou geração de relatórios. O problema começa quando delimitadores ou contagens são dinâmicos e vêm da entrada do usuário.
Onde a segurança falha – Substring_index em SQL
Três padrões principais de risco mudam substring_index em SQL em um passivo, especialmente em sistemas multilocatários ou de alto risco:
Exposição excessiva de dados
Em um banco de dados compartilhado, um único erro de um ou uma contagem de delimitadores errada pode vazar detalhes confidenciais de outros locatários ou usuários não relacionados.
sql
-- Intended: first name only
SELECT SUBSTRING_INDEX(full_name, ' ', 1);
-- Bug: leaks full name and extra fields
SELECT SUBSTRING_INDEX(full_name, ' ', 3);
Em um CRM multilocatário, isso pode revelar nomes completos de clientes de outras empresas no CSV exportado de um locatário.
Entrada nula ou malformada
Se o delimitador estiver faltando ou a entrada for nula, Índice de substring do SQL pode retornar o campo inteiro. Em sistemas críticos, isso pode expor IDs internos, metadados concatenados ou valores de depuração não destinados à visibilidade externa.
Acesso não autorizado em junções ou subconsultas
Em configurações multilocatário, o uso descuidado de funções de string em SQL para escopo de locatário pode quebrar o isolamento:
SELECT o.id, o.amount, t.name
FROM orders o
JOIN tenants t
ON SUBSTRING_INDEX(o.customer_ref, '-', 1) = t.tenant_code;
If referência_do_cliente Se o formato for inconsistente ou controlado pelo usuário, o Locatário A poderá recuperar os pedidos do Locatário B. Em sistemas de pagamento ou plataformas de saúde, isso se torna uma violação direta das políticas de segregação de dados.
Exemplo de risco de vários inquilinos: Imagine uma plataforma de faturamento SaaS onde referência_do_cliente codifica o ID do locatário antes de um hífen (ID DO PEDIDO DO INQUILINO). Se um usuário malicioso enviar uma referência de pedido com o ID de outro locatário, mas com um número de pedido válido, e a associação usar substring_index em SQL sem validação, eles poderiam acessar dados de faturas pertencentes a uma organização completamente diferente.
Vetores de Ataque Reais em CI/CD e código-fonte aberto
Uso indevido de índice de substring SQL não é apenas um erro de desenvolvedor júnior; ele aparece em:
- Consultas ORM com delimitadores dinâmicos
- Procedimentos armazenados em plugins de código aberto
- SQL embutido que concatena parâmetros de solicitação diretamente
Como o código inseguro chega à produção:
Developer writes query using substring_index in sql
↓
Code is committed and pushed to the repository
↓
Automated build runs (no SQL security checks)
↓
Code review focuses on business logic, not string functions in SQL
↓
Changes are merged into the main branch
↓
Application is deployed to production
Sem verificações automatizadas de funções de string inseguras em SQL, esses riscos podem passar despercebidos pela revisão e chegar à produção, potencialmente vazando dados confidenciais desde o primeiro dia.
Detecção em SAST/CI-CD
A maneira mais segura de lidar com riscos substring_index em SQL padrões é bloqueá-los antes da fusão.
As regras de detecção devem capturar:
- Uso de índice de substring SQL com delimitadores ou contagens de parâmetros de solicitação
- Validação de delimitador ausente
Exemplo de regra mínima:
yaml
rules:
- id: mysql-substring-index-dynamic-delimiter
languages: [sql]
message: Avoid SUBSTRING_INDEX with dynamic delimiter or count.
severity: error
Pipeline degrau:
yaml
- name: SAST – SQL rules
run: semgrep --config semgrep-sql.yml --error
Ao escanear funções de string inseguras em SQL durante verificações de RP, você elimina as suposições da revisão de código.
Estratégias de mitigação para desenvolvedores
Detectando o uso arriscado de índice de substring SQL em revisões ou varreduras é bom, mas a verdadeira vantagem é não implementá-lo em primeiro lugar. Muitos incidentes de segurança acontecem porque os desenvolvedores confiam em atalhos conhecidos sem considerar casos extremos.
Veja como evitar problemas ao trabalhar com substring_index em SQL ou funções de string semelhantes em SQL:
Validar posições delimitadoras antes da execução
Não presuma que o delimitador existe e está no lugar certo. Em sistemas multilocatários, um único delimitador inesperado em um identificador pode abrir acesso aos dados de outro locatário.
sql
SELECT
CASE
WHEN LOCATE('@', email) > 0
THEN SUBSTRING_INDEX(email, '@', 1)
ELSE NULL
END AS username
FROM users;
- Verifique o comprimento de saída esperado
Defina limites seguros. Se o resultado da substring for muito curto ou muito longo, trate-o como inválido. - Higienize e codifique os dados antes do uso
Remova delimitadores não autorizados da entrada fornecida pelo usuário antes mesmo que ela chegue ao SQL - Evitar substring_index em SQL em lógica crítica de segurança
Nunca o utilize para verificações de permissão, isolamento de inquilinos ou qualquer coisa que controle o acesso a dados confidenciais. A análise sintática não é um limite de segurança. - Mova a análise para a camada de aplicação. A lógica do lado do aplicativo oferece melhor controle sobre validação, tratamento de erros e testes unitários.
python
def safe_split_email(email):
if '@' not in email:
raise ValueError("Invalid email")
username, domain = email.split('@', 1)
if '.' not in domain:
raise ValueError("Invalid domain")
return username, domain
Ao tratar funções de string em SQL como caminhos de código não confiáveis, você reduz o raio de alcance de qualquer erro lógico.
Integração com ferramentas de segurança
Mesmo equipes qualificadas não podem confiar apenas em revisões manuais; padrões arriscados, como inseguros índice de substring SQL o uso pode passar despercebido, especialmente em grandes bases de código ou ao lidar com código de terceiros.
Por que integrar ferramentas como o Xygeni:
- Abrange código de código aberto e proprietário: garantir que vulnerabilidades não estejam escondidas em pacotes de fornecedores ou módulos legados.
- Detecta padrões inseguros em scripts SQL e código de aplicativo: encontrando substring_index em SQL uso indevido, mesmo quando incorporado em strings dentro de Python, Java ou Node.js.
- Integra-se diretamente em CI/CD pipelines: as compilações falham automaticamente se não forem seguras funções de string em SQL são detectados.
- Fornece aconselhamento prático sobre remediação: mostrando aos desenvolvedores exatamente qual parte da consulta é arriscada, por que e como corrigi-la.
Exemplo de fluxo de trabalho com Xygeni em CI/CD segurança:
Source → Commit → Build
→ SQL Scan (Xygeni)
→ Fail build if violations found
→ Remediation & re-scan
→ Merge & Deploy
Varredura contínua antes da implantação é crítico, garante que os usos arriscados de índice_de_substring_sql são detectadas não apenas durante o desenvolvimento inicial, mas também em atualizações, refatorações e alterações de dependências posteriores. Essa abordagem proativa significa que as vulnerabilidades são eliminadas antes mesmo de chegarem à produção.
Lições finais para desenvolvedores – Sobre substring_index em SQL
Aqui está a linha de fundo:
- índice de substring SQL não é inerentemente ruim, mas o mau uso o transforma em um vazamento silencioso de dados.
- Cada substring_index em SQL uma chamada em um caminho sensível à segurança deve ser tratada como suspeita até que seja comprovada sua segurança.
- Todas as funções de string em SQL podem ser perigosas em contextos onde limites de dados ou permissões são importantes; sempre trate-as como potencialmente perigosas em ambientes sensíveis, mesmo que pareçam simples ou inofensivas.
Próximas etapas práticas para equipes de desenvolvimento:
- Audite sua base de código para qualquer uso de índice de substring SQL em junções, subconsultas ou lógica de controle de acesso.
- Adicione SAST regras para detectar delimitadores dinâmicos e entradas não validadas em funções de string em SQL.
- Deslocar a análise para a camada de aplicação qualquer lugar possível.
- Executar varreduras contínuas com ferramentas como o Xygeni para detectar uso inseguro antes da implantação.
Segurança não significa apenas corrigir falhas após o fato; significa incorporar a prevenção ao fluxo de trabalho. Se você tratar índice de substring SQL e outras funções de string em SQL com o mesmo cuidado que a entrada bruta do usuário, você evitará transformar um auxiliar conveniente na linha mais perigosa da sua consulta.
