mod security/database.xml

Author: ManueldG

security/database.xml

@@ -115,7 +115,7 @@
       controlla se la password fornita corrisponde all'hash memorizzato nel database.
      </simpara>
      <example><!--XXX tradotto ricontrollare-->
-      <title>Hashing password field</title>
+      <title>Campo per l'Hash della password</title>
       <programlisting role="php">
 <![CDATA[
 <?php
@@ -143,17 +143,16 @@ if ($row && password_verify($password, $row['pwd'])) {
      </example>
     </sect2>
    </sect1>
-<!--XXX tradurre-->
    <sect1 xml:id="security.database.sql-injection">
     <title>SQL Injection</title>
     <simpara>
-     L'SQL injection è una tecnica in cui un utente malintenzionato sfrutta i difetti del file
+     L'SQL injection è una tecnica dove un utente malintenzionato sfrutta i difetti del
      codice dell'applicazione responsabile della creazione di query SQL dinamiche.
      L'aggressore può accedere a sezioni privilegiate dell'applicazione,
      recuperare tutte le informazioni dal database, manomettere i dati esistenti,
      o addirittura eseguire comandi pericolosi a livello di sistema sul database
-     ospite. La vulnerabilità si verifica quando gli sviluppatori concatenano o
-     interpolare input arbitrari nelle loro istruzioni SQL.
+     ospite(host). La vulnerabilità si verifica quando gli sviluppatori concatenano o
+     interpolano input(dati) arbitrari nelle loro istruzioni SQL.
 
      SQL injection is a technique where an attacker exploits flaws in
      application code responsible for building dynamic SQL queries.
@@ -166,10 +165,13 @@ if ($row && password_verify($password, $row['pwd'])) {
     <para>
      <example>
       <title>
-       Splitting the result set into pages ... and making superusers
+       Dividere il set di risultati in pagine ... e creare superutenti<!--XXX tradurre-->
        (PostgreSQL)
       </title>
       <simpara>
+       Nell'esempio seguente, l'input dell'utente viene interpolato (binding) direttamente nel
+       Query SQL che consente all'aggressore di ottenere un account superutente nel database.
+
        In the following example, user input is directly interpolated into the
        SQL query allowing the attacker to gain a superuser account in the database.
       </simpara>
@@ -200,18 +202,37 @@ insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
 ]]>
        </programlisting>
       </informalexample>
+      Se ciò dovesse accadere, lo script presenterebbe un accesso da superutente all'aggressore.
+      Tieni presente che <literal>0;</literal> fornisce un offset valido a
+      query originale e per terminarla.
+
       If it happened, the script would present a superuser access to the attacker.
       Note that <literal>0;</literal> is to supply a valid offset to the
       original query and to terminate it.
     </para>
     <note>
      <para>
+      È una tecnica comune forzare il parser SQL a ignorare il resto del file
+      query scritta dallo sviluppatore con <literal>--</literal> che è il
+      segno di commento in SQL.
+
       It is a common technique to force the SQL parser to ignore the rest of the
       query written by the developer with <literal>--</literal> which is the
       comment sign in SQL.
      </para>
     </note>
     <para>
+     Un modo fattibile per ottenere password è aggirare le pagine dei risultati di ricerca.
+     L'unica cosa che l'attaccante deve fare è vedere se sono presenti variabili inviate
+     utilizzato nelle istruzioni SQL che non vengono gestite correttamente. Questi filtri possono essere impostati
+     comunemente in una forma precedente per personalizzare <literal>WHERE, ORDER BY,
+     Clausole LIMIT</literal> e <literal>OFFSET</literal> in <literal>SELECT</literal>
+     dichiarazioni. Se il tuo database supporta il costrutto <literal>UNION</literal>,
+     l'aggressore potrebbe tentare di aggiungere un'intera query a quella originale da elencare
+     password da una tabella arbitraria. Si consiglia vivamente di conservare solo
+     proteggere gli hash delle password anziché le password stesse.
+
+
      A feasible way to gain passwords is to circumvent your search result pages.
      The only thing the attacker needs to do is to see if there are any submitted variables
      used in SQL statements which are not handled properly. These filters can be set
@@ -223,7 +244,7 @@ insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
      secure hashes of passwords instead of the passwords themselves.
      <example>
       <title>
-       Listing out articles ... and some passwords (any database server)
+       Elenco degli articoli... e alcune password (qualsiasi server di database) - Listing out articles ... and some passwords (any database server)
       </title>
       <programlisting role="php">
 <![CDATA[
@@ -237,8 +258,8 @@ $result = odbc_exec($conn, $query);
 ]]>
       </programlisting>
      </example>
-     The static part of the query can be combined with another
-     <literal>SELECT</literal> statement which reveals all passwords:
+     La parte statica della query può essere combinata con un'altra - The static part of the query can be combined with another
+     <literal>SELECT</literal>dichiarazione che rivela tutte le password: - statement which reveals all passwords:
      <informalexample>
       <programlisting role="sql">
 <![CDATA[