Não costumo falar de notícias e eventos atuais aqui, mas estou abrindo uma exceção para o Os 25 erros de programação mais perigosos da CWE/SANS lista. Essa lista é importante e merece um público amplo, por isso estou repetindo-a aqui, juntamente com um breve resumo editado à mão de cada erro.
Se o senhor trabalha com software de alguma forma, pelo menos dê uma olhada nessa lista. Eu o encorajo a clicar para obter mais detalhes sobre qualquer coisa com a qual não esteja familiarizado ou que desperte seu interesse.
- Validação inadequada de entrada
Certifique-se de que sua entrada seja válida. Se o senhor estiver esperando um número, ele não deve conter letras. O preço de um carro novo também não deve ser um dólar. A validação incorreta da entrada pode levar a vulnerabilidades quando os invasores podem modificar suas entradas de maneiras inesperadas. Muitas das vulnerabilidades mais comuns hoje em dia podem ser eliminadas, ou pelo menos reduzidas, com uma validação de entrada rigorosa.
- Codificação inadequada ou escape de saída
A codificação insuficiente da saída é a raiz da maioria dos ataques baseados em injeção. Um invasor pode modificar os comandos que o senhor pretende enviar a outros componentes, o que pode levar a um comprometimento total do seu aplicativo, sem falar na exposição dos outros componentes a explorações que o invasor não conseguiria iniciar diretamente. Quando seu programa gerar saídas para outros componentes na forma de mensagens estruturadas, como consultas ou solicitações, certifique-se de separar as informações de controle e os metadados dos dados reais.
- Falha na preservação da estrutura da consulta SQL (também conhecido como ‘SQL Injection’)
Se os invasores puderem influenciar o SQL que o senhor envia ao seu banco de dados, eles poderão modificar as consultas para roubar, corromper ou alterar os dados subjacentes. Se o senhor usar consultas SQL em controles de segurança, como autenticação, os invasores poderão alterar a lógica dessas consultas para contornar a segurança.
- Falha na preservação da estrutura da página da Web (também conhecido como ‘Cross-site Scripting’)
O XSS (Cross-site scripting) é o resultado da combinação da natureza sem estado do HTTP, da mistura de dados e scripts em HTML, da passagem de muitos dados entre sites da Web, de diversos esquemas de codificação e de navegadores da Web repletos de recursos. Se o senhor não for cuidadoso, os invasores poderão injetar Javascript ou outro conteúdo executável pelo navegador em uma página da Web gerada pelo seu aplicativo. Sua página da Web é então acessada por outros usuários, cujos navegadores executam esse script mal-intencionado como se tivesse vindo do senhor – porque, afinal, ele fez veio do senhor! De repente, seu site está servindo um código que não foi escrito pelo senhor. O invasor pode usar uma variedade de técnicas para obter a entrada diretamente no seu servidor ou usar uma vítima involuntária como intermediário.
- Falha na preservação da estrutura de comando do sistema operacional (também conhecido como ‘Injeção de comando do sistema operacional’)
Seu software atua como uma ponte entre um estranho na rede e os componentes internos do seu sistema operacional. Quando o senhor invoca outro programa no sistema operacional e permite que entradas não confiáveis sejam inseridas na cadeia de comandos, está convidando invasores para o seu sistema operacional.
- Transmissão de informações confidenciais em texto claro
As informações enviadas por uma rede atravessam muitos nós diferentes em trânsito até o destino final. Se o seu software enviar dados confidenciais e privados ou credenciais de autenticação, tome cuidado: os invasores podem detectá-los diretamente do fio. Tudo o que eles precisam fazer é controlar um nó ao longo do caminho até o destino final, qualquer nó dentro das mesmas redes desses nós de trânsito ou conectar-se a uma interface disponível. Ofuscar o tráfego usando esquemas como Base64 e codificação de URL não oferece nenhuma proteção.
- Falsificação de solicitação entre sites (CSRF)
A falsificação de solicitação entre sites é como aceitar um pacote de um estranho, exceto que o invasor engana o usuário para que ele ative um “pacote” de solicitação HTTP que vai para o seu site. O usuário pode nem mesmo estar ciente de que a solicitação está sendo enviada, mas quando a solicitação chega ao seu servidor, parece que veio do usuário, não do invasor. O invasor se disfarçou como um usuário legítimo e obteve todo o acesso potencial que o usuário tem. Isso é especialmente útil quando o usuário tem privilégios de administrador, resultando em um comprometimento completo da funcionalidade do seu aplicativo.
- Condição de corrida
Uma condição de corrida envolve vários processos nos quais o invasor tem controle total sobre um processo; o invasor explora o processo para criar caos, colisões ou erros. A corrupção de dados e a negação de serviço são a norma. O impacto pode ser local ou global, dependendo do que a condição de corrida afeta – como variáveis de estado ou lógica de segurança – e se ela ocorre em vários threads, processos ou sistemas.
- Vazamento de informações de mensagens de erro
As mensagens de erro tagarelas podem revelar segredos a qualquer invasor que faça mau uso do seu software. Os segredos podem abranger uma ampla gama de dados valiosos, inclusive informações de identificação pessoal (PII), credenciais de autenticação e configuração do servidor. Podem parecer segredos inofensivos e úteis para seus usuários e administradores, como o caminho completo de instalação do seu software, mas até mesmo esses pequenos segredos podem simplificar muito um ataque mais concentrado.
- Falha na restrição de operações dentro dos limites de um buffer de memória
O flagelo dos aplicativos C há décadas, os buffer overflows têm sido notavelmente resistentes à eliminação. As técnicas de ataque e detecção continuam a melhorar, e as variantes atuais de estouro de buffer nem sempre são óbvias à primeira ou até mesmo à segunda vista. O senhor pode pensar que é completamente imune a estouros de buffer porque escreve seu código em linguagens de alto nível em vez de C. Mas em que está escrito o interpretador da sua linguagem “segura” favorita? E o código nativo que o senhor chama? Em que linguagens estão escritas as APIs do sistema operacional? E o software que executa a infraestrutura da Internet?
- Controle externo de dados de estado crítico
Se o senhor armazenar os dados de estado do usuário em um local onde um invasor possa modificá-los, isso reduzirá a sobrecarga de um comprometimento bem-sucedido. Os dados podem ser armazenados em arquivos de configuração, perfis, cookies, campos de formulário ocultos, variáveis de ambiente, chaves de registro ou outros locais, todos os quais podem ser modificados por um invasor. Em protocolos sem estado, como o HTTP, alguma forma de informação sobre o estado do usuário deve ser capturada em cada solicitação, de modo que ela é exposta a um invasor por necessidade. Se o senhor realizar operações críticas de segurança com base nesses dados (como afirmar que o usuário é um administrador), pode apostar que alguém modificará os dados para enganar seu aplicativo.
- Controle externo do nome ou do caminho do arquivo
Quando o senhor usa a entrada de alguém de fora ao construir um nome de arquivo, o caminho resultante pode apontar para fora do diretório pretendido. Um invasor pode combinar várias sequências “…” ou similares para fazer com que o sistema operacional navegue para fora do diretório restrito. Outros ataques relacionados a arquivos são simplificados pelo controle externo de um nome de arquivo, como o seguimento de link simbólico, que faz com que o aplicativo leia ou modifique arquivos que o invasor não pode acessar diretamente. O mesmo se aplica se o seu programa estiver sendo executado com privilégios elevados e aceitar nomes de arquivos como entrada. Regras semelhantes se aplicam a URLs e à permissão para que uma pessoa de fora especifique URLs arbitrários.
- Caminho de pesquisa não confiável
Seu software depende do senhor ou do ambiente dele para fornecer um caminho de busca (ou caminho de trabalho) para encontrar recursos essenciais, como bibliotecas de código ou arquivos de configuração. Se o caminho de busca estiver sob o controle do invasor, ele poderá modificá-lo para apontar para recursos de sua escolha.
- Falha no controle da geração de código (também conhecido como “Injeção de código”)
Embora seja difícil negar a sensualidade do código gerado dinamicamente, os invasores o consideram igualmente atraente. Ele se torna uma vulnerabilidade grave quando seu código pode ser chamado diretamente por partes não autorizadas, se entradas externas podem afetar qual código é executado ou se essas entradas são alimentadas diretamente no próprio código.
- Download de código sem verificação de integridade
Se o senhor baixar um código e executá-lo, estará confiando que a fonte desse código não é mal-intencionada. Mas os invasores podem modificar esse código antes que ele chegue ao senhor. Eles podem invadir o site de download, fazer-se passar por ele com spoofing de DNS ou envenenamento de cache, convencer o sistema a redirecionar para um site diferente ou até mesmo modificar o código em trânsito enquanto ele atravessa a rede. Esse cenário se aplica até mesmo aos casos em que o senhor possui O produto baixa e instala atualizações.
- Desligamento ou liberação inadequada de recursos
Quando os recursos do seu sistema atingem o fim da vida útil, o senhor os descarta: memória, arquivos, cookies, estruturas de dados, sessões, pipes de comunicação e assim por diante. Os invasores podem explorar o desligamento inadequado para manter o controle sobre esses recursos bem depois que o senhor pensou que tinha se livrado deles. Os invasores podem vasculhar os itens descartados em busca de dados confidenciais. Eles também podem reutilizar esses recursos.
- Inicialização inadequada
Se o senhor não inicializar adequadamente seus dados e variáveis, um invasor poderá fazer a inicialização para o senhor ou extrair informações confidenciais que permanecem de sessões anteriores. Se essas variáveis forem usadas em operações críticas de segurança, como tomar uma decisão de autenticação, elas poderão ser modificadas para contornar sua segurança. Isso é mais comum em erros ou condições obscuras que fazem com que seu código ignore inadvertidamente a inicialização.
- Cálculo incorreto
Quando os invasores têm controle sobre as entradas dos cálculos numéricos, os erros matemáticos podem ter consequências para a segurança. Isso pode fazer com que o senhor aloque muito mais recursos do que pretendia, ou muito menos. Podem violar a lógica comercial (um cálculo que produz um preço negativo) ou causar negação de serviço (uma divisão por zero que aciona uma falha no programa).
- Controle de acesso inadequado (Autorização)
Se o senhor não garantir que os usuários do seu software façam apenas o que lhes é permitido, os invasores tentarão explorar sua autorização inadequada e exercer essa funcionalidade não autorizada.
- Uso de um algoritmo criptográfico quebrado ou arriscado
A criptografia do tipo “cresça você mesmo” é uma visão bem-vinda para os atacantes. A criptografia é difícil. Se matemáticos e cientistas da computação brilhantes do mundo todo não conseguem fazer isso direito – e eles estão regularmente obsoletos em suas próprias técnicas – então o senhor também não consegue.
- Senha codificada
A codificação de uma conta e senha secretas em seu software é extremamente conveniente para engenheiros reversos habilidosos. Se a senha for a mesma em todo o seu software, todos os clientes ficarão vulneráveis quando essa senha inevitavelmente se tornar conhecida. E como ela é codificada, é muito difícil corrigi-la.
- Atribuição de permissão insegura para recurso crítico
Cuidado com programas essenciais, armazenamentos de dados ou arquivos de configuração com permissões padrão de leitura mundial. Embora essa questão possa não ser considerada durante a implementação ou o projeto, ela deve ser. Não exija que seus clientes protejam o software para o senhor! Tente ser seguro por padrão, pronto para uso.
- Uso de valores insuficientemente aleatórios
O senhor pode depender da aleatoriedade mesmo sem saber, por exemplo, ao gerar IDs de sessão ou nomes de arquivos temporários. Os geradores de números pseudo-aleatórios (PRNG) são comumente usados, mas várias coisas podem dar errado. Quando um invasor consegue determinar qual algoritmo está sendo usado, ele pode adivinhar o próximo número aleatório com frequência suficiente para lançar um ataque bem-sucedido após um número relativamente pequeno de tentativas.
- Execução com privilégios desnecessários
Seu software pode precisar de privilégios especiais para executar determinadas operações; usar esses privilégios por mais tempo do que o necessário é arriscado. Ao ser executado com privilégios extras, seu aplicativo tem acesso a recursos que o usuário do aplicativo não pode acessar diretamente. Sempre que o senhor iniciar um programa separado com privilégios elevados, os invasores poderão explorar esses privilégios.
- Aplicação no lado do cliente da segurança no lado do servidor
Não confie no cliente para realizar verificações de segurança em nome do seu servidor. Os invasores podem fazer engenharia reversa do seu cliente e escrever seus próprios clientes personalizados. As consequências variam de acordo com o que suas verificações de segurança estão protegendo, mas alguns dos alvos mais comuns são autenticação, autorização e validação de entrada.
É claro que não há nada verdadeiramente novo aqui; basicamente, eu passei pela mesma lista básica em Pecados da segurança de software há quase dois anos. A única diferença são as prioridades relativas, pois os aplicativos da Web começam a dominar a computação convencional.
Essa lista de erros de segurança de software tem a mesma finalidade que a lista de McConnell lista de erros clássicos de desenvolvimento: para aumentar a conscientização. Uma parte surpreendentemente grande do sucesso é o reconhecimento dos erros e modos de falha mais comuns. Assim, o senhor pode, pelo menos em teoria, perceber quando seu projeto está caindo em um deles. A ignorância é o maior assassino de projetos de software de todos.
Mesmo que o senhor sejam ciente desses erros de segurança, o senhor pode acabar cometendo-os de qualquer forma. Eu sei Eu tenho.
O senhor já?