translation progress database.xml

Author: ManueldG

security/database.xml

@@ -6,8 +6,8 @@
 
    <simpara>
     Al giorno d'oggi, i database sono componenti essenziali di qualsiasi
-    applicazione basata sul Web, consentendo ai siti Web di fornire vari contenuti
-    dinamici. Poiché anche le informazioni molto sensibili o segrete possono
+    applicazione basata sul Web, consentendo ai siti Web di fornire molti contenuti
+    dinamici. Poiché anche le informazioni sensibili o segrete possono
     essere archiviate in un database, dovresti prendere seriamente in considerazione di 
     protegere i tuoi database.
    </simpara>
@@ -16,16 +16,16 @@
     eseguire una query, recuperare il risultato e quindi chiudere la connessione.
     Oggigiorno, il linguaggio più utilizzato per questo tipo di interazione è 
     l'SQL (Structured Query Language). Di seguito viene mostrato come un'aggressore può <link
-    linkend="security.database.sql-injection">manomettere una query SQL</link>.
+    linkend="security.database.sql-injection">manometterelo con una query SQL</link>.
    </simpara>
    <simpara>
-    Come si può immaginare, <acronym>PHP</acronym> non può proteggere il database da solo. 
+    Da come si può immaginare, <acronym>PHP</acronym> non può proteggere da solo il database. 
     Le prossime sezioni puntano a introdurre le modalità di come
     accedere e manipolare ai database all'interno di uno script <acronym>PHP</acronym>.
    </simpara>
    <simpara>
     Bisogna tener presente questa semplice regola: (Defense in Depth) difesa in profondità. Più prendi provvedimenti
-    per aumentare la protezione del database, minore è probabilità che un utente malintenzionato
+    per aumentare la sicurezza del database, minore è probabilità che un utente malintenzionato
     riesca ad accedere o abusare di eventuali dati archiviati. Una buona progettazione
     dello schema del database e dell'applicazione previene le tue più grandi paure.
    </simpara>
@@ -34,15 +34,15 @@
     <title>Progetazione del database</title>
      <simpara>
       Il primo passo è quello di creare il database, a meno che non si voglia utilizzarne uno
-      di terze parti. Una volta creato il database, gli viene assegnato a un proprietario, 
-      che ha eseguito l'istruzione di creazione. Di solito, solo il proprietario 
-      (o un superuser) può fare qualsiasi cosa con gli oggetti in quel database e, 
+      di terze parti. Una volta creato il database, viene assegnato un proprietario, 
+      a chi ha eseguito l'istruzione di creazione. Di solito, solo il proprietario 
+      (o l'amministratore) può fare qualsiasi cosa con gli oggetti di quel database e, 
       per consentire ad altri utenti di utilizzarlo, gli devono essere concessi dei privilegi.
      </simpara>
      <simpara>
       Le applicazioni non dovrebbero mai connettersi al database come proprietario o 
-      superutente, perché questi utenti possono eseguire qualsiasi query a piacimento, 
-      ad esempio, potrebbero modificare lo schema (ad esempio eliminando tabelle) o potrebbero 
+      amministratore, poichè questi utenti possono eseguire qualsiasi query a piacimento, 
+      ad esempio, potrebbero modificare lo schema (ad esempio eliminando le tabelle) o potrebbero 
       eliminare l'intero contenuto.
      </simpara>
      <simpara>
@@ -51,28 +51,28 @@
       solo i privilegi necessari per evitare che lo stesso utente possa modificare
       il database tramite le diverse funzionalità. Ciò significa che se gli intrusi ottengono 
       l'accesso al tuo database utilizzando le credenziali delle tue applicazioni, 
-      potrebbero apportare tutte le modifiche quante ne sono previsti dai privilegi.
+      potrebbero apportare tutte le modifiche quante ne sono previste dai privilegi.
      </simpara> 
    </sect1>
 
    <sect1 xml:id="security.database.connection">
     <title>Connessione al database</title>
     <simpara>
-     E' possibile stabilire connessioni SSL per crittografare le
-     comunicazioni client/server per una maggiore sicurezza oppure è possibile utilizzare SSH
+     E' possibile per una maggiore sicurezza stabilire connessioni SSL per criptare le
+     comunicazioni client/server oppure è possibile utilizzare SSH
      per criptare la connessione di rete tra i client e il server del database.
-     Se viene utilizzato uno di questi sistemi, monitorare il traffico e ottenere
-     le informazioni sul tuo database saranno difficili da parte di un potenziale malintenzionato.
+     Se viene utilizzato uno di questi sistemi, sarà difficile monitorare il traffico e ottenere
+     le informazioni del tuo database da parte di un potenziale malintenzionato.
     </simpara>
     <simpara>
-     Se il tuo server database ha il supporto SSL nativo, considera l'utilizzo delle <link
-     linkend="ref.openssl">Funzioni OpenSSL</link> nelle comunicazioni tra
+     Se il server del database ha il supporto nativo SSL, si può considerare l'uso delle funzioni <link
+     linkend="ref.openssl">OpenSSL</link> per comunicazioni tra
      <acronym>PHP</acronym> e database tramite SSL.
-    </simpara><!-- XXX  (livelli ruoli)-->
+    </simpara>
    </sect1>
 
-   <sect1 xml:id="security.database.storage"> <!-- tradurlo o lasciarlo in Inglese? -->
-    <title>Modello d'archiviazione crittografato - Encrypted Storage Model</title>
+   <sect1 xml:id="security.database.storage"> <!-- tradurlo o lasciarlo in Inglese? - Encrypted Storage Model-->
+    <title>Modello d'archiviazione crittografato</title>
     <simpara>
      SSL/SSH protegge i dati che viaggiano dal client al server: SSL/SSH
      non protegge i dati persistenti archiviati in un database. SSL è un
@@ -85,24 +85,24 @@
      è un buon modo per limitare questa minaccia, ma pochissimi database offrono
      questo tipo di crittografia dei dati.
     </simpara>
-    <simpara> <!--XXX pacchetto?? classe libreria   -->
-     Il modo più semplice per aggirare questo problema è innanzitutto creare il proprio pacchetto di crittografia,
+    <simpara> <!--XXX pacchetto?? classe libreria funzione   -->
+     Il modo più semplice per aggirare il problema è innanzitutto creare il proprio pacchetto di crittografia,<!-- classe o funzione-->
      e quindi utilizzarlo nei tuoi script <acronym>PHP</acronym>. <acronym>PHP</acronym>
      può aiutarti con diverse estensioni, come <link
-     linkend="book.openssl">OpenSSL</link> e <link
-     linkend="book.sodium">Sodium</link>, che copre un'ampia varietà di algoritmi di crittografia. 
+     linkend="book.openssl">OpenSSL</link> o <link
+     linkend="book.sodium">Sodium</link>, che impiega un'ampia varietà di algoritmi di crittografia. <!-- vanta usa impiega-->
      Lo script cripta i dati prima di inserirli nel database e li decripta
      durante il recupero. Vedere i riferimenti per ulteriori esempi 
-     su come funziona la crittografia.<!-- XXX 1 controllo -->
+     su come funziona la crittografia.
     </simpara>
 
     <sect2 xml:id="security.database.storage.hashing">
     <title>Hashing</title>
      <simpara>
-      Nel caso di dati veramente nascosti(estremamente /privati- segreti- ), se non è necessaria la loro rappresentazione grezza(originale - in chiaro )
+      Nel caso di dati veramente segreti <!--estremamente /privati- segreti -->, se non è necessaria la loro rappresentazione originale <!--originale - in chiaro - grezza -->
       (p.es. non dev'essere visualizzato), è necessario prendere in considerazione l'hashing.
-      L'esempio ben noto di hashing è la memorizzazione della password criptata tramite hashing 
-      (è il salvataggio dell'hash della password) nel database, 
+      Un'esempio ben noto di hashing <!-- è la memorizzazione della password criptata tramite hashing  -->
+      è il salvataggio dell'hash della password nel database, 
       invece della password stessa.
      </simpara>
      <simpara>
@@ -117,7 +117,8 @@
      <example> 
       <title>Campo per l'Hash della password</title>
       <programlisting role="php">
-<![CDATA[
+      <!--tradurre-->
+<![CDATA[ 
 <?php
 
 // storing password hash
@@ -146,23 +147,23 @@ if ($row && password_verify($password, $row['pwd'])) {
    <sect1 xml:id="security.database.sql-injection">
     <title>SQL Injection</title>
     <simpara>
-     L'SQL injection è una tecnica dove un utente malintenzionato sfrutta i difetti del
+     L'SQL injection è una tecnica dove un'utente malintenzionato sfrutta i difetti del
      codice 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 <!-- sarebbe macchina host-->
-     ospite(host). La vulnerabilità si verifica quando gli sviluppatori concatenano o
+     o addirittura eseguire comandi pericolosi a livello di sistema Host dul database. 
+     La vulnerabilità si verifica quando gli sviluppatori concatenano o
      interpolano dati arbitrari nelle loro istruzioni SQL.
     </simpara>
     <para>
      <example>
-      <title> <!-- XXX 1 controllo -->
-       Dividere il set di risultati in pagine ... e creare superutenti <!-- amministratori -->
+      <title> 
+       Dividere il set di risultati in pagine ... e creare amministratori <!-- amministratori -->
        (PostgreSQL)
       </title>
       <simpara>
-       Nell'esempio seguente, l'input dell'utente viene interpolato <!--binding--> direttamente nella
-       Query SQL che consente all'aggressore di ottenere un account superuser <!--amministratore--> nel database.
+       Nell'esempio seguente, l'input dell'utente viene interpolato direttamente nella
+       Query SQL che consente all'aggressore di ottenere un account amministratore nel database.
       </simpara>
       <programlisting role="php">
 <![CDATA[
@@ -197,33 +198,22 @@ insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
     </para>
     <note>
      <para>
-      È una tecnica comune per forzare il parser SQL a ignorare il resto del file <!--della richiesta-->
-      con una query scritta dal programmatore con <literal>--</literal> che introduce <!-- con \-\- inserisce i commenti in sql -->
+      Una tecnica comune per forzare il parser SQL a ignorare il resto della richiesta
+      query scritta dal programmatore è usare <literal>--</literal> che introduce <!-- con \-\- inserisce i commenti in sql -->
       i commenti in SQL.
      </para>
     </note>
     <para>
      Un modo possibile per ottenere le password è analizzare le pagine dei risultati di ricerca.
      L'unica cosa che l'attaccante deve fare è vedere se sono presenti variabili inviate
-     utilizzate nelle istruzioni SQL che non vengono gestite correttamente. Questi filtri possono essere impostati
-     comunemente in una forma personalizzata di <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 <!-- in modo da -->
-     password da una tabella arbitraria. <!-- è fortemente consigliato salvare/inserire solola chiave hash -->Si consiglia vivamente di salvare sole le secure hash delle password 
+     utilizzate nelle istruzioni SQL che non vengono gestite correttamente. Questi filtri di solito possono essere impostati
+     in un form usato precedentemente e personalizzarlo usando le clausule <literal>WHERE, ORDER BY,
+     LIMIT</literal> e <literal>OFFSET</literal> nell'istruzione <literal>SELECT</literal>. 
+     Se il database supporta il costrutto <literal>UNION</literal>,
+     l'aggressore potrebbe tentare di aggiungere un'intera query a quella originale per far elencare <!-- in modo da -->
+     le password da una tabella arbitraria. <!-- è fortemente consigliato salvare/inserire solola chiave hash -->Si consiglia vivamente di salvare sole le secure 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
-     commonly in a preceding form to customize <literal>WHERE, ORDER BY,
-     LIMIT</literal> and <literal>OFFSET</literal> clauses in <literal>SELECT</literal>
-     statements. If your database supports the <literal>UNION</literal> construct,
-     the attacker may try to append an entire query to the original one to list
-     passwords from an arbitrary table. It is strongly recommended to store only
-     secure hashes of passwords instead of the passwords themselves.
-     <example>
+     <example> <!-- XXX controllo -->
       <title>Elencare gli articoli... e alcune password (può essere usato su qualunque database server).</title>
       <programlisting role="php">
 <![CDATA[
@@ -237,8 +227,8 @@ $result = odbc_exec($conn, $query);
 ]]>
       </programlisting>
      </example>
-     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:-->
+     La parte statica della query può essere combinata con un'altra <literal>SELECT</literal>
+     che rivela tutte le password: <!-- statement which reveals all passwords:-->
      <informalexample>
       <programlisting role="sql">
 <![CDATA[
@@ -404,8 +394,8 @@ $stmt->execute(["%{$productId}%"]);
      </para>
 
      <simpara>
-      Le Prepared statement Sono fornite.
-      <link linkend="pdo.prepared-statements">da PDO</link>,
+      Le Prepared statement Sono fornite. Da
+      <link linkend="pdo.prepared-statements">PDO</link>,
       <link linkend="mysqli.quickstart.prepared-statements">da MySQLi</link>,
       e da altre librerie per database.
      </simpara>     
@@ -450,7 +440,7 @@ $stmt->execute(["%{$productId}%"]);
        <listitem>
         <simpara>
          Se l'applicazione prevede un input numerico, prendi in considerazione la verifica dei dati
-         con <function>ctype_digit</function>, modifica silenziosamente il suo tipo
+         con <function>ctype_digit</function>, modificare con discrezione il suo tipo
          usando <function>settype</function> o usa la sua rappresentazione numerica
          con <function>sprintf</function>.
 
@@ -462,31 +452,22 @@ $stmt->execute(["%{$productId}%"]);
        </listitem>
        <listitem>
         <simpara>
-         Se il livello del database non supporta variabili di binding, allora
-         cita <!--quota--> ogni valore non numerico fornito dall'utente che viene passato al
-         database con la funzione di escape della stringa specifica del database (ad esempio
+         Se il livello<!--l' interfaccia --> del database non supporta il binding delle variabili, allora
+         va messo tra virgolette <!--quote--> ogni valore non numerico fornito dall'utente che viene passato al
+         database con la specifica funzione di escape del database per le stringhe (ad esempio
          <function>mysql_real_escape_string</function>,
          <function>sqlite_escape_string</function>, ecc.).
          Le funzioni generiche come <function>addslashes</function> sono utili solo
-         in un ambiente molto specifico (ad esempio MySQL in un set di caratteri a singolo byte
-         con <varname>NO_BACKSLASH_ESCAPES</varname> disabilitato), quindi è
+         in un ambiente molto specifico<!--limitato--> (ad esempio MySQL in un set di caratteri a singolo byte
+         con <varname>NO_BACKSLASH_ESCAPES</varname> disabilitato)e quindi è
          meglio evitarle.
-
-         If the database layer doesn't support binding variables then
-         quote each non-numeric user-supplied value that is passed to the
-         database with the database-specific string escape function (e.g.
          <function>mysql_real_escape_string</function>,
-         <function>sqlite_escape_string</function>, etc.).
-         Generic functions like <function>addslashes</function> are useful only
-         in a very specific environment (e.g. MySQL in a single-byte character
-         set with disabled <varname>NO_BACKSLASH_ESCAPES</varname>), so it is
-         better to avoid them.
         </simpara>
        </listitem>
        <listitem>
         <simpara>
-         Non stampare <!-- far visualizare -->informazioni specifiche del database, in particolare
-         sullo schema<!-- struttura -->, con mezzi leciti o illeciti. Vedere anche la <link
+         Non far visualizare informazioni specifiche del database, in particolare
+         lo schema <!-- la struttura -->, <!--con mezzi leciti o illeciti-->a qualunque costo. Vedere anche la sezione <link
          linkend="security.errors">Segnalazione degli errori</link> e <link
          linkend="ref.errorfunc">Funzioni di gestione e registrazione degli errori</link>.
         </simpara>
@@ -496,8 +477,8 @@ $stmt->execute(["%{$productId}%"]);
 
      <simpara>
       Oltre a ciò, puoi trarre vantaggio dal log <!-- cronologia - report - log - traccia- traking --> delle query da parte del tuo script
-      o dal database stesso, se lo supporta. Ovviamente, il log non è in grado
-      di prevenire alcun tentativo dannoso, ma può essere utile per risalire a quale
+      o, se lo supporta, dal database stesso. Ovviamente, il log non è in grado
+      di prevenire alcun tentativo d'attacco, ma può essere utile per capire quale
       applicazione è stata colpita. Il registro non è utile di per sé, ma
       sono utili le informazioni che contiene. Generalmente più dettagli ci sono nel log meglio è.
      </simpara><!--XXX traduzione da sistemare -->