+5
Principais Falhas de Segurança em PHP
Escrevendo um Código PHP SEGURO
PHP é uma linguagem muito fácil de aprender e não precisa de um esforço muito grande que as outras linguagens necessitam. Por um lado, isso é bom para os iniciantes em php, pois podem começar a programar rapidamente, mas infelizmente, eles não se importam em aprender algo sobre segurança e acabam escrevendo seus códigos de qualquer jeito... Isso infelizmente não acontece somente com PHP. Acho que a maioria que começa a programar escreve os primeiros códigos com falhas banais de segurança. Em algumas linguagens isso não é um problema grave, porem toda tecnologia que é voltado para web, tem contato com um numero muito grande de pessoas diferentes, algumas são boas, outras no entanto não.
Eu imagino que a maioria dos iniciantes em PHP vai escrever em seus primeiros códigos minis-cms ou sistemas de noticias. Um grande número de sites pequenos provavelmente rodam códigos pessoais escritos por alguns que não possuem uma experiência necessária com php, isso também significa que um grande numero de sites podem se tornar (e estão) inseguros.
Eu mostrarei uma lista das falhas mais comuns que podemos encontrar e apesar de parecerem banais, são muito encontrados, junto com os maiores perigos.
Register Globals
----------------
Isso não é um problema novo, já foi tema de muitos artigos e muitos avisos, é algo comum de se encontrar. Porém talvez seja a primeira vez que alguns estão vendo isso... Então irei explicar:
No php.ini a variável register_globals até a versão 4.2.0 o padrão era on(ativada), porém a partir dela o padrão tornou-se off(desativada), mas muitos servidores ainda usam on, pois muitos scripts antigos foram feitos com base o register_globals on, então obviamente não funcionam quando o padrão é off.
O que acontece quando register_globals está on, variáveis GET/POST, etc se tornam variáveis globais.
Por exemplo:
http://example.com/test.php?id=4&shoes=cake
Como register_globals está on, as variáveis id e shoes tornaram-se variáveis globais.
O problema é que isso permite que variáveis sejam injetadas via url. Um script problemático poderia ser um como esse:
Agora se alguém chamasse a url test.php?loggedin=1
O script entenderia que a pessoa está logada, pois $loggedin se tornou uma variável global com o valor 1.
Uma 'correção' simples seria assim:
Desse modo, até mesmo se o $loggedin for injetado via url, ele se tornaria 0.
Com register_globals off, variáveis que são passadas como parâmetro via url, não se tornam variáveis globais. A forma certa de usar é você simplesmente usar as 'superglobals' que são $_GET, $_POST, $_SERVER, etc. etc.
O uso de superglobals sempre é preferido por razões de segurança e isso também deixa o código mais limpo e seguro. Pois você sabe quais variáveis estão vindo do GET/POST e quais não estão.
/*
Observação: A partir do PHP 6 provavelmente register_globals não irá mais existir
*/
PHP é uma linguagem muito fácil de aprender e não precisa de um esforço muito grande que as outras linguagens necessitam. Por um lado, isso é bom para os iniciantes em php, pois podem começar a programar rapidamente, mas infelizmente, eles não se importam em aprender algo sobre segurança e acabam escrevendo seus códigos de qualquer jeito... Isso infelizmente não acontece somente com PHP. Acho que a maioria que começa a programar escreve os primeiros códigos com falhas banais de segurança. Em algumas linguagens isso não é um problema grave, porem toda tecnologia que é voltado para web, tem contato com um numero muito grande de pessoas diferentes, algumas são boas, outras no entanto não.
Eu imagino que a maioria dos iniciantes em PHP vai escrever em seus primeiros códigos minis-cms ou sistemas de noticias. Um grande número de sites pequenos provavelmente rodam códigos pessoais escritos por alguns que não possuem uma experiência necessária com php, isso também significa que um grande numero de sites podem se tornar (e estão) inseguros.
Eu mostrarei uma lista das falhas mais comuns que podemos encontrar e apesar de parecerem banais, são muito encontrados, junto com os maiores perigos.
Register Globals
----------------
Isso não é um problema novo, já foi tema de muitos artigos e muitos avisos, é algo comum de se encontrar. Porém talvez seja a primeira vez que alguns estão vendo isso... Então irei explicar:
No php.ini a variável register_globals até a versão 4.2.0 o padrão era on(ativada), porém a partir dela o padrão tornou-se off(desativada), mas muitos servidores ainda usam on, pois muitos scripts antigos foram feitos com base o register_globals on, então obviamente não funcionam quando o padrão é off.
O que acontece quando register_globals está on, variáveis GET/POST, etc se tornam variáveis globais.
Por exemplo:
http://example.com/test.php?id=4&shoes=cake
Como register_globals está on, as variáveis id e shoes tornaram-se variáveis globais.
<?php echo $id; // 4 echo $shoes; // cake ?>
O problema é que isso permite que variáveis sejam injetadas via url. Um script problemático poderia ser um como esse:
<?php
if(AuthenticateUser($user, $pass)) {
$loggedin = 1;
}
// se tiver valor 1 é como se fosse autenticado
if($loggedin == 1) {
// stuff here that only a logged in user can see.
include("admin.php");
}
?>
Agora se alguém chamasse a url test.php?loggedin=1
O script entenderia que a pessoa está logada, pois $loggedin se tornou uma variável global com o valor 1.
Uma 'correção' simples seria assim:
<?php
if(AuthenticateUser($user, $pass)) {
$loggedin = 1;
} else {
$loggedin = 0;
}
?>
Desse modo, até mesmo se o $loggedin for injetado via url, ele se tornaria 0.
Com register_globals off, variáveis que são passadas como parâmetro via url, não se tornam variáveis globais. A forma certa de usar é você simplesmente usar as 'superglobals' que são $_GET, $_POST, $_SERVER, etc. etc.
O uso de superglobals sempre é preferido por razões de segurança e isso também deixa o código mais limpo e seguro. Pois você sabe quais variáveis estão vindo do GET/POST e quais não estão.
/*
Observação: A partir do PHP 6 provavelmente register_globals não irá mais existir
*/
Valeu pelo toque. Vou prestar mais atenção nesses detalhes.
26/10/2006 4:06pm
(~18 anos atrás)
Falhas ou Não, é necessário estár atendo as possíveis invasões... de qualquer forma o artigo é muito bom, parabéns!!!
15/09/2006 5:23am
(~18 anos atrás)
Ok, se você não conhece outros DB, não deveria ter tanta propriedade em desmerecê-los em favor do MySql que é muito mais limitado - inclusive quanto à segurança de banco e não aplicação - que os grandes de mercado. Há muitas funcionalidades disponíveis em outros DB que não se encontram no Mysql e que os DBAs necessitam
06/07/2006 5:41pm
(~18 anos atrás)
Não é falhas de seguranca do PHP, acho que você leu errado não?
E sim falhas de segurança "em" PHP
abraços
E sim falhas de segurança "em" PHP
abraços
29/06/2006 2:18pm
(~18 anos atrás)
Eu não concordo quando diz falhas de seguranca do PHP.
Acho que existem falhas de seguranca do programador. O PHP por facilitar muito as coisas, permite que os programadores facam muitas besteiras.
[]s
adler medrado
www.neshertech.net
adler.neshertech.net
Acho que existem falhas de seguranca do programador. O PHP por facilitar muito as coisas, permite que os programadores facam muitas besteiras.
[]s
adler medrado
www.neshertech.net
adler.neshertech.net
25/06/2006 7:34am
(~18 anos atrás)
Cara!
confesso que muita coisa que vc falou, eu já deu mole!!
muito obrigado pelas dicas!!
abraços!!
confesso que muita coisa que vc falou, eu já deu mole!!
muito obrigado pelas dicas!!
abraços!!
12/06/2006 4:13am
(~18 anos atrás)
Como o artigo não é seu, somente a tradução, congratulo-o pela iniciativa.
21/05/2006 8:30pm
(~18 anos atrás)
Primeiramente OTIMO artigo. Eu sou bem novato em php e este artigo vei muito bem a calhar.
No caso de tratamento de query diretamente tambem poderia ser utilizado:
$login = isset($_POST["login"]) ? addslashes(trim($_POST["login"])) : FALSE;
Desta forma todos os dados escapados como aspas simpes(') e aspas duplas(") seria vistos com caracteres normais.
Prontinho minha contribuicao.
Abraco
No caso de tratamento de query diretamente tambem poderia ser utilizado:
$login = isset($_POST["login"]) ? addslashes(trim($_POST["login"])) : FALSE;
Desta forma todos os dados escapados como aspas simpes(') e aspas duplas(") seria vistos com caracteres normais.
Prontinho minha contribuicao.
Abraco
07/05/2006 6:11pm
(~18 anos atrás)
Realmente alguns são bons programadores, porém acabam se esquecendo de um fator importante: segurança. Apenas um deslize poderá ser fatal um dia... Parabéns pelo artigo :-)
29/04/2006 5:47pm
(~18 anos atrás)