Share
Cosa starai creandoNel dicembre 2014, Slashdot ha lanciato una storia allarmante Bots Scanning GitHub per rubare Amazon EC2 Keys, basato sull'esperienza dello sviluppatore e blogger Andrew Hoffman che ha provato Ruby on Rails su Amazon con AWS S3. Ha inavvertitamente commesso un application.yml file con le sue chiavi AWS. Anche se l'ha notato e cancellato rapidamente, gli hacker che eseguono bot sono riusciti a spendere $ 2375 di servizi prima che Amazon intervenisse. Fortunatamente, per Hoffman, non lo ritennero responsabile delle tasse.
Ma questa non era esattamente una nuova storia. Nel gennaio 2014, Runa Sandvik di Forbes ha riportato: Gli attaccanti raschiano GitHub per le credenziali del servizio cloud, l'account hijack per estrarre la moneta virtuale, sulla base della propria esperienza di blogger di sicurezza Rich Mogull. Gli hacker hanno accumulato $ 500 in accuse sul suo conto.
Chi non può riferirsi al suo modo di dire:
Ero sul divano, finendo un episodio di Agenti di Marvel di S.H.I.E.L.D. Comunque ... dopo lo spettacolo ho controllato la mia e-mail prima di andare a letto. Questo è quello che ho visto: "Gentile cliente AWS, la tua sicurezza è importante per noi. Di recente siamo venuti a conoscenza del fatto che la tua chiave di accesso AWS (che termina con 3KFA) insieme alla tua chiave segreta sono disponibili pubblicamente su github.com." Una schifezza. Sono scappato dal divano, borbottando con mia moglie, "la mia amazzone è stata violato" e spariva nel mio ufficio. Ho immediatamente effettuato l'accesso ad AWS e GitHub per vedere cosa è successo.
È un errore facile e molti di noi hanno probabilmente fatto una cosa simile in un punto o nell'altro. E non sono solo le chiavi AWS a rischio. Con l'aumento del nostro utilizzo di servizi basati su cloud, l'uso in espansione di un'ampia varietà di chiavi API di servizi può essere sfruttato allo stesso modo dagli hacker e dagli spammer.
In questo tutorial, ti guiderò attraverso una soluzione che utilizzo nelle mie applicazioni per separare il mio codice di repository dalle mie chiavi. Anche se questo potrebbe non essere appropriato per ambienti più grandi, è una pratica che uso regolarmente che mi ha aiutato a limitare questi tipi di errori - sì, li ho fatti anche io.
Sicuro. In teoria, dovrebbe funzionare. Ma ho avuto esperienze in cui Git ha ignorato che non ha funzionato come mi aspettavo (probabilmente a causa del mio errore). Inoltre, se ti affidi gitignore e commetti un errore, potresti non scoprirlo finché non è troppo tardi.
Un altro approccio è quello di pagare per gli archivi privati. Se hai un budget flessibile, funziona bene. Ma se lavori su progetti open source o decidi di aprire un progetto legacy, non è neanche un approccio infallibile.
Perché le API chiave esposte e i dati sensibili sono in crescita Perché gli elenchi di Preference riguardano alcune best practice e suggerimenti come:
Raccomandano anche:
Non incorporare chiavi API, password, ecc. Direttamente nel codice, tenerle sempre separate. Inserisci chiavi API, password, ecc. In un file di configurazione separato. Se un file di configurazione fa parte di un progetto in un IDE, rimuovere i dati sensibili prima di distribuire o condividere.
Questo è l'approccio che utilizzo per i miei progetti e che esaminerò di seguito.
Trovo che sia meglio posizionare le chiavi in un file di configurazione ospitato al di fuori delle directory del server Web accessibili pubblicamente e gestite manualmente, a parte il mio repository Git.
Ho iniziato a utilizzare questa soluzione quando ho iniziato a lavorare con Yii 1.1. Yii 2.0 fornisce ambienti configurabili come parte del suo modello di applicazione avanzato, ma non corregge la vulnerabilità .gitignore errori.
Il mio approccio è relativamente semplice. Invece di incorporare direttamente chiavi e credenziali di servizio nei miei file di codifica, inserisco le mie chiavi in un file di configurazione separato che viene analizzato durante gli script di inizializzazione.
Ad esempio, ecco come potrebbe apparire l'approccio tradizionale. Yii fornisce uno script di configurazione che carica su ogni richiesta di pagina: si noti che tutti i miei nomi utente, password e chiavi API sono vulnerabili ai check in errati:
Accentsconagua
array ('connectionString' => 'mysql: host = localhost; dbname = mydatabase', 'emulatePrepare' => true, 'username' => 'jeff', 'password' => 'whitefoxesjumpfences', 'charset' => ' utf8 ',' tablePrefix '=>' fox_ ',), // parametri a livello di applicazione a cui è possibile accedere // usando Yii :: app () -> params [' paramName ']' params '=> array (' pushover '=> array (' chiave '=>' H75EAC19M3249! X2 ',),' google '=> array (' maps_api_key '=>' W69uHsUJZBPhsFNExykbQceK ',),), ...); ...?>Piuttosto che correre questo rischio, creo un app-config.ini file e posizionarlo all'esterno della directory del repository github. Potrebbe sembrare qualcosa del genere:
mysql_host = "http://host33663.rds.amazon-aws.com" mysql_un = "amzn-app-db7293" mysql_db = "rds-foxesandfences-db" mysql_pwd = "K * $ 1x7B32auiWX91" pushover_key = "H75EAC19M3249! X2" google_maps_api_key = "W69uHsUJZBPhsFNExykbQceK"
Quindi, modifico lo script di configurazione per includere il file usando parse_ini_file e sostituisco le impostazioni hardcoded con variabili dal ini file:
array ('connectionString' => 'mysql: host ='. $ config ['mysql_host']. '; dbname ='. $ config ['mysql_db'], 'emulatePrepare' => true, 'username' => $ config ['mysql_un'], 'password' => $ config ['mysql_pwd'], 'charset' => 'utf8', 'tablePrefix' => 'fox_',), // parametri a livello di applicazione a cui è possibile accedere / / using Yii :: app () -> params ['paramName'] 'params' => array ('pushover' => array ('chiave' => $ config ['pushover_key'],), 'google' => array ('maps_api_key' => $ config ['google_maps_api_key'],),), ...); >?Questo approccio si è rivelato abbastanza semplice e gestibile per me.
Se sei un amministratore di WordPress, dovresti anche essere a conoscenza delle chiavi API utilizzate dai plug-in comuni; questi sono memorizzati nel tuo database di WordPress. Tieniti aggiornato con gli aggiornamenti del tuo sistema operativo, WordPress e plug-in per evitare che le chiavi vengano compromesse da altre vulnerabilità.
Il mio approccio è pensato per offrire un'alternativa di base, ma non è certamente l'ultima parola. Mi piacerebbe sentire le tue idee e i tuoi suggerimenti. Si prega di postare eventuali commenti e idee qui sotto. Puoi sfogliare i miei altri Tuts + tutorial sulla mia pagina di istruttore o seguirmi su Twitter @reifman.
