Segurança é um conceito interessante e atrai muita gente para ele. Infelizmente é um assunto complexo e até os profissionais erram. Encontrei falhas de segurança no Google (CSRF), Facebook (mais CSRF), vários grandes varejistas online (principalmente injeção de SQL / XSS), bem como milhares de sites menores, tanto corporativos quanto pessoais.
Estas são as minhas recomendações:
1) Use consultas parametrizadas
As consultas parametrizadas forçam os valores passados à consulta a serem tratados como dados separados, de modo que os valores de entrada não possam ser analisados como código SQL pelo SGBD. Muitas pessoas irão recomendar que você escape de suas strings usando
mysql_real_escape_string() , mas ao contrário da crença popular, não uma solução abrangente para injeção de SQL. Veja esta consulta por exemplo:SELECT * FROM users WHERE userID = $_GET['userid']
Se
$_GET['userid'] está definido como 1 OR 1=1 , não há caracteres especiais e não será filtrado. Isso resulta no retorno de todas as linhas. Ou, pior ainda, e se estiver definido como 1 OR is_admin = 1 ? As consultas parametrizadas evitam que esse tipo de injeção ocorra.
2) Valide suas entradas
As consultas parametrizadas são ótimas, mas às vezes valores inesperados podem causar problemas com seu código. Verifique se você está validando que eles estão dentro do alcance e que não permitirão que o usuário atual altere algo que não deveria.
Por exemplo, você pode ter um formulário de alteração de senha que envia uma solicitação POST para um script que altera sua senha. Se você colocar o ID do usuário como uma variável oculta no formulário, eles poderão alterá-lo. Enviando
id=123 em vez de id=321 pode significar que eles alteram a senha de outra pessoa. Certifique-se de que TUDO seja validado corretamente, em termos de tipo, alcance e acesso. 3) Use htmlspecialchars para escapar da entrada do usuário exibida
Digamos que seu usuário insira seu "sobre mim" assim:
</div><script>document.alert('hello!');</script><div> O problema com isso é que sua saída conterá a marcação que o usuário inseriu. Tentar filtrar isso você mesmo com listas negras é uma má ideia. Use
htmlspecialchars para filtrar as strings para que as tags HTML sejam convertidas em entidades HTML. 4) Não use $_REQUEST
Os ataques de falsificação de solicitação entre sites (CSRF) funcionam fazendo com que o usuário clique em um link ou visite uma URL que representa um script que executa uma ação em um site para o qual ele está logado. O
$_REQUEST variável é uma combinação de $_GET , $_POST e $_COOKIE , o que significa que você não pode dizer a diferença entre uma variável que foi enviada em uma solicitação POST (ou seja, por meio de um input tag em seu formulário) ou uma variável que foi definida em seu URL como parte de um GET (por exemplo, page.php?id=1 ). Digamos que o usuário queira enviar uma mensagem privada para alguém. Eles podem enviar uma solicitação POST para
sendmessage.php , com to , subject e message como parâmetros. Agora vamos imaginar que alguém envie uma solicitação GET:sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Se você estiver usando
$_POST , você não verá nenhum desses parâmetros, pois eles estão definidos em $_GET em vez de. Seu código não verá o $_POST['to'] ou qualquer uma das outras variáveis, então não enviará a mensagem. No entanto, se você estiver usando $_REQUEST , o $_GET e $_POST ficam presos juntos, para que um invasor possa definir esses parâmetros como parte do URL. Quando o usuário visita esse URL, ele envia a mensagem inadvertidamente. A parte realmente preocupante é que o usuário não precisa fazer nada. Se o invasor criar uma página maliciosa, ela poderá conter um iframe que aponta para o URL. Exemplo:<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Isso resulta no usuário enviando mensagens para as pessoas sem nunca perceber que eles fizeram alguma coisa. Por esse motivo, você deve evitar
$_REQUEST e use $_POST e $_GET em vez de. 5) Trate tudo o que receber como suspeito (ou até malicioso)
Você não tem ideia do que o usuário está lhe enviando. Pode ser legítimo. Pode ser um ataque. Nunca confie em nada que um usuário lhe enviou. Converta para tipos corretos, valide as entradas, use listas brancas para filtrar quando necessário (evite listas negras). Isso inclui qualquer coisa enviada via
$_GET , $_POST , $_COOKIE e $_FILES . Se você seguir essas diretrizes, estará em uma posição razoável em termos de segurança.
