Qual o melhor modo de proteger um arquivo PHP ?

[Daniel_Alves 0]

Amigos, boa tarde,

Estou começando a desenvolver em PHP, e me cadastrei no fórum afim de conversar com pessoas que realmente entendem do assunto.

Essa minha primeira dúvida não consegui resolver pesquisando no fórum do Imasters, no google, ou em outros blogs e sites afins.

 

A minha dúvida é : Criei um arquivo em PHP, que conecta a minha classe PHP de login ao meu banco de dados MySql.

Eu chamo esse arquivo utilizando require_once().

 

Sendo que quando "upei" esse arquivo para a minha hospedagem, fiquei com receio em relação à segurança do mesmo, visto que ali dentro estão o usuário e senha para conectar no meu servidor, e como utilizo o serviço de hospedagem da "HostMach", vem a ser a senha do Cpanel do meu domínio também , isso reforçou ainda mais o meu medo dessa senha ficar acessível.

 

Durante minhas pesquisas, descobri vários metódos de proteger o meu arquivo, sendo eles:

 

1-Colocar o arquivo um diretório acima do 'public_html':

Me parece bastante seguro, pois fica inacessível a todos, somente minhas páginas com código específico deveriam acessa-lo,porém não consegui fazer esse método funcionar, e ví também uma resistencia muito grande da parte de algumas pessoas em usar esse modo de proteção.

 

2-Colocar o arquivo em uma pasta isolada das demais e impedir a indexação da pasta com ".htaccess", ou até mesmo criar um arquivo "index.php" vazio, para que meus usuários não enchergem o conteúdo da pasta:

Apesar de fazer isso em todos os meus diretórios, não acho muito seguro, pois isso não impede o acesso direto ao arquivo.

 

3-Proteger o arquivo com o seguinte cabeçalho: "if ( basename($_SERVER['SCRIPT_FILENAME'])== basename(__FILE__) )die("Redirecionamento...");":

Ele é eficaz, realmente impede o acesso direto e tentativa de login, porém, ele bloqueia também as páginas que solicitam o arquivo, se tornando assim inútil ( desconfio que eu esteja fazendo algo de errado, pois essa solução eu achei aqui no fórum, e diversos usuários dizem utiliza-la ).

 

4-Não ter medo do acesso ao arquivo, pois como o PHP é processado pelo servidor quando o arquivo é solicitado pelo usuário, o código fonte não é mostrado, mas sim o resultado do processamento do código:

Não confio 100% nisso, ainda não conheço PHP o suficiente para julga-lo tão seguro ao ponto de por minhas senhas em suas mãos sem nenhuma segurança adicional.

 

Então, qual modo de proteção vocês usam e julgam como mais seguro e apropriado ao caso ?

 

Perdoem-me pelo longo texto, mas ele não é por falta de objetividade, mas sim por excesso de dúvidas...rsrsrs

[Andrey Knupp Vital 136]

Cara, na boa .. sinceramente, acho que você NÃO deveria se preocupar com coisas que não vão acontecer, se você acha que seu arquivo está inseguro, arrume um jeito de hackear o código, fazendo isso, você vai saber como fazer, e ao mesmo tempo, vai saber por onde começar a procurar as formas de se proteger.

[Daniel_Alves 0]

Cara, na boa .. sinceramente, acho que você NÃO deveria se preocupar com coisas que não vão acontecer, se você acha que seu arquivo está inseguro, arrume um jeito de hackear o código, fazendo isso, você vai saber como fazer, e ao mesmo tempo, vai saber por onde começar a procurar as formas de se proteger.

 

Ok, agradeço o conselho...

O meu único medo é em relação as coisas que não sei ainda, e por isso temo cometer um erro grotesco ou de super iniciante, que poderia facilmente ser evitado.

[Andrey Knupp Vital 136]

Potz, se eu tivesse medo das coisas que eu não sei, estaria frito ..

 

Você está pensando em algo totalmente fora de cogitação, no dia que você tiver mesmo um problema, você trabalha pra resolver este problema, e quanto mais preocupado você ficar com problemas que você não tem, mais problemas você vai ter.

[Henrique Barcelos 290]

Basta saber escolher com cuidado as empresas de hospedagem que vai ser muito difícil você ter seu sistema invadido ao ponto de terem acesso aos seus arquivos .php.

Essa deve ser a menor das suas preocupações com segurança...

[Lucas Peperaio 20]

Não confiem no usuário.

E possivel enviar cookies ao servidor, falsas sessões, simular um outro referrer, tudo com cURL.

 

Se você quiser impedir o acesso pela URL, crie um .htaccess na pasta onde está esse arquivo e faça isso:

<FilesMatch "seuArquivo\.php$>
order allow,deny
deny from all
</filesmatch>

[Henrique Barcelos 290]

Não confiem no usuário.

E possivel enviar cookies ao servidor, falsas sessões, simular um outro referrer, tudo com cURL.

Possível é, mas pra ele conseguir fazer o download de um arquivo *.php o buraco é beeeem mais embaixo...

[Daniel_Alves 0]

Não confiem no usuário.

E possivel enviar cookies ao servidor, falsas sessões, simular um outro referrer, tudo com cURL.

 

Se você quiser impedir o acesso pela URL, crie um .htaccess na pasta onde está esse arquivo e faça isso:

<FilesMatch "seuArquivo\.php$>
order allow,deny
deny from all
</filesmatch>

 

Show!

Era algo nesse nível que eu estava procurando !

Obrigado pelo código !

[hinom 5]

Uma dica também é não liberar execução do php nas pastas públicas.

 

Considerando que a pasta pública seja:

/www/websites/foo.bar/public

 

No virtualhost do httpd.conf, especifique um alias:

AliasMatch ^/(.*).php /www/websites/foo.bar/private/index.php

 

 

Desse modo, tudo que estiver em public são os arquivos estáticos

js, css, image, html, txt, entre outros..

 

Pode até existir um arquivo .php na pasta public, mas a execução será "redirecionada" para o arquivo index.php da pasta private

 

Isso é muito útil, por exemplo, quando um cliente exige ter acesso ao FTP para fazer uploads de imagens, arquivos html, etc, sendo que você não quer que ele tenha acesso a execução de scripts server-side como o PHP.

[Lucas Peperaio 20]

Possível é, mas pra ele conseguir fazer o download de um arquivo *.php o buraco é beeeem mais embaixo...

 

Pois é, se o código tiver alguma função arbitrária que utiliza uma entrada do usuário.. dá pra fazer o download do script php ao invés de ser processado. Deixo um exemplo:

<?php
if(isset($_GET['file'])):
	$file = $_GET['file'];
	if(file_exists($file)):
		$fp = fopen($file, "r");

		header("Content-Type:text/plain");
		header("Content-Disposition:attachment; filename=download.txt");
		header("Content-Transfer-Encoding:binary");

		fpassthru($fp);
	endif;
else:
	exit("Download não Encontrado");
endif;
?>

 

Neste código vulnerável, bastaria fazer um Path Transversal e ler o próprio arquivo PHP ou qualquer outra coisa, como o passwd. Como o Browser não interpreta PHP, ele iria servir para download. Esta é a única forma que eu conheco de roubar scripts PHP.

 

 

Show!

Era algo nesse nível que eu estava procurando !

Obrigado pelo código !

 

Por nada, disponha

 

Uma dica também é não liberar execução do php nas pastas públicas.

 

Considerando que a pasta pública seja:

/www/websites/foo.bar/public

 

No virtualhost do httpd.conf, especifique um alias:

AliasMatch ^/(.*).php /www/websites/foo.bar/private/index.php

 

 

Desse modo, tudo que estiver em public são os arquivos estáticos

js, css, image, html, txt, entre outros..

 

Pode até existir um arquivo .php na pasta public, mas a execução será "redirecionada" para o arquivo index.php da pasta private

 

Isso é muito útil, por exemplo, quando um cliente exige ter acesso ao FTP para fazer uploads de imagens, arquivos html, etc, sendo que você não quer que ele tenha acesso a execução de scripts server-side como o PHP.

 

Legal sua dica, vou anotar aqui

[Henrique Barcelos 290]

Mas esse é um caso muito específico onde você força um download.

É simples prefinivir isso impedindo no próprio código que arquivos com a extensão .php sejam baixados.

 

Volto a enfatizar: o problema de alguém ter acesso aos seus arquivos *.php é o menor dos problemas de segurança...

[Lucas Peperaio 20]

Com certeza Henrique, os problemas mais comuns são:

 

1. SQL Injection
2. PHP Injection
3. Path Traversal
4. Spoofing em Formulários
5. Leitura de Cookies com unserialize()
6. Sequestro de Sessão

 

 

As respectivas soluções:

 

1. Filtrar os dados de entrada
2. Verificar se o arquivo existe e desligar o allow_url_include (ja vem desligado por padrao)
3. Configurar o open_basedir e filtrar a entrada por ER
4. Captcha, sessão ou limitar qtde de envio por IP
5. Evitar cookies em casos de risco
6. Expirar sessão por inatividade

Download forçado de script é raro

[Andrey Knupp Vital 136]

1. SQL Injection
2. PHP Injection
3. Path Traversal
4. Spoofing em Formulários
5. Leitura de Cookies com unserialize()
6. Sequestro de Sessão

 

E você tem algum desses problemas ? .. só você pensar kara .. 'você acha que vai vim um cara lá do .. sei lá onde, fazer injection logo na tua app' ? ninguém está preocupado com isso não amigo .. no dia que acontecer, aí sim você tem que providenciar uma forma de evitar.

 

Galera, volto a falar ... parem de se preocupar com problemas que vocês não tem.

[Lucas Peperaio 20]

E você tem algum desses problemas ?

 

Não é questão de ter ou não ter, eu só mostrei os principais problemas e possíveis soluções. Leia novamente o meu texto acima

 

.. 'você acha que vai vim um cara lá do .. sei lá onde, fazer injection logo na tua app'

 

Nós não podemos pensar assim, se nós sabemos que existe as vulnerabilidades, vamos deixar de lado na esperança que ninguém com um pouco de conhecimento venha explorar? Se eu acho que vem? ah vem, com certeza. E pior, quando descobrem uma falha, eles divulgam em fóruns hackers, ai vem uma galera inteira pra f* com tudo.

 

Galera, volto a falar ... parem de se preocupar com problemas que vocês não tem.

 

Você prefere ter o seu site ou do seu cliente invadido para se preocupar? Eu prefiro previnir antes..

[Andrey Knupp Vital 136]

Nós não podemos pensar assim, se nós sabemos que existe as vulnerabilidades, vamos deixar de lado na esperança que ninguém com um pouco de conhecimento venha explorar?

 

Se você ficar sempre na esperança de que vá aparecer um problema, você pode desistir de trabalhar com qualquer tipo de coisa, primeiro que pode acontecer milhares de coisas, não só os que você pode resolver, com os que você não pode, e você só resolve um problema, quando você tem um problema ..

 

É mesma coisa que eu falar pra você, vou atacar seu site amanhã, vou fazer isso isso e isso .. 'ameaça', sendo que amanhã nem se quer vou lembrar disso, você vai se preocupar com algo que provavelmente não vai acontecer, agora, se acontecer, você vai ter que resolver, você faz as coisas que não precisa em casa ? .. você limpa o que não tá sujo ? pescou a pegada .. ? NÃO SE RESOLVE UM PROBLEMA QUANDO NÃO SE TEM UM PROBLEMA

 

Temos que se preocupar sim Andrey, pois agora podemos até não ter estes problemas, mas se nos omitirmos, é questão de tempo os nossos sites serem alvos destes problemas.

 

O servidor vai explodir amanhã, o que você vai fazer pra resolver ? ¬¬ não tem lógica nenhuma essa sua resposta.

 

E tem mais, não adianta você ficar argumentando aqui comigo, porque não vai chegar a lugar nenhum, você não vai mudar, e eu não vou mudar .. mas isso vai acabar atrapalhando quem tem problemas sérios pra resolver, ou tem problemas que precisam ser resolvidos de primeira importância.

 

Você vai fazer essa pessoa ter que ficar pensando nessas coisas aí que o cara nem sabe que existe.

[Lucas Peperaio 20]

Entendi o seu ponto de vista.

Eu prefiro prevenir, não sou bitolado a ponto de pensar sempre em falhas, invasões e etc.

 

Quando desenvolvo algo, eu penso como um usuário malioso poderia explorar aquilo. E pronto, entrego pro cliente assim, depois nem me preocupo mais.

[Daniel_Alves 0]

Nossa, gerou uma discução monstro a dúvida...rsrsr

 

Nos ultimos posts teve uma chuva de informações, muitas delas eu não conhecia, estou pesquisando sobre cada uma delas.

 

Agradeço pela dica hinnon, vou implementar ela agora mesmo.

 

Lucas, seu ponto de vista é exatamente igual ao meu, sempre se preocupando com a segurança, te entendo, sei como são essas preocupações.

 

Andrey, concordo com você quando fala sobre problemas que fogem ao nosso controle ( por exemplo : vulnerabilidades no servidor ), porém, na minha concepção é irresponsabilidade de nossa parte não tratar de erros que já sabemos que existem/ já passamos por eles / podemos evitar ! Seria meio que uma negligência, entende ?

 

Trazendo pra vida real eu vejo como o exemplo de um motorista : Ele sabe que é errado andar com os pneus carecas, que está propício a acidentes, mas como o carro "está funcionando", ele não se preocupa em troca-los!

 

Enfim, cada um tem seu modo de pensar, cabe a cada um respeitar o modo do próximo, mas na questão desse tópico, eu concordo com o Lucas...

 

Bem, creio que já tenho todas as informações que preciso, não sei bem como funciona esse lance de "Fechar o tópico", mas se quiserem já podem fechar...

 

Obrigado novamente pelas respostas e pela ajuda !

[Lucas Peperaio 20]

Daniel, pra complementar as suas pesquisas, dá uma olhada neste tópico:

http://forum.imaster..._1#entry1681844

 

Nele a galera discutiu vários pontos importantes em segurança PHP

 

Só um detalhe sobre aquele código que eu te passei, faltou uma aspas nele, aqui está o corrigido:

<FilesMatch "seuArquivo\.php">
order allow,deny
deny from all
</filesmatch>

 

Ps: repararam que apagaram aquela discussão toda?

[Daniel_Alves 0]

Daniel, pra complementar as suas pesquisas, dá uma olhada neste tópico:

http://forum.imaster..._1#entry1681844

 

Nele a galera discutiu vários pontos importantes em segurança PHP

 

Só um detalhe sobre aquele código que eu te passei, faltou uma aspas nele, aqui está o corrigido:

<FilesMatch "seuArquivo\.php">
order allow,deny
deny from all
</filesmatch>

 

Ps: repararam que apagaram aquela discussão toda?

 

Lucas, estou tentando implantar Esse esquema de "FilesMatch".

Na primeira mensagem onde você a sitou, você disse para criar um '.htaccess' e então colocar o código.

Nesse ponto fiquei em dúvida ! Devo colocar o código no cabeçalho do arquivo que quero proteger, ou no arquivo ".htaccess" ?

 

E outra dúvida, para ficar mais "didático":

<FilesMatch "seuArquivo\.php"> //Aqui definimos o nome do único arquivo que poderá acessar o arquivo protegido ?
order allow,deny
deny from all //Nessas duas ultimas linhas, ele define que a não ser que o acessante seja o arquivo definido na primeira linha, o acesso será negado. Correto ?
</filesmatch>

 

PS: Na verdade não apagaram todas as mensagens, deixaram a parte onde a discução ainda estava saldável....rsrsrs

[Andrey Knupp Vital 136]

Ps: repararam que apagaram aquela discussão toda?

Era totalmente inútil neste tópico, agente devia ter discutido por mp, rsrsrs ..