Uso do $_POST e $_GET

[#Tigre]

Olá pessoal,

no site que estou fazendo eu não estava usando o $_POST nas variáveis, mas fiquei sabendo que por motivos de segurança é sempre bom usá-lo.

Pelo que fiquei sabendo o $_POST é usado sempre em variáveis que vem de um formulário. Certo?

A minha dúvida é no caso do $_GET. Quando devo usar o $_GET ? Em quais tipos de variáveis?

Se alguém puder me dar a dica, agradeço.

[ESerra]

$_POST é quando os dados são enviados pelo método POST (99% dos casos vem de formulários, mas isso também pode ser simulado com cURL).

$_GET é quando os dados são enviados usando o método GET (que pode ser enviado através de formulário, mas também pode simplesmente ser um link passando um dado por querystring).

Note que usar ou não as superglobais para recuperação de dados, em si, não é falha de segurança, o que é falha de segurança e não validar as entradas que foram passadas pelo usuário, por exemplo, pegar um dado vindo de um formulário e jogar direto na query... de qualquer maneira register_globals (que é o que te permite abrir mão de resgatar as variáveis) não vai mais existir no PHP6 e a partir de lá tudo vai ter que ser resgatado, é claro, que vai ter gente que vai acabar fazendo uma gambiarra pra simular o efeito de register_globals...

Por fim cabe ressaltar que também existe o $_REQUEST e tem o mesmo efeito de $_POST e $_GET, mas é claro, pouco recomendado é o seu uso...

[Geleiaskt]

$_POST é quando os dados são enviados pelo método POST (99% dos casos vem de formulários, mas isso também pode ser simulado com cURL).

$_GET é quando os dados são enviados usando o método GET (que pode ser enviado através de formulário, mas também pode simplesmente ser um link passando um dado por querystring).

Note que usar ou não as superglobais para recuperação de dados, em si, não é falha de segurança, o que é falha de segurança e não validar as entradas que foram passadas pelo usuário, por exemplo, pegar um dado vindo de um formulário e jogar direto na query... de qualquer maneira register_globals (que é o que te permite abrir mão de resgatar as variáveis) não vai mais existir no PHP6 e a partir de lá tudo vai ter que ser resgatado, é claro, que vai ter gente que vai acabar fazendo uma gambiarra pra simular o efeito de register_globals...

Por fim cabe ressaltar que também existe o $_REQUEST e tem o mesmo efeito de $_POST e $_GET, mas é claro, pouco recomendado é o seu uso...

$_REQUEST é pouco recomendável? Humm... Poderia me dizer o porque?

Pois pelo que estudei sobre, como ele engloba a maioria das váriaveis pré-definidas($_GET, $_POST, $_FILES, etc), ela é mais recomendada para o uso em projetos de sistemas OO. :huh:

[ESerra]

Motivo é a seguraça, $_REQUEST permite que dados sejam infiltrados, afinal de contas, supondo que você tenha um formulário na página a.php e o action é a página b.php, se você utilizar o $_REQUEST eu posso passar os dados direto por querystring, claro que se você sempre fizer a validação/filtragem dos dados inseridos isso ameniza os problemas, de qualquer maneira sempre vai ter algum desocupado procurando brechas e o $_REQUEST ao meu ver causa um problema semelhante ao de register_globals (guardadas as devidas proporções).

De qualquer maneira, se um dado SEMPRE vai vir por POST é sem fundamente utilizar um REQUEST, por outro lado se algum dado pode as vezes vir por POST e as vezes por GET, ai sim o REQUEST é a saída.

[Guest --#tigre --]

Olá Serra, agradeço sua explicação.

Lá onde vou hospedar o site (hotel da web) eles usam o php 4 e me disseram que não tem nem previsão de mudar para a versão 6.

Mas mesmo assim acho que é bom usar o $_POST.

Só fiquei com duas dúvidas: se eu usar o $_POST então vou estar validando as entradas que foram passadas pelo usuário, certo? E qual seria a outra opção de validar as entradas sem usar $_POST ?

Quanto ao $_GET, eu não usei nenhuma vez o método GET. Tem como você passar um exemplo simples de um caso que use o $_GET, sem ser em formulário?

Obrigado pela atenção.

[ESerra]

Resgatar os dados por $_POST ou $_GET não é validação, validação é por exemplo, em um campo que só se espera número você verificar com o is_numeric se o que veio realmente é número, e assim por diante.

Para o $_GET, por exemplo, você chama uma página assim:

arquivo.php?dado1=XXXXXXXXX&dado2=YYYYYYYYYY

Para resgatar o XXXXXXXXX você usa $_GET['dado1'] e para resgatar o YYYYYYYYYY você usa o $_GET['dado2']

[#Tigre]

Ok Serra, só pra terminar, qual o principal motivo de se usar o $_POST, sem contar o register_globals.

Seria só pra resgatar mesmo ou tem haver com segurança?

[ESerra]

$_POST/$_GET apenas resgata, nada mais que isso, se register_globals estiver OFF ou não existir (como vai ser no PHP 6) você será obrigado a utilizar elas, senão simplesmente não vai pegar nada, a segurança está ligada a validação dos dados vindos dos forms...

[#Tigre]

Ok Serra, já tá ficando bem mais claro esse negócio do uso do $_POST.

Eu só fiquei meio preocupado com esse negócio de segurança. Num outro fórum um usuário passou essa mensagem abaixo:

Aconselho você acostumar a programar com $_POST e $_GET.

E aconselho também você a tratar essas variáveis.

Para não ocorrer de engraçadinhos bricar com seu código.

Gostaria muito de sua opinião sobre esse termo "tratar essas variáveis" que o colega falou aí.

Qual a melhor maneira de não deixar que essas variáveis fiquem vulneráveis?

A sua explicação sobre o uso do $_POST foi a que mais esclareceu a minha dúvida. Só essa questão de segurança é que está me encucando.

[ESerra]

Tratar as variáveis é se prevenir de engraçadinhos, não sei se você sabe, mas alguém com um mínimo de experiência pode dar um DROP na sua tabela e o pior é que isso nem é complicado...

Básico para garantir a segurança (segundo o meu ponto de vista):

1 - utilizar a função mysql_real_escape_string: Isso vai reduzir drasticamente problemas com SQL Injection

2 - Se você espera algo de um campo, teste para ver se o tal algo veio: Por exemplo, se você espera que em um campo só venha o valor 1 ou 2, ou que seja apenas números, teste, pois alguém pode estar se aproveitando para passar algo de forma errada

3 - Criar blacklists, ou whitelists: uma blacklist vai ter, por exemplo, palavras probidias em uma query (SELECT, DELETE, DROP, UPDATE...etc), uma whitelist serve para agilizar a questão citada acima (item 2), ou por exemplo, para limitar as palavras permitidas em um certo campo. Aqui tem um exemplo disso.

4 - Também é bom se previnir de ataques XSS (Cross Site Scripting) que dá pra fazer com as funções htmlspecialchars e htmlentities.

5 - Se um formulário é apenas para cadastro, crie um usuário que tenha apenas permissão para INSERT, no máximo SELECT... não precisa de todas as permissões se não vai usar.

Isso barra a maioria dos usuários maliciosos...

[#Tigre]

Ok Serra, vou dar uma estuda em cima destas funções aí.

Sobre o que vem do formulário não me preocupa tanto, pois os anúncios cadastrados só serão liberados após a verificação do mesmo. O site que estou fazendo é de classificados de veículos, com usuários cadastrados.

O problema maior são esses possíveis ataques.

Obrigado pela atenção.

[Geleiaskt]

Motivo é a seguraça, $_REQUEST permite que dados sejam infiltrados, afinal de contas, supondo que você tenha um formulário na página a.php e o action é a página b.php, se você utilizar o $_REQUEST eu posso passar os dados direto por querystring, claro que se você sempre fizer a validação/filtragem dos dados inseridos isso ameniza os problemas, de qualquer maneira sempre vai ter algum desocupado procurando brechas e o $_REQUEST ao meu ver causa um problema semelhante ao de register_globals (guardadas as devidas proporções).

De qualquer maneira, se um dado SEMPRE vai vir por POST é sem fundamente utilizar um REQUEST, por outro lado se algum dado pode as vezes vir por POST e as vezes por GET, ai sim o REQUEST é a saída.

Pois é ESerra. Não que $_REQUEST não seja recomendável, é que a maioria dos desenvolvedores não efetuam uma verificação dos dados enviados aí preferem utilizar o $_POST para ocultar o valor das variáveis dos usuários.

Pois para quem quer burlar um sistema, o modo de envio da variável é o de menos.

Você citou o exemplo da página a.php e b.php. Vamos dizer que o cara envie por $_POST em vez de $_REQUEST, de qualquer forma se ele não efetuar uma verificação, a aplicação vai estar vunerável pois pelo formulário eu também posso enviar os dados que eu enviaria por querystring($_GET). A diferença é que por POST os dados são ocultados do usuário.

Agora com certeza o código fica melhor estruturado e semântico utilizando os métodos $_GET e $_POST em suas determinadas funções, deixando o $_REQUEST para quando houver uma necessidade de receber dados dos dois modos, como você citou.

Abraço! :D

[#Tigre]

Olá Serra, voltando ao assunto do tópico, estou tentando implantar esta função que você me sugeriu no ítem 3 acima, mas estou meio confuso em como colocar as variávies ali no foreach. Tem como você me mostrar como ficaria num exemplo simples, por exemplo, com um formulário com 2 variáveis: $nome e $endereço.

Tem que fazer um pra cada variável ou todos de uma vez como falou o autor? Esse "todos de uma vez" que ficou meio confuso.

Agradeço pela atenção.

/* Fabyo Guimaraes de Oliveira 17/12/2004*/
function anti_injection($string){

  $string = str_ireplace(" or ", "", $string);
  $string = str_ireplace("select ", "", $string);
  $string = str_ireplace("delete ", "", $string);
  $string = str_ireplace("create ", "", $string);
  $string = str_replace("#", "", $string);
  $string = str_replace("=", "", $string);
  $string = str_replace("--", "", $string);
  $string = str_replace(";", "", $string);
  $string = str_replace("*", "", $string);
  $string = trim($string);
  $string = strip_tags($string);
  $string = addslashes($string);

  return $string;
}

//aqui eu pego todos os dados vindos do form 
//e tratos todos de uma vez e já cria as variaveis correspondentes
foreach ($_POST as $campo => $valor) {
   $$campo = anti_injection ($valor);
}

[ESerra]

O que você passou já está correto.

[#Tigre]

Serra, mas esse código aí eu passei como estava, sem mudar nada.

As variáveis que vem do formulário ficariam aonde?

Num exemplo com duas variávies: $nome e $endereco

eu tenho que colocá-las ali no lugar do $campo e $valor ou não preciso especificar as variáveis?

[ESerra]

Vamos ao racicício simples:

Isso tá vindo de um formulário né?

Nesse formulário existem dois campos, a saber:

1 - nome

2 - endereco

Correto?

Bom, se for isso o foreach está perfeito, pois a leitura é a seguinte, dois campos do formulário:

1 - nome, você digitou nele "fulado da silva"

2 - endereco, você digitou nele "rua sem nome"

A partir dai o foreach vai varrer o array $_POST e cada volta ele vai ter o seguinte:

foreach ($_POST as $campo => $valor) {

$$campo = anti_injection ($valor);

$campo vai ter o valor do nome do campo

$valor vai ser o valor do campo, então o próprio foreach transforma o -> $$campo = anti_injection ($valor); em:

$nome = anti_injection (fulado da silva);

e

$endereco = anti_injection (rua sem nome);

}

[#Tigre]

Ah bom, entendi o negócio, então não preciso alterar nada nessa função.

E como eu faço pra testar a função, tentar usar DELETE na query por exemplo. É possível ou é complicado testar isso?

[ESerra]

Esperimenta digitar no campo "xxvcv SELECT * FROM tabela" e submeter para ver o que retorna...

[#Tigre]

Serra, os 4 primeiros $string alí da função só funciona se tirar o 'i' do ireplace. Como está dá este erro: Fatal error: Call to undefined function: str_ireplace() in c:\..... on line 4

Se tirar o 'i' parece que funciona pois ele retira a palavra (select, delete..) digitada.

No caso do delete, select... tem um espaço ali depois da palavra que também tem que ser retirado pra funcionar.

você sabe a diferença de replace e ireplace? Posso deixar sem o 'i' mesmo?

[ESerra]

É sempre bom consultar o manual em primeiro lugar, veja o que ele diz sobre str_ireplace:

http://br.php.net/str_ireplace

str_ireplace — Versão que não diferencia maiúsculas e minúsculas de str_replace().

Se ele está dizendo que a função não existe é porque seu PHP ainda não é o 5, que é a versão em que foi introduzida essa função str_ireplace.

[#Tigre]

É isso Serra, o meu php é a versão 4.

Então a saída é usar o str_replace duas vezes, uma pra minúscula e outra pra maicúscula.

Acho que isso resolve. O que você acha?

[ESerra]

Duas vezes vai resolver para caso o cara escreva select ou SELECT, mas e se ele escrever sELECT ou Select? Ai já não resolve... ou seja, você vai ter que colocar bem mais do que duas maneiras para contemplar todas as possíveis alternativas.

[#Tigre]

É mesmo, não tinha pensado nisso.

Serra, eu só não entendi direito qual o efeito que causa usar este comando digitado em um campo de formulário.

Neste exemplo que você deu (aí embaixo) o que a função faz é retirar a palavra que está sendo proibida (no caso SELECT).

Esperimenta digitar no campo "xxvcv SELECT * FROM tabela" e submeter para ver o que retorna...

Se eu digitar isso aí sem ter a função na página, o que vai acontecer é guardar esta frase aí no banco de dados, como se fosse algo digitado normalmente.

você sabe como posso testar realmente um comando que tenha efeito no banco de dados?

[ESerra]

Um SELECT não é problema (até ali porque o catho teve um problema com um simples select a um tempo atrás), agora se o cara mandar um DROP lá pelo meio ele pode acabar com a sua tabela.

http://en.wikipedia.org/wiki/SQL_injection

[#Tigre]

Esses exemplos que tem no wikipédia são formas de "estragar" uma tabela?

Vou ver se faço um teste com esse DROP, mas não vai explodir nada lá né? hehe

[Durub]

Vai deletar a tabela.

Abraços.