Prevenção de injeção de comandos e argumentos

O Bash é uma poderosa linguagem de integração — ele passa texto diretamente ao núcleo do sistema, a outros programas e a subshells. Esse poder se torna uma vulnerabilidade no momento em que uma entrada não confiável chega a um comando sem validação ou sem aspas.

Duas causas fundamentais estão por trás de praticamente todas as injeções no Bash:

• Divisão de palavras: variáveis sem aspas são divididas nos espaços em branco (IFS), transformando um único valor lógico em vários tokens do shell.
• Expansão de curingas: caracteres como *, ? e [ são expandidos pelo shell antes mesmo de o comando ser executado.

Um invasor que controle um nome de arquivo, nome de usuário, parâmetro de URL ou variável de ambiente pode explorar ambos os mecanismos para executar comandos arbitrários, ler arquivos ou elevar privilégios.

Esta lição mostra exatamente como essas vulnerabilidades surgem e — mais importante — como eliminá-las com o uso correto de aspas, validação de entrada e passagem de argumentos baseada em matrizes.

Quando o Bash encontra uma variável sem aspas, ele divide o valor em qualquer caractere listado em $IFS (padrão: espaço, tabulação, quebra de linha). O que parece ser um único argumento torna-se vários.

Execute o script abaixo e observe como um nome de arquivo com um espaço se transforma em dois argumentos separados para rm.

A defesa mais simples e eficaz contra a divisão de palavras é sempre colocar entre aspas duplas as expansões de variáveis.

• "$var" — expande para exatamente um token, preservando espaços, tabulações e quebras de linha.
• 'literal' — aspas simples: nenhuma expansão é realizada, sendo úteis para strings fixas.
• Nunca use $var sem aspas, a menos que você precise explicitamente da divisão de palavras e da expansão de curingas.

O script abaixo mostra a versão segura do exemplo anterior.

Variáveis sem aspas também estão sujeitas à expansão de caminhos (curingas). Se a entrada controlada pelo usuário contiver * ou ?, o Bash a expande de acordo com o sistema de arquivos antes de o comando ser executado.

Um vetor de ataque clássico: um formulário web define PATTERN=* e o script executa cp $PATTERN /tmp/leak/ — copiando todos os arquivos do diretório atual.

A correção é idêntica: coloque a variável entre aspas duplas. Uma "$PATTERN" entre aspas é passada literalmente; o shell nunca realiza expansão de curingas sobre ela.

Scripts que aceitam argumentos do chamador são alvos prioritários de injeção. Cada parâmetro posicional ($1, $2, ...) deve estar entre aspas em todos os locais onde for usado.

Um padrão particularmente perigoso é passar $@ ou $* sem aspas para outro comando:

• "$@" — expande cada parâmetro posicional como uma palavra separada e individualmente entre aspas. Use sempre esta forma.
• $@ ou $* sem aspas — ficam sujeitos à divisão de palavras e à expansão de curingas.
• "$*" — reúne todos os parâmetros em uma única palavra, o que raramente é o desejado.

eval analisa novamente seu argumento como código do shell. Qualquer dado não confiável que chegue a eval pode executar comandos arbitrários.

Padrões perigosos comuns:

• eval "$user_input"
• eval echo \$$var (consulta indireta de variável)
• Passar dados do usuário por bash -c "$input"

Regra: nunca passe entradas não confiáveis para eval ou bash -c. Use alternativas seguras do Bash:

• Expansão indireta: ${!varname} em vez de eval echo \$$varname
• Matrizes associativas para consultas dinâmicas de chave-valor
• Funções em vez de strings de comandos geradas

Rejeitar caracteres conhecidos como perigosos (uma lista de bloqueio) é frágil — os invasores encontram codificações ou caracteres que você esqueceu. Em vez disso, use uma lista de permissões: aceite apenas os caracteres que você sabe serem seguros.

Estratégias de lista de permissões no Bash:

• Correspondência com expressão regular: [[ "$input" =~ ^[A-Za-z0-9_-]+$ ]]
• Correspondência com padrão: case "$input" in [A-Za-z0-9]*) ... ;; esac
• Verificação de enumeração: compare com um conjunto fixo de valores válidos

Valide na fronteira — assim que a entrada entrar no script — antes que ela toque qualquer comando.

Quando precisar criar um comando dinamicamente — adicionando sinalizadores condicionalmente ou percorrendo entradas em um loop — use uma matriz do Bash em vez de concatenar strings.

A concatenação de strings elimina toda a estrutura; uma matriz do Bash preserva cada argumento como um elemento distinto, sem uma nova análise pelo shell.

• Declare: args=()
• Adicione: args+=(--flag "$value")
• Execute: command "${args[@]}"

"${args[@]}" expande cada elemento como uma palavra separada e individualmente entre aspas — exatamente como "$@".

Até mesmo um argumento colocado corretamente entre aspas pode ser interpretado incorretamente como um sinalizador de opção se começar com -. Considere rm "$file" quando file='-rf .': as aspas protegem contra a divisão de palavras, mas o rm ainda interpreta -rf como sinalizadores.

A convenção POSIX -- indica o fim das opções para a maioria dos utilitários GNU/BSD. Tudo após -- é tratado como argumento posicional, nunca como sinalizador.

Quando scripts Bash invocam interfaces de linha de comando de bancos de dados (psql, mysql), usam curl com URLs fornecidas pelo usuário ou recorrem a ferramentas semelhantes, aplicam-se duas camadas adicionais:

• Consultas parametrizadas: nunca incorpore dados do usuário em strings SQL. Passe os valores por meio de -v no psql ou de --data-urlencode no curl.
• Separe dados de código: use printf com uma string de formato literal; nunca permita que a entrada do usuário seja a string de formato.

O exemplo abaixo consulta o PostgreSQL com segurança, mantendo o valor fornecido pelo usuário completamente fora do texto SQL.

Um script Bash seguro, pronto para produção, combina todas as técnicas desta lição em uma defesa consistente e em camadas. Veja um modelo mínimo, mas completo, de script protegido:

• set -euo pipefail — encerra em caso de erro, trata variáveis não definidas como erros e propaga falhas em pipelines.
• Valide na entrada — use uma lista de permissões para cada entrada externa antes que ela toque qualquer comando.
• Coloque tudo entre aspas — "$var", "$@", "${array[@]}" — sem exceções, a menos que você precise da divisão.
• Use matrizes para construir comandos dinâmicos.
• Prefixe os argumentos com -- ao passar nomes de arquivos ou strings fornecidos pelo usuário.
• Nunca use eval com dados não confiáveis; prefira ${!var} para consultas indiretas.
• Restrinja as permissões — execute scripts com os privilégios mínimos necessários; evite sudo em scripts que aceitem entradas do usuário.

Teste sua compreensão dos principais conceitos desta lição.

Você estudou o conjunto completo de ferramentas defensivas para lidar com entradas do Bash com segurança:

• Divisão de palavras e expansão de curingas são os mecanismos fundamentais que transformam variáveis inseguras em vetores de injeção.
• Coloque todas as variáveis entre aspas duplas ("$var", "$@", "${arr[@]}") para neutralizar ambas as ameaças.
• Use "$@" — nunca $@ ou $* sem aspas — ao encaminhar argumentos.
• Prefixe os nomes de arquivos fornecidos pelo usuário com -- para evitar injeção de sinalizadores.
• Use uma lista de permissões para todas as entradas externas, com uma verificação por expressão regular ([[ $v =~ ^pattern$ ]]), antes que elas cheguem a qualquer comando.
• Crie comandos dinâmicos com matrizes (cmd+=() → "${cmd[@]}"), nunca por concatenação de strings.
• Elimine eval e bash -c "$input"; use ${!varname} para uma expansão indireta segura.
• Sempre inicie os scripts com set -euo pipefail e IFS=$'\n\t' para estabelecer uma proteção básica.

Aplicadas de forma consistente desde a primeira linha de cada script, essas práticas reduzem quase a zero a superfície de ataque do Bash para vulnerabilidades da classe de injeção.