Como é, ser hackeado no PHP?

[Micilini Roll 49]

Como é ser hackeado,em seu proprio site? em seu proprio banco de dados?,muitos iniciantes em PHP ja deve ter visto ou ouvido que,um sistema feito para web pode ser facilmente hackeado,muitos destes iniciantes concerteza ja devem ter feito este tipo de pergunta, ou deveriam! e a pergunta MASTER é a seguinte:

 

 

 

Como vou saber como fui hackeado?

 

não entendeu? vamos a um pequeno exemplo!

 

Como fui roubado?

 

Iremos imaginar que em sua propria casa, aconteçeu um roubo no exato momento em que vc nao estava presente! ao chegar em casa verá que alguns itens foram destruidos e outros roubado,a primeira coisa que voce fará antes de ligar para policia é...por onde ele entrou?

 

1- SE ele entrou pela janela = a janela deve estar quebrada

2- SE ele entrou pela porta = a maçaneta deve estar quebrada

3- e assim por diante...

 

voltando ao assunto interior...acho muito provavel que no php nao tenha isso ou seja,se eu estiver por fora do conheçimento em sql injection logicamente meu campo de texto do site nao estara quebrado! rsrs

 

então pessoal! vamos compartilhar!

 

1-seu site foi hackeado alguma vez? o que aconteçeu, e como voce fez pra descobrir por onde o hacker encontrou uma brecha?

2- como é ser hackeado no php?

[Vinicius Rangel 208]

se não apresentar nenhum funcionamento incorreto ou dado inconsistente creio eu que não tem como saber.

do mesmo modo que vc citou o exemplo da sua casa ser assaltada vou usar para tentar explicar meu ponto de vista.

 

na minha casa eu tenho uma gaveta com uns 30 tipos de cabos diferentes e as vezes existem até 2 cabos daquele mesmo modelo e eu já perdi o controle daquilo logo se alguém entrar na minha casa e pegar 1 ou 10 cabos daquele eu não vou dar falta e minha vida vai continuar tocando normalmente, agora se for um item critico.. TV, NOTEBOOK, CELULAR ETC..

 

sentirei faltar e começarei "debugar" a situação para saber como o ladrão chegou nisso, sabendo como ele chegou nisso claramente vc sabe como arrumar.

[William Phantom 32]

bom, básicamente não tem como saber se foi hackeado ou não.(ter tem mas ai você teria que notar que foi hackeado)

você vera algo caso seja crakeado (alterações nos arquivos, inserções de dados estranhos, etc(...))

geralmente isso deixa rastros no log

[Ricardo Saraiva 84]

Ai depende um pouco do conceito 'hackeado' se o cara acesso o seu host atraves de ftp e robou seu arquivos mais não modificou nada existe a possibilidade de ver os log's de acesso, no caso de acesso de um banco de dados existe a mesma possibilidade.

 

Porem você não vai ficar olhando log de acesso de ftp e log de acesso do banco de dados todos os dias.

Em caso de aplicativos onde se precisa de um nivel de segurança existe um administrador de rede para isso.

 

E a dica no tópico de #2 do Vinicius tambem é bem importante.

E tem aquele fomoso ditado: É MELHOR PREVINIR DO QUE REMEDIAR!

[Micilini Roll 49]

Eu ate aonde sei...nunca fui hackeado, mas em falar sobre hacker de site, eu penso logo em duas coisas

 

1- invadir seu banco de dados e alterar ou apagar os arquivos

 

e tambem seria muito frustrante abrir seu site e ver imagens como estas:

 

 

 

tudo bem que se for banco de dados,e tiver usuarios cadastrados podemos ate inventar uma desculpas ,mas as imagens lá em cima causa bastante frustração tanto para o criador do site quando para os usuarios do site...

[William Phantom 32]

essas imagens acima mostra um trabalho "cracker" e não "hacker", pois hacker é aquele que trabalha procurando por falhas em sistemas, a fim de consertá-los

 

já o cracker sim, esse causa probremas, apaga arquivos, destrói bancos de dados.

 

e sim é bastante frustante ver um site que você fez ser hackeado,

já que você pensa em toda estrutura, visando segurança e praticidade

 

e absolutamente não existe um site 100% seguro contra invasões, e derrubadas (esqueci o termo correto XD)

alguns sites são mais seguros outros nem tanto

[Micilini Roll 49]

pessoal eu vi que existem programas na internet que exploram as vulnerabilidades do seu site ate agora so conheço o:

 

DAMN VULNERABLE WEB APP

 

Acredito que existam muitos outros,mas quais são eles?

[Williams Duarte 431]

Acutenix

[Ricardo Saraiva 84]

Um site muito interresante quando o assunto é segurança: OWASP

 

Tenha uma slide muito bom tambem que aborda varios tópicos interessante:

http://www.slideshare.net/gedvan/segurana-em-aplicaes-web-com-php-8676135

 

Uma pratica que acho que da escopo maior sobre controle de sua aplicação e com certeza com isso aumenta o nivel de segurança dela é TDD. Ainda sou novo to tentado me adpatar (na verdade to apanhado demais) com TDD.

[Micilini Roll 49]

Então vamos lá,antes de colocar o site no ar quais sao as primeiras prevençoes para evitar futuras perdas de dados? De acordo com a minha intuição deve-se seguir:

 

1-Hospedar em um servidor dedicado e seguro,tais como kinghost dentre outros

2-Caso for um site aonde a segurança do usuario é fundamental,deve-se pegar um certificado SSL,no caso custoxbeneficio pegue o um que ofereça criptografia de pelo menos 256 bits e que faça apareçer um cadeado verde na url

3-deve-se filtrar todos os campos de seu site contra -> sql injection e xss injection

4-nas pastas dos projetos mudar as permissões(chmod) para somente leitura

5-nos arquivos .htaccess fazer com que somente as pastas necessarias sejam acessadas

6-criptografar quaisquer tipos de cookies,ainda mais se forem do tipo CONTINUAR LOGADO

7-em caso de força bruta em areas de logins definir quantas tentativas pode ser feitas ate a aparição do captcha

 

eu iria adicionar o numero 8 que iria se consistir em :

 

 

 

• LFI (Local File Inclusion)
• RFI (Remote File Inclusion)

 

 

so que dentre estes estou totalmente por fora...e ao meu ver esse LFI e RFI são os responsaveis por fazer alteraçoes na index,tipos de alterações que voces podem ver nas imagens que postei logo acima...

[William Phantom 32]

ultimamente eu ouço muito falar em javascript injection (apesar de não saber muito)

 

você não deve filtrar sómente os campos, filtre também query strings, javascript e todas entradas de dados

[Enrico Pereira 299]

Ricardo Saraiva, agora bateu uma curiosidade: de que forma você acha que TDD ajuda em segurança?

[Ricardo Saraiva 84]

Bom Enrico essa uma opnião um pouco pessoal minha mais vou tentar expor meu ponto de vista:

• Quando escrevo testes tenho um controle maior sobre o controle do fluxo entrada e saida de minha apicação.
• Os testes ajudão a evitar erros de programação.
• Integração Continua - quando se trabalha com uma equipe no mesmo projeto ou em projeto open source intregação continua ajuda a garantir que os programadores vão respeitar os teste ja estabelecido incluindo teste de segurança.

Mais resumindo os teste ajudão a previnir erros de programação que podem gerar falhas de segurança.

[Prog 183]

Os testes funcionam muito bem para testar os cenários previstos, logo, pelo menos estes cenários devem estar menos "bugados" e dificultar a exploração.

[Ricardo Saraiva 84]

Prog defino de forma perfeita a relação entre TDD e segurança. :yes:

[Evandro Oliveira 331]

@Micilini Roll, os exemplos postados são casos clássicos de deface.

 

A única forma que eu conheço para isso acontecer é com a alteração de arquivos.

 

As duas formas que eu conheço para se alterar os arquivos são: acessando o sistema de arquivos (ftp e ssh) ou por script.

 

As duas formas que eu conheço para se alterar arquivos por sistema de arquivos são: senha (ftp e ssh) ou chave de acesso (ssh).

 

As duas formas que eu conheço para se alterar arquivos num script php são eval e exec

 

Pra deface, eu acho que é isso.

[Enrico Pereira 299]

Ricardo e Prog, sobre o TDD: sim, comumente gera menos bugs mas não podemos falar que o objetivo do TDD é segurança.. é que na forma que postou, parece que TDD era uma técnica de segurança :lol:.

Vou postar uma compilação de coisas relacionadas à segurança em PHP, talvez ajude alguém.

Dicas Básicas de Segurança

I/O e Filtragem & Validação

A forma mais simples e eficaz (e extremamente necessária) contra invasores: nunca confiar em dados externos. Quando digo dados externos digo: input de usuário, dados vindos do banco (o banco pode ter sido violado), webservices, ou qualquer outra coisa que não seja um dado vindo do código. Não confiar significa, basicamente, filtrar e validar sempre.

Hospedagem/Servidor

Todavia de pouco adianta ter um código extremamente seguro se possui um servidor inseguro ou se usar senhas fracas para FTP ou qualquer outra forma de acesso à código ou à dados da aplicação em geral. Esse é um ponto de porque 99% das hospedagens compartilhadas são ruins.
E evidentemente: se quem realiza acesso à esse tipo de ferramenta com conexão de internet insegura (geralmente conexões wi-fi públicas; como as de shopping, aeroporto, etc.).

Versão do PHP

Outro ponto é a versão do PHP. Puta merda, tem gente usando PHP 4 hoje em dia :o, o PHP 4 foi abandonado há anos. E um pouquinho menos perigoso, mas ainda ruim é que muitos servidores usam outras versões minor do PHP que não são mais mantidas ou versões patch desatualizadas.

Dica: sempre use uma versão do PHP atualmente mantida (hoje em dia PHP 5.3 e PHP 5.4) com os patches atualizados (e.g. 5.3.x, 5.4.x - x significa o patch).

Verificando invasões

Em minha opinião, logs são a melhor (se não a única) forma de verificar invasões.

Dica: crie logs para as partes seguras (admin, contas de usuário, etc.) e poderá ter uma maior chance de detectar uma invasão. Nos logs, passe todos os dados das superglobais ($_GET, $_POST, $_FILES, $_SERVER, $_COOKIE, $_SESSION).

Visibilidade de arquivos

Outro ponto que muitos fazem e é inseguro: colocar tudo na pasta pública (public_html, public, www, htdocs, etc. dependendo do servidor), esses arquivos ficarão visíveis ou você vai bloquear de alguma forma, mas neste caso o invasor pensará que algum arquivo existe ali e ele acabou de obter uma informação que não deveria.

Dica: coloque apenas o index.php e os arquivos estáticos, classes e outros arquivos devem ficar uma pasta abaixo. Em cPanel (que é bem comum de se usar) ficaria assim:

pastadousuario/ (a pasta home do cPanel)    /projeto      ... (aqui vão os arquivos internos de PHP e todo o resto que não é para o usuário meter a pata, note que está fora da public_html)    public_html/      img/      css/      js/      videos/      index.php      ... (se não puder usar .httpd.conf, use um .htaccess para fazer as urls amigáveis, cache e o que for necessário)    ... (outras pastas do servidor...)

PHP.ini

:seta: Desabilite os erros (somente em produção, em desenvolvimento isso é jogar lixo debaixo do tapete):

display_errors = Off

:seta: Remova a informação do PHP dos cabeçalhos de resposta HTTP (X-Powered-By especificamente):

expose_php = Off

:seta: Se estiver usando uma versão do PHP que seja menor do que a 5.3 (o que é extremamente não recomendado), desligue o maldito infeliz do register_globals :skull::

register_globals = Off

Código externo

A\o usar código externo veja bem o que tu estás fazendo, colocar código externo em sua aplicação é como você colocar uma pessoa dentro de sua casa, saiba bem o que está fazendo e tenha cuidado.

.htaccess

Você não deve usá-lo se puder usar o httpd.conf. Você pode até bloquear o acesso, mas o invasor vai saber que você usa Apache, e quanto menos informação ele tiver, melhor.

Encriptação

Para senhas, não use MD5 e nem mesmo SHA1, use bcrypt.
Vale a pena ler: http://blog.thiagobelem.net/criptografando-senhas-no-php-usando-bcrypt-blowfish/

Upload de Arquivos

Se for fazer upload de arquivo todo cuidado é pouco: valide pelo mime-type e pela extensão, por ambos. E além de que você pode (e deve) dar um file_get_contents no arquivo temporário e ver se possui código PHP malicioso dentro dele.

Sessions

:seta: No PHP.ini, habilite o session.use_only_cookies, para evitar que o PHPSESSID seja passado pela URL.

session.use_only_cookies = 1

:seta: Renomeie o PHPSESSID para algum outro nome que não fale sobre PHP, usando PHP.ini:

session.name = TOKEN

:seta: Regere o id da sessão sempre.

:seta: Use sessões ao invés de cookies para armazenar dados sensíveis.

Princípios

:seta: Forneça ao invasor a menor informação possível.
:seta: Filtre o input e escape o output.
:seta: Não forneça dados secretos à ninguém (meio que óbvio).
:seta: Teste a segurança da aplicação sempre, tente simular ataques que invasores podem fazer.
:seta: Não confie no usuário.
:seta: Não confie no usuário.
:seta: Não confie no usuário.
:seta: Não seja preguiçoso.
:seta: Não seja preguiçoso.
:seta: Não seja preguiçoso.
(as repetições foram propositais..)

Hangout

O iMasters possui um hangout sobre segurança em aplicações web, apesar de ter 4 horas, vale a pena assistir.

Conclusão

Acho que foi um post bem longo, mas com informações úteis, isso é o que importa :D.

E não esqueça: não existe sistema 100% seguro, problemas acontecem nas melhores "famílias".

[Henrique Barcelos 290]

Medidas de segurança por ocultação são a maior enganação que existem. Na verdade, nem deveriam ser chamadas de medidas de segurança.

"Esconder" o PHP não adianta nada. Se o cara quer mesmo invadir, primeiro ele tenta o Java, depois o Python, depois o .NET, o PHP, e assim vai...

[Evandro Oliveira 331]

Medidas de segurança por ocultação são a maior enganação que existem. Na verdade, nem deveriam ser chamadas de medidas de segurança.

"Esconder" o PHP não adianta nada. Se o cara quer mesmo invadir, primeiro ele tenta o Java, depois o Python, depois o .NET, o PHP, e assim vai...

Custo, atraso e filtro. Como eu vivo dizendo, segurança não é escalar ou inteiro. Você não está 100%, 80% seguro. Segurança remete a camadas.

 

Você está seguro contra X, contra Y, contra Z. Cada camada/medida de segurança, te defende dum perfil. Ocultação gera custo por tentativa e erro.

 

Gerar custo é um dos princípios da lib mais comumente usada para criptografia hoje, crypt

 

Supondo que tenhamos rainbow tables pra sha-512. É mais fácil testar a tabela num hash que roda uma única vez do que num hash de 10.000 vezes. Tem muito a ver com custo.

 

Sair procurando por informativos de linguagem backend é um custo.

Se o cara quer mesmo invadir, primeiro ele tenta o Java, depois o Python, depois o .NET, o PHP, e assim vai...

Não dando a versão do PHP, por exemplo, o cara tem que procurar por todas as vulnerabilidades conhecidas ao invés de buscar o changelog da versão+1 e ganhar - de bandeja - os pontos fracos.

[Enrico Pereira 299]

Quanto mais segurança melhor, sendo que o limite é a usabilidade.