Skip to content

Commit

Permalink
translation progress database.xml
Browse files Browse the repository at this point in the history
  • Loading branch information
@ManueldG
ManueldG committed Feb 23, 2025
1 parent 6c50039 commit ec14079
Showing 1 changed file with 53 additions and 73 deletions.
126 changes: 53 additions & 73 deletions security/database.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand All @@ -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>
Expand All @@ -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>
Expand All @@ -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
Expand All @@ -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>
Expand All @@ -117,7 +117,8 @@
<example>
<title>Campo per l'Hash della password</title>
<programlisting role="php">
<![CDATA[
<!--tradurre-->
<![CDATA[
<?php
// storing password hash
Expand Down Expand Up @@ -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[
Expand Down Expand Up @@ -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[
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -462,25 +452,15 @@ $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
ogni valore non numerico fornito dall'utente che viene passato al
database va messo tra virgolette <!--quote--> 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>
Expand Down

0 comments on commit ec14079

Please sign in to comment.