Update security/ with last en rev

security/apache.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, fabioluciano, leonardolara -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
    <title>Instalando como módulo do Apache</title>
    <simpara>
@@ -19,7 +19,7 @@
    </simpara>
    <simpara>
     Normalmente, uma vez que a segurança está estabelecida até esse ponto onde o
-    usuário do <acronym>PHP</acronym> (no caso, o usuário apache) tem pouco risco atribuído a ele,
+    usuário do <acronym>PHP</acronym> (no caso, o usuário Apache) tem pouco risco atribuído a ele,
     você descobre que o <acronym>PHP</acronym> 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

security/cgi-bin.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 330a38c4d45556b49e06ebe6d39e0e311534cd8c Maintainer: leonardolara Status: ready --><!-- CREDITS: #lisaldo,narigone,ae,leonardolara-->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: #lisaldo,narigone,ae,leonardolara-->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
    <title>Instalando como binário CGI</title>
 
@@ -13,7 +13,7 @@
      tipos diferentes de empacotadores <acronym>CGI</acronym> para criar ambientes
      <command>chroot</command> e <command>setuid</command> seguros
      para os scripts. Esta configuração geralmente envolve a instalação
-     do binário <command>php</command> executável para o diretório <filename class="directory">cgi-bin</filename> do servidor web.
+     do <command>php</command> executável para o diretório <filename class="directory">cgi-bin</filename> do servidor web.
      A CERT Advisory <link xlink:href="&url.cert;">CA-96.11</link> recomenda
      não colocar nenhum interpretador em <filename class="directory">cgi-bin</filename>.
      Mesmo se o binário <command>php</command> possa ser usado como um interpretador autônomo,
@@ -56,7 +56,7 @@
        requisição redirecionada <filename
        role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
        Infelizmente, se a requisição é dada originalmente nessa forma,
-       a checagem de permissão não é feita para o arquivo <filename
+       nenhuma verificação de acesso é realizada pelo servidor web para o arquivo <filename
        role="uri">/secret/script.php</filename>, mas apenas para o arquivo
        <filename role="uri">/cgi-bin/php</filename>. Dessa maneira
        qualquer usuário que pode acessar <filename
@@ -135,33 +135,33 @@ AddHandler php-script .php
    <sect1 xml:id="security.cgi-bin.doc-root">
     <title>Caso 3: configurando doc_root ou user_dir</title>
     <simpara>
-     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.
     </simpara>
     <simpara>
-     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
-     <link linkend="ini.doc-root">doc_root</link> no script que
-     seja diferente do diretório raiz dos documentos do servidor web.
+     <link linkend="ini.doc-root">doc_root</link> de scripts que
+     seja diferente do diretório raiz dos documentos web.
     </simpara>
     <simpara>
-     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 <link linkend="ini.doc-root">doc_root</link> no
-     <link linkend="configuration.file">arquivo de configuração</link>, ou
+     <link linkend="configuration.file">arquivo de configuração</link> ou
      você pode criar a variável de ambiente
      <envar>PHP_DOCUMENT_ROOT</envar>. Se ela existir, a versão <acronym>CGI</acronym>
      do PHP sempre construirá o nome de arquivo para ser aberto com esse
      <parameter>doc_root</parameter> e a informação de caminho na
-     requisição, para assegurar que nenhum script é executado fora desse
-     diretório (exceto por <parameter>user_dir</parameter>
+     requisição, para garantir que nenhum script seja executado fora deste
+     diretório (exceto pelo <parameter>user_dir</parameter>
      abaixo).
     </simpara>
     <simpara>
@@ -170,7 +170,7 @@ AddHandler php-script .php
      indefinido, a única coisa controlando o arquivo aberto é
      <parameter>doc_root</parameter>. Abrir uma URL como <filename
      role="url">http://my.host/~user/doc.php</filename> 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 <filename role="uri">~user/doc.php</filename> dentro de
      <parameter>doc_root</parameter> (sim, um nome de diretório começando com til
      [<literal>~</literal>]).

security/current.xml

@@ -1,14 +1,14 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: narigone Status: ready -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, leonardoalara -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.current" xmlns="http://docbook.org/ns/docbook">
    <title>Mantendo-se Atualizado</title>
    <simpara>
-    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.
    </simpara>
    <simpara>
     Como outras linguagens de script e programas de nível de sistema, a melhor

security/database.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 0009ebd09f938e8f066779bb9bb774baed10bd8a Maintainer: leonardolara Status: ready --><!-- CREDITS: rafaelbernard,narigone,ae,leonardolara -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: rafaelbernard,narigone,ae,leonardolara -->
   <chapter xml:id="security.database" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
    <title>Segurança de Bancos de Dados</title>
 
@@ -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.
    </simpara>
 
    <sect1 xml:id="security.database.design">
@@ -46,12 +46,12 @@
       removendo seu conteúdo completamente.
      </simpara>
      <simpara>
-      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.
      </simpara>
    </sect1>
 
@@ -114,7 +114,7 @@
       verifica se a senha fornecida corresponde ao hash armazenado no banco de dados.
      </simpara>
      <example>
-      <title>Usando campo de senha hasheado</title>
+      <title>Usando campo de senha com hash</title>
       <programlisting role="php">
 <![CDATA[
 <?php
@@ -191,7 +191,7 @@ insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
 ]]>
        </programlisting>
       </informalexample>
-      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 <literal>0;</literal> é para fornecer uma deslocamento válido
       para a consulta original e terminá-la.
     </para>
@@ -307,7 +307,7 @@ $result = mssql_query($query);
 ]]>
       </programlisting>
      </example>
-     Se o atacante enviar o valor
+     Se um atacante enviar o valor
      <literal>a%' exec master..xp_cmdshell 'net user test testpass /ADD' --</literal>
      para <varname>$prod</varname>, então <varname>$query</varname> terá o valor:
      <informalexample>

security/errors.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: ae725a44023db78b9f6e9d2a0baac8c8dc337d38 Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, fabioluciano -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, fabioluciano -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
    <title>Relatando Erros</title>
    <para>
@@ -30,8 +30,8 @@
    <para>
     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 <function>show_source</function>,
     <function>highlight_string</function>, ou
@@ -67,23 +67,23 @@
     sistema) enviando dados incorretos, ele pode ser capaz de
     determinar que um sistema foi feito com PHP.
    </para>
-   <para>
-    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.
-   </para>
-   <para>
-    Um erro geral do PHP ou do sistema de arquivos indicam quais permissões
+   <simpara>
+    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.
+   </simpara>
+   <simpara>
+    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".
-   </para>
+   </simpara>
    <para>
     Existem três soluções principais para esse problema. A primeira é
     verificar exaustivamente todas as funções, e tentar compensar pelo volume dos

security/filesystem.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 91570644fbbe4d23e79908e1a04c4c4d003fe587 Maintainer: leonardolara Status: ready --><!-- CREDITS: rafaelbernard,narigone,leonardolara -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: rafaelbernard,narigone,leonardolara -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.filesystem" xmlns="http://docbook.org/ns/docbook">
    <title>Segurança do Sistema de Arquivos</title>
    <simpara>
@@ -145,15 +145,15 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us
      </programlisting>
     </example>
    </para>
-   <para>
+   <simpara>
     Dependendo do sistema operacional, existe uma variedade enorme de arquivos
     com os quais devemos nos preocupar, incluindo entradas de dispositivos (<filename>/dev/</filename>
     ou <filename>COM1</filename>), arquivos de configuração (<filename>/etc/</filename>
     e <literal>.ini</literal>), áreas de armazenamento de arquivo bem conhecidas (<filename>/home/</filename>,
     <filename>Meus Documentos</filename>), etc. Por este
     motivo, normalmente é mais fácil criar uma política onde se proíbe
     tudo exceto aquilo que for explicitamente permitido.
-   </para>
+   </simpara>
    <sect1 xml:id="security.filesystem.nullbytes">
     <title>Problemas relacionados aos bytes nulos</title>
     <simpara>
@@ -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:
     </simpara>
     <example>
      <title>Script vulnerável a bytes nulos</title>

security/general.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: narigone Status: ready -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, leonardolara -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.general" xmlns="http://docbook.org/ns/docbook">
    <title>Considerações Gerais</title>
    <simpara>

security/hiding.xml

@@ -1,18 +1,18 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: narigone Status: ready --><!-- CREDITS: narigone, rafaelbernard -->
-<!---->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, rafaelbernard, leonardolara -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
   <chapter xml:id="security.hiding" xmlns="http://docbook.org/ns/docbook">
    <title>Escondendo o PHP</title>
    <para>
     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.
    </para>
-   <para>
+   <simpara>
     Algumas técnicas simples podem ajudar a esconder o <acronym>PHP</acronym>, possivelmente retardando
     um atacante que está tentando descobrir fraquezas no seu
     sistema. Configurar a diretiva expose_php para <literal>off</literal> no
     arquivo &php.ini;, reduz a quantidade de informação disponível aos atacantes.
-   </para>
+   </simpara>
    <para>
     Outra tática é configurar o servidor web, como o Apache, para
     executar tipos de arquivos diferentes pelo <acronym>PHP</acronym>, ou por uma diretiva

security/intro.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: 96c9d88bad9a7d7d44bfb7f26c226df7ee9ddf26 Maintainer: fabioluciano Status: ready --><!-- CREDITS: narigone, fabioluciano -->
+<!-- EN-Revision: f5b71e9150fddd14fa56c3c8f7197ef08e966c0b Maintainer: leonardolara Status: ready --><!-- CREDITS: narigone, fabioluciano, leonardolara -->
 <!-- splitted from ./index.xml, last change in rev 1.66 -->
  <chapter xml:id="security.intro" xmlns="http://docbook.org/ns/docbook">
   <title>Introdução</title>