it-swarm-eu.dev

Come crittografare le credenziali di connessione al database su un server Web?

OWASP sconsiglia di archiviare le credenziali DB in testo semplice:

https://www.owasp.org/index.php/Password_in_Configuration_File

Tuttavia, non forniscono suggerimenti su come crittografare le credenziali di accesso al DB, dove archiviare le chiavi, come gestire l'accesso alle chiavi, ecc.

Qualcuno ha qualche esperienza reale nell'implementazione di una tale soluzione che può suggerire un'architettura su uno stack LAMP (ubuntu 10, PHP 5.3)?

PS: non cerco risposte sulla falsariga di "non preoccuparti - se qualcuno ottiene l'accesso alla radice è troppo tardi", ecc.

26
tom

Le altre risposte qui sono tutte corrette in un paio di aspetti chiave. Il file contenente la stringa di connessione non deve essere conservato in una posizione leggibile in tutto il mondo e, come noterai, non puoi impedire a qualcuno di ottenere la chiave se hanno compromesso il tuo server. Anche così, ci sono altri motivi per crittografare la chiave (o il file). Parte del motivo per cui OWASP sconsiglia di archiviare in testo normale è impedire la divulgazione accidentale delle credenziali a coloro che non ne hanno bisogno.

Mentre molti sottolineano che la crittografia della stringa di connessione sul sistema in esecuzione fornisce poco valore effettivo (sicurezza per oscurità), ciò è vero soprattutto nel contesto del sistema live. Supponendo una configurazione LAMP tradizionale, le autorizzazioni basate su file impedirebbero la lettura da parte di qualsiasi utente diverso dall'utente di script in cui è in esecuzione il processo php/Apache. Avere il file al di fuori della posizione di root offre un po 'più potenziale di sicurezza (in caso di gestori MIME o htaccess non configurati correttamente) ma non è strettamente necessario.

Il valore più grande nel separare le impostazioni di connessione è che i dettagli e i dati di autenticazione non devono più essere consegnati a sviluppatori/tester o altre persone che potrebbero avere una reale necessità di connettersi al server. Mantenendo i dettagli della connessione fuori dal controllo del codice sorgente e dalla distribuzione generale, si riduce la possibilità di perdita o perdita.

Un secondo vantaggio è la distribuzione e il backup dell'origine. Certamente una buona pratica sarebbe quella di trasferire solo i file contenenti connessioni sensibili e le informazioni sull'account crittografate da soli, ma per molte ragioni, questo non è sempre pratico. A causa di ciò, se si utilizza la crittografia, separare la chiave dalla stringa di connessione e separare la stringa di connessione dall'origine è un'azione essenziale. In questo modo sono stati separati i compiti e la protezione delle chiavi di crittografia (o dei file di configurazione) e diventa una funzione di amministratore di sistema, piuttosto che una funzione di sviluppo.

A parte questo, in Apache/php hai una serie di opzioni.

1.) Non inserire affatto la stringa di connessione nel codice php. Puoi inserire questi valori nel tuo httpd.conf O nel file degli host virtuali. La connessione non richiede quindi parametri quando si utilizza mysql_connect() ... un uso più dettagliato è disponibile qui: http://www.php.net/manual/en/class.mysqli.php

2.) Includi il file di configurazione configfile.php come di consueto, ma sposta il file di connessione da webroot se puoi, e crittografa il file stesso. La decrittografia del sistema operativo può essere impostata da SA per il processo che accederà al file. In alternativa, utilizzare Se non è possibile spostare il file fuori dal webroot (hosting condiviso), proteggere il file con .htaccess

<files configfile> 
     order allow,deny 
     deny from all 
</files> 

Per Microsoft IIS con ASP.NET, la stringa di connessione è archiviata nel file application.config o web.config e la crittografia utilizzata può essere una chiave macchina statica, memorizzata in uno di questi file o una chiave generata da IIS stesso - che non è memorizzato in una posizione accessibile. I dettagli sono disponibili su MSDN, con cui non sporcherò questa risposta poiché la tua domanda era specifica per LAMP.

Dovrei anche notare che, quando possibile, la mia preferenza è quella di evitare del tutto il problema utilizzando l'autenticazione integrata. Il mapping dell'utente del sistema operativo a un utente db estrae quasi del tutto i requisiti di protezione dal contesto di questa domanda.

17
iivel

Ho pochissima esperienza con questo, ma ho sempre sentito che lo lasci in chiaro (che senso ha crittografare se la chiave è comunque lì) e lasciare le credenziali in un file include e quindi mettere un controllo di accesso molto rigoroso su quel file .

nella mia esperienza con le cose sul web ... ci sono molti modi per fare le cose ... e pochi modi per fare le cose bene.

(dal mio telefono scusa la mia brevità)

0
user11869

È poco utile crittografare la password del database. In caso di PHP hai persino bisogno del codice crittografico per essere eseguito su ogni richiesta - questo è solo uno spreco di tempo della CPU. Inoltre, ci sono un sacco di altri motivi per cui non è una buona idea:

  • L'applicazione deve decrittografare i dati. Poiché in PHP sono molto probabilmente PHP, molto probabilmente qualcuno che ha accesso al file di configurazione ha accesso al file contenente il codice di decrittazione /chiave.
  • Spreco di tempo della CPU per decrittografare la password.
  • Se il database è configurato correttamente con la password non ti dà alcun vantaggio - l'accesso dovrebbe essere limitato a localhost (o qualunque Host su cui è in esecuzione il server web) e nel caso in cui strumenti come phpMyAdmin siano sul server dovrebbero essere protetti con un diverso parola d'ordine. In realtà, in caso di es PostgreSQL in esecuzione localmente potrebbe non essere affatto necessaria una password poiché puoi semplicemente concedere a un utente del sistema l'accesso a un determinato database - quindi se il tuo codice PHP viene eseguito come quell'utente eviti di archiviare any password per il database.

Quindi .. cosa possibile che fai ha senso? Abbastanza semplice, non inserire più file nella radice del documento di quanto assolutamente necessario. Poiché di solito le applicazioni valide utilizzano URL puliti indirizzati attraverso un singolo file .php, inseriscono quel file nella radice del documento. Qualsiasi altra cosa, ad esempio l'altro codice dell'applicazione, file di configurazione, ecc. Dovrebbe essere al di fuori della radice del documento. In questo modo una configurazione errata del server (ad es. PHP disabilitato e quindi l'invio di codice semplice all'utente) darà all'utente l'accesso solo a un singolo PHP che probabilmente non contiene molto più di una chiamata require e qualche chiamata di funzione.

Assicurati anche che i tuoi file non siano scrivibili/leggibili in tutto il mondo (specialmente quando devi usare l'hosting condiviso). Con un server correttamente configurato (php NON in esecuzione come www-data o un utente simile ma tuo utente) puoi disabilitare completamente "mondo" e possibilmente "raggruppare" l'accesso ai tuoi file.

0
ThiefMaster