Mas, você não pode resistir estatísticas. Ninguém vai ler um artigo intitulado Todo mundo quer um artigo com um número dentro "Codificação para a Segurança.": "Os 8 ataques mais comuns de segurança do PHP e como evitá-los", "23 coisas para não dizer a um modelo Super" , e "15 razões para evitar envenenamento por radiação." Então, aqui vai, o "Top 10 vulnerabilidades de segurança do PHP."
Injeção de SQL.
O número um na lista de alvos é o ataque de injeção de SQL. Neste caso, alguém entra em um fragmento de SQL (o exemplo clássico é uma declaração de banco de dados queda, embora haja muitas possibilidades que não incluem supressões que poderia ser tão destrutivo) como um valor em seu URL ou formulário web. Não importa agora como ele sabe o que os seus nomes de tabela são, que é um outro problema completamente. Você está lidando com um inimigo insidioso e engenhoso.
Então, o que você pode fazer para evitar isso? Em primeiro lugar você precisa ser suspeito de qualquer entrada que aceitar de um usuário. Acredito que todos é bom? Basta olhar para a família do seu cônjuge ... eles é estranho e esquisito, alguns perigosamente.
A maneira de evitar esse tipo de coisa é usar DOP declarações preparadas. Eu não quero passar por uma discussão completa do DOP agora. Basta dizer que as declarações preparadas separar os dados a partir das instruções. Ao fazer isso, ele evita que os dados sejam tratados como algo além de dados. Para mais informações, você pode querer verificar para fora este artigo PHPMaster .
XSS (Cross Site Scripting)
Amaldiçoar os corações negros que prosperam sobre este tipo de fraude. Os pais, conversar com vocês, crianças de hoje para que não se XSS'ers mal!
A essência de qualquer ataque XSS é a injeção de código (geralmente código JavaScript, mas pode ser qualquer código do lado do cliente) para a saída do seu script PHP. Este ataque é possível quando você exibir a entrada que foi enviado para você, como você faria com uma mensagem do fórum, por exemplo. O atacante pode postar o código JavaScript em sua mensagem que faz coisas indescritíveis para o seu site. Por favor, não me faça entrar em detalhes, o meu coração chora o que esses bandidos são capazes.
Para mais informações e como se proteger, sugiro a leitura desses artigos finos no PHPMaster:
Ataques Cruz Scripting por George Fekette
Validação de entrada Usando Funções de filtro por Toby Osbourn
Revelação Código Fonte
Este tem a ver com as pessoas serem capazes de ver os nomes e conteúdo de arquivos que não devem em caso de uma avaria na configuração do Apache. Sim, eu cavo, é improvável que isso aconteça, mas que podia, e é bastante fácil de se proteger, por que não?
Nós todos sabemos que o PHP é do lado do servidor - você não pode apenas fazer uma fonte de visão para ver o código de um script. Mas se algo acontecer com Apache e, de repente, seus scripts são servidos como texto simples, as pessoas vêem o código-fonte que nunca foram feitos para ver. Alguns dos que o código pode listar arquivos de configuração acessíveis ou ter informações sensíveis, como as credenciais de banco de dados.
A solução gira em torno de como você definir a estrutura de diretórios para sua aplicação. Ou seja, ele não é tanto um problema que as pessoas ruins podem ver o código, é o código que eles podem ver se os arquivos sensíveis são mantidos em um diretório público. Manter arquivos importantes fora do diretório acessível ao público para evitar as conseqüências desse erro.
Para mais informações sobre este assunto, incluindo uma amostra do que sua estrutura de diretório pode parecer, ver ponto 5 deste artigo . Para discussão adicional sobre este assunto, consulte este fórum de discussão .
Inclusão de arquivos remoto
Segurem-se, enquanto eu tento explicar isso: inclusão remota de arquivos é quando arquivos remotos são incluídos no seu pedido. Muito profundo, não é? Mas por que isso é um problema? Como o arquivo remoto não é confiável. Ele poderia ter sido modificado de forma maliciosa para conter código que você não quer correr em sua aplicação.
Suponha que você tem uma situação onde o seu site em www.myplace.com inclui o www.goodpeople.com biblioteca / script.php. Uma noite, www.goodpeople.com está comprometida eo conteúdo do arquivo é substituído por código mal que irá lixo sua aplicação. Em seguida, alguém visitar o seu site, você puxa no código atualizado, e Bam! Assim como você parar com isso?
Felizmente, a fixação é relativamente simples. Tudo que você tem a fazer é ir para o seu php.ini e verifique as configurações dessas bandeiras.
allow_url_fopen - indica se os arquivos externos podem ser incluídos. O padrão é definir isto para 'on', mas você quer desligar isso.
allow_url_include - indica se o include () , require () , include_once () funções, e require_once () pode fazer referência a arquivos remotos. O padrão define esta fora, e definindo allow_url_fopen off força esta fora também.
Session Hijacking
Seqüestro de sessão é quando uma pessoa patife rouba e uso mais do ID da sessão, que é algo como uma chave para um cofre. Quando uma sessão é estabelecida entre um cliente e um servidor web, o PHP irá armazenar o ID da sessão em um cookie do lado do cliente, provavelmente chamado PHPSESSID. O envio da identificação com a solicitação de página dá acesso à informações de sessão persistiu no servidor (que preenche o super global $ _SESSION matriz).
Se alguém rouba uma chave de sessão, isso é ruim? E a resposta é: se você não está fazendo nada de importante nessa sessão, então a resposta é não. Mas se você está usando a sessão para autenticar um usuário, então seria permitir que alguma pessoa vil para assinar e entrar em coisas. Isto é particularmente ruim se o usuário é importante e tem um monte de autoridade.
Então como é que as pessoas roubam esses IDs de sessão e que pode decente, gente temente a Deus como nós fazer sobre isso?
IDs de sessão são comumente roubado através de um ataque XSS, evitando assim que os é uma coisa boa que produz benefícios duplos. Também é importante mudar o ID da sessão sempre que é prático. Isso reduz a janela do roubo. De dentro de PHP, você pode executar o session_regenerate_id () função para alterar o ID da sessão e notificar o cliente.
Para aqueles que usam PHP5.2 e acima (você está, não é?), Há um php.ini configuração que irá impedir JavaScript de ser dado acesso ao ID de sessão ( session.cookie.httponly ). Ou, você pode usar a função session_set_cookie_parms () .
IDs de sessão também podem ser vulneráveis do lado do servidor, se você estiver usando serviços de hospedagem compartilhada que armazenam informações de sessão em diretórios globalmente acessível, como / tmp . Você pode bloquear o problema simplesmente armazenar o seu ID de sessão em um local que apenas seus scripts podem acessar, seja em disco ou em um banco de dados.
Atravesse Request Forgery site
Falsificação de solicitação entre sites (CSRF), também conhecido como o Maverick Brett, ou Shawn Spencer, Gambit, envolve enganar o usuário, em vez inconsciente em emitir um pedido que é, digamos assim, não em seu melhor interesse. Mas ao invés de me acontecendo e em ataques sobre CSRF, consulte um exemplo notável de apenas que tipo de conteúdo que temos aqui na PHPMaster: Evitar Falsificações Cross-Site Request por Martin Psinas.
Diretório Traversal
Este ataque, como muitos dos outros, procura por um local onde a segurança não é tudo o que deveria ser, e quando se encontra um, ele faz com que arquivos sejam acessados que o proprietário não tinha planos de fazer publicamente acessível. É também conhecido como o ataque .. / (ponto, ponto, barra), o ataque de escalada, eo ataque retrocesso.
Existem algumas maneiras de se proteger contra esse ataque. O primeiro é para desejar muito, muito difícil que não vai acontecer com você. Às vezes, desejando em fadas e unicórnios vai ajudar. Às vezes isso não acontece. A segunda é definir o que as páginas podem ser retornados para uma determinada solicitação usando whitelisting. Outra opção é a de converter os caminhos de arquivo de caminhos absolutos e certifique-se que está referenciando os arquivos nos diretórios permitidos.
Resumo
Essas são as 10 melhores questões que, se você não for cuidadoso para evitar, pode permitir sua aplicação PHP de ser violada. Sim, 10. Contá-las ... 1, 2, 3 ... O quê? Você só contava 8? Ok, talvez 7. Bem, então, que mostra o quão facilmente você pode ser enganado, e eu não sou mesmo um dos bandidos!
Imagem via Fotolia
Nenhum comentário :
Postar um comentário