diff --git a/security/apache.xml b/security/apache.xml index c22c6c229..30de23980 100644 --- a/security/apache.xml +++ b/security/apache.xml @@ -1,6 +1,6 @@ - - + + Instalando como módulo do Apache @@ -19,7 +19,7 @@ Normalmente, uma vez que a segurança está estabelecida até esse ponto onde o - usuário do PHP (no caso, o usuário apache) tem pouco risco atribuído a ele, + usuário do PHP (no caso, o usuário Apache) tem pouco risco atribuído a ele, você descobre que o PHP não tem permissão de escrita nos diretórios dos usuários. Ou talvez tenha sido proibido de acessar ou alterar bancos de dados. Também foi proibido de escrever diff --git a/security/cgi-bin.xml b/security/cgi-bin.xml index 49fd23d47..2b071a14f 100644 --- a/security/cgi-bin.xml +++ b/security/cgi-bin.xml @@ -1,6 +1,6 @@ - - + + Instalando como binário CGI @@ -13,7 +13,7 @@ tipos diferentes de empacotadores CGI para criar ambientes chroot e setuid seguros para os scripts. Esta configuração geralmente envolve a instalação - do binário php executável para o diretório cgi-bin do servidor web. + do php executável para o diretório cgi-bin do servidor web. A CERT Advisory CA-96.11 recomenda não colocar nenhum interpretador em cgi-bin. Mesmo se o binário php possa ser usado como um interpretador autônomo, @@ -56,7 +56,7 @@ requisição redirecionada http://my.host/cgi-bin/php/secret/script.php. Infelizmente, se a requisição é dada originalmente nessa forma, - a checagem de permissão não é feita para o arquivo /secret/script.php, mas apenas para o arquivo /cgi-bin/php. Dessa maneira qualquer usuário que pode acessar Caso 3: configurando doc_root ou user_dir - Para incluir conteúdo ativo, como script e executáveis, nos - diretórios de documentos do servidor é algumas vezes considerada uma - prática insegura. Se, por conta de um erro de configuração, os scripts - não são executados mas mostrados como documentos HTML normais, isso - pode resultar em vazamento de propriedade intelectual ou informação - de segurança, como senhas. Portanto, muitos administradores preferem + Incluir conteúdo ativo como scripts e executáveis nos + diretórios de documentos do servidor web é algumas vezes considerada uma + prática insegura. Se, por conta de algum erro de configuração, os scripts + não forem executados mas mostrados como documentos HTML normais, isto + pode resultar em vazamento de propriedade intelectual ou de informações + de segurança, como senhas. Portanto, muitos administradores de sistemas preferem configurar outra estrutura de diretório para scripts que são acessíveis - apenas pelo CGI do PHP, e, portanto, sempre - interpretados e não enviados ao navegador. + somente através do CGI do PHP e assim serão sempre + interpretados e não mostrados no navegador. - Além disso, se o método para assegurar que as requisições não são + Além disso, se o método que assegura que as requisições não sejam redirecionadas, como descrito na seção anterior, não estiver disponível, é necessário configurar um - doc_root no script que - seja diferente do diretório raiz dos documentos do servidor web. + doc_root de scripts que + seja diferente do diretório raiz dos documentos web. - Você pode configurar a raiz de documentos dos scripts PHP pela + Você pode configurar a raiz dos documentos de script PHP pela diretiva de configuração doc_root no - arquivo de configuração, ou + arquivo de configuração ou você pode criar a variável de ambiente PHP_DOCUMENT_ROOT. Se ela existir, a versão CGI do PHP sempre construirá o nome de arquivo para ser aberto com esse doc_root e a informação de caminho na - requisição, para assegurar que nenhum script é executado fora desse - diretório (exceto por user_dir + requisição, para garantir que nenhum script seja executado fora deste + diretório (exceto pelo user_dir abaixo). @@ -170,7 +170,7 @@ AddHandler php-script .php indefinido, a única coisa controlando o arquivo aberto é doc_root. Abrir uma URL como http://my.host/~user/doc.php não resulta - em abrir um arquivo no diretório home de users, mas um arquivo + em abrir um arquivo no diretório padrão do usuário, mas um arquivo chamado ~user/doc.php dentro de doc_root (sim, um nome de diretório começando com til [~]). diff --git a/security/current.xml b/security/current.xml index 89dfb8ece..f1fcec14c 100644 --- a/security/current.xml +++ b/security/current.xml @@ -1,14 +1,14 @@ - - + + Mantendo-se Atualizado - PHP, como qualquer outro sistema grande, está sob constante revisão e + O PHP, como qualquer outro sistema grande, está sob constante revisão e melhoramento. Cada versão nova normalmente incluirá mudanças, sejam grandes ou pequenas, para melhorar a segurança e reparar falhas, erros de configuração, e outros problemas que podem afetar a segurança geral - e estabilidade do seu sistema. + e a estabilidade do seu sistema. Como outras linguagens de script e programas de nível de sistema, a melhor diff --git a/security/database.xml b/security/database.xml index 81bdc4f21..7619bf91d 100644 --- a/security/database.xml +++ b/security/database.xml @@ -1,5 +1,5 @@ - + Segurança de Bancos de Dados @@ -25,8 +25,8 @@ É preciso manter em mente essa regra simples: defesa em profundidade. Em quanto mais lugares há ações para aumentar a proteção do banco de dados, menor a probabilidade de um atacante ter sucesso em expor ou abusar de qualquer informação - guardada. Uma boa modelagem do esquema (schema) do banco de dados e da aplicação - para lidar com os maiores medos. + guardada. Uma boa modelagem do esquema do banco de dados e da aplicação + endereça as maiores preocupações. @@ -46,12 +46,12 @@ removendo seu conteúdo completamente. - Devem ser criados usuários de bancos de dados diferentes para cada aspecto + Podem ser criados diferentes usuários de bancos de dados para cada aspecto da sua aplicação com direitos bem limitados aos objetos do banco de dados. Apenas os privilégios necessários devem ser concedidos, e deve-se evitar que o mesmo usuário possa interagir com o banco de dados em casos de uso diferentes. Isso significa que se invasores conseguirem acessar seu banco de dados usando credenciais da sua - aplicação, eles só podem afetar o banco tanto quanto sua aplicação poderia. + aplicação, eles só poderão fazer as mesmas alterações que sua aplicação poderia. @@ -114,7 +114,7 @@ verifica se a senha fornecida corresponde ao hash armazenado no banco de dados. - Usando campo de senha hasheado + Usando campo de senha com hash - Se isso acontecesse, então o script daria de presente acesso de superusuário ao + Se isso acontecesse, o script concederia acesso de superusuário ao atacante. Perceba que 0; é para fornecer uma deslocamento válido para a consulta original e terminá-la. @@ -307,7 +307,7 @@ $result = mssql_query($query); ]]> - Se o atacante enviar o valor + Se um atacante enviar o valor a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- para $prod, então $query terá o valor: diff --git a/security/errors.xml b/security/errors.xml index e62f973aa..bbe943a5a 100644 --- a/security/errors.xml +++ b/security/errors.xml @@ -1,6 +1,6 @@ - - + + Relatando Erros @@ -30,8 +30,8 @@ Os erros do PHP que são retornados normalmente podem ser úteis para um desenvolvedor que está tentando depurar um script, indicando coisas - como a função ou arquivo que falhou, o arquivo PHP no qual a falha ocorreu, - e o número da linha de código causadora da falha. Toda essa informação + como a função ou arquivo que falhou, o arquivo PHP e + o número da linha onde a falha ocorreu. Toda essa informação pode ser explorada. Não é incomum para um desenvolvedor PHP usar show_source, highlight_string, ou @@ -67,23 +67,23 @@ sistema) enviando dados incorretos, ele pode ser capaz de determinar que um sistema foi feito com PHP. - - Uma função de erro pode indicar se o sistema pode está executando um - engine de banco de dados específico, ou dar dicas de como uma página foi - programada ou desenhada. Isso permite uma investigação profunda sobre - portas abertas de bancos de dados, ou procurar por bugs específicos ou fraquezas - de uma página. Enviando diferentes pedaços de dados ruins, por exemplo, - um atacante pode determinar a ordem de autenticação em um script, - (a partir da linha do erro) assim como sondar por exploits que - podem ser aproveitados em diferentes partes do script. - - - Um erro geral do PHP ou do sistema de arquivos indicam quais permissões + + Um erro de função pode indicar se um sistema está utilizando um + determinado mecanismo de banco de dados, ou como uma página da web foi + programada ou projetada. Isso possibilita uma investigação mais aprofundada sobre + portas de banco de dados abertas, ou a busca por falhas ou vulnerabilidades + específicas em uma página da web. Ao fornecer diferentes tipos de dados inválidos, por exemplo, + um invasor pode determinar a ordem de autenticação em um script + (por meio de erros que indicam o número da linha), bem como investigar a existência + de vulnerabilidades que possam estar presentes em diferentes partes do script. + + + Um erro geral do PHP ou do sistema de arquivos podem indicar quais permissões o servidor web tem, assim como a estrutura e organização dos arquivos no servidor web. Códigos de erros escritos pelo desenvolvedor podem - agravar o problema, levando à exploração fácil de informação até então + agravar este problema, levando à exploração fácil de informação até então "escondida". - + Existem três soluções principais para esse problema. A primeira é verificar exaustivamente todas as funções, e tentar compensar pelo volume dos diff --git a/security/filesystem.xml b/security/filesystem.xml index ccff16ac2..ace0ad06e 100644 --- a/security/filesystem.xml +++ b/security/filesystem.xml @@ -1,6 +1,6 @@ - - + + Segurança do Sistema de Arquivos @@ -145,7 +145,7 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us - + Dependendo do sistema operacional, existe uma variedade enorme de arquivos com os quais devemos nos preocupar, incluindo entradas de dispositivos (/dev/ ou COM1), arquivos de configuração (/etc/ @@ -153,7 +153,7 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us Meus Documentos), etc. Por este motivo, normalmente é mais fácil criar uma política onde se proíbe tudo exceto aquilo que for explicitamente permitido. - + Problemas relacionados aos bytes nulos @@ -162,7 +162,7 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us Como bytes nulos denotam fim de string em C, as strings que os contêm não serão consideradas de forma inteira, mas apenas até que um byte nulo ocorra. - O exemplo a seguir mostra um código vulnerável que demonstra esse problema: + O exemplo a seguir mostra o código vulnerável que demonstra esse problema: Script vulnerável a bytes nulos diff --git a/security/general.xml b/security/general.xml index 50402484a..65ee4d607 100644 --- a/security/general.xml +++ b/security/general.xml @@ -1,6 +1,6 @@ - - + + Considerações Gerais diff --git a/security/hiding.xml b/security/hiding.xml index df95e2771..0c7f8308e 100644 --- a/security/hiding.xml +++ b/security/hiding.xml @@ -1,18 +1,18 @@ - - + + Escondendo o PHP Em geral, segurança por obscuridade é uma das maneiras mais fracas de segurança. Mas em alguns casos, cada pequena medida de segurança extra é desejável. - + Algumas técnicas simples podem ajudar a esconder o PHP, possivelmente retardando um atacante que está tentando descobrir fraquezas no seu sistema. Configurar a diretiva expose_php para off no arquivo &php.ini;, reduz a quantidade de informação disponível aos atacantes. - + Outra tática é configurar o servidor web, como o Apache, para executar tipos de arquivos diferentes pelo PHP, ou por uma diretiva diff --git a/security/intro.xml b/security/intro.xml index b6af0b6bc..142a81189 100644 --- a/security/intro.xml +++ b/security/intro.xml @@ -1,5 +1,5 @@ - + Introdução diff --git a/security/variables.xml b/security/variables.xml index d923532ef..7f4c4e4e7 100644 --- a/security/variables.xml +++ b/security/variables.xml @@ -1,6 +1,6 @@ - - + + Dados Enviados pelo Usuário @@ -63,13 +63,13 @@ exec ($evil_var); - + Respondendo essas perguntas adequadamente enquanto escrevendo o script, ao invés de depois, previne a reescrita indesejada quando você precisar aumentar a segurança. Começando com essa linha de raciocí­nio, você não garante a segurança do seu sistema, mas pode ajudar a aumentá-la. - + Melhore a segurança desabilitando configurações de conveniência que obscurecem a origem, validade ou integridade dos dados de entrada. A criação implícita de variáveis @@ -83,13 +83,13 @@ exec ($evil_var); escapando dados inconsistentemente. Embora não esteja mais no PHP, riscos semelhantes persistem se o tratamento de entrada for mal gerenciado. - + Habilite error_reporting(E_ALL) para ajudar a detectar variáveis ​​não inicializadas e validar a entrada. Use tipos estritos (declare(strict_types=1), introduzido no PHP 7) para reforçar a segurança de tipos, evitar conversões de tipos não intencionais e melhorar a segurança geral. - +