Share
Vad du ska skapaI december 2014 körde Slashdot en oroväckande historia Bots Scanning GitHub för att stjäla Amazon EC2 Keys, baserat på utvecklare och bloggare Andrew Hoffmans erfarenhet av att prova Ruby on Rails på Amazon med AWS S3. Han begav oavsiktligt en application.yml filen med sina AWS-nycklar. Trots att han märkte det och raderade dem snabbt lyckades hackare som körde bots att betala $ 2.375 av tjänster innan Amazon ingrep. Lyckligtvis för Hoffman höll de inte honom ansvarig för avgifterna.
Men det var inte precis en ny historia. I januari 2014 rapporterade Forbes 'Runa Sandvik: Attackers Scrape GitHub för Cloud Service Credentials, Hijack Account to Mine Virtual Currency, baserat på säkerhetsbloggar Rich Mogulls egen erfarenhet. Hackare sprang upp $ 500 i avgifter på sitt konto.
Vem kan inte relatera till hans berättande:
Jag låg på soffan och avslutade en episod av Marvels agenter av S.H.I.E.L.D. Hur som helst ... efter showen kontrollerade jag min e-post innan du gick till sängs. Så här såg jag: "Kära AWS-kund, Din säkerhet är viktig för oss. Vi blev nyligen medvetna om att din AWS Access Key (slutar med 3KFA) tillsammans med din hemliga nyckel är offentligt tillgänglig på github.com." Skit. Jag bultade av soffan och mumlade till min fru, "min Amazon har blivit hackad" och försvann till mitt kontor. Jag loggade omedelbart till AWS och GitHub för att se vad som hände.
Det är ett enkelt misstag och de flesta av oss har förmodligen gjort en liknande sak vid en eller annan punkt. Och det är inte bara AWS-nycklar som är i fara. Eftersom vår användning av molnbaserade tjänster ökar kan den växande användningen av ett brett utbud av API-nycklar av tjänst utnyttjas av hackare och spammare.
I denna handledning går jag igenom en lösning som jag använder i mina egna applikationer för att separera min förrådskod från mina nycklar. Även om detta kanske inte är lämpligt för större miljöer, är det en övning som jag regelbundet använder som har hjälpt mig att begränsa dessa typer av misstag - ja, jag har gjort dem också.
Säker. Teoretiskt borde det fungera. Men jag har haft erfarenheter där Gits ignorerar inte har fungerat som jag förväntade mig (troligen på grund av mitt eget fel). Dessutom, om du litar på gitignore och du gör ett fel kan du inte upptäcka det förrän det är för sent.
Ett annat tillvägagångssätt är att betala för privata repositorier. Om du har en flexibel budget fungerar det bra. Men om du arbetar med open source-projekt eller någonsin bestämmer dig för att öppna upp ett arvsprojekt, är det inte heller en idiotsäker strategi.
Programmerbar webb varför exponerade API-nycklar och känsliga data växer för att bekymra sig listar några bra metoder och förslag som:
De rekommenderar också:
Bädda inte in API-nycklar, lösenord etc. direkt i koden, håll alltid dessa separata. Sätt API-nycklar, lösenord etc. i en separat konfigurationsfil. Om en konfigurationsfil är en del av ett projekt i en IDE, ta bort känslig data innan du distribuerar eller delar.
Detta är det tillvägagångssätt som jag använder för mina egna projekt och kommer att granska med dig nedan.
Jag tycker att det är bäst att placera nycklar i en konfigurationsfil som är värd utanför de offentligt tillgängliga webbserverns kataloger och hanteras manuellt, förutom mitt Git-arkiv.
Jag började använda denna lösning när jag började arbeta med Yii 1.1. Yii 2.0 ger konfigurerbara miljöer som en del av dess avancerade applikationsmall, men löser inte sårbarheten för .gitignore fel.
Min inställning är relativt enkel. I stället för att inbädda tjänste nycklar och referenser i mina kodningsfiler direkt placerar jag mina nycklar i en separat konfigurationsfil som analyseras under initieringsskript.
Till exempel, här är vad det traditionella tillvägagångssättet kan se ut. Yii tillhandahåller ett konfigurationsskript som fyller på varje sidförfrågan. Observera att alla mina användarnamn, lösenord och API-nycklar är sårbara för felaktiga incheckningar:
Accentsconagua
array ('connectionString' => 'mysql: värd = localhost; dbname = mydatabase', 'emulatePrepare' => true, 'användarnamn' => 'jeff', 'password' => 'whitefoxesjumpfences', 'charset' => ' utf8 ',' tablePrefix '=>' fox_ '), // applikationsnivåparametrar som kan nås // med hjälp av Yii :: app () -> parametrar [' paramName ']' params '=> array => array ('maps_api_key' => 'W69uHsUJZBPhsFNExykbQceK',),), ...); ...?>I stället för att köra denna risk skapar jag en app-config.ini filen och placera den utanför githubregisterkatalogen. Det kan se ut så här:
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"
Sedan ändrar jag konfigurationsskriptet för att inkludera filen med parse_ini_file och ersätta de hårdkodade inställningarna med variabler från ini fil:
array ('connectionString' => 'mysql: värd ='. $ config ['mysql_host']. '; dbname ='. $ config ['mysql_db'], 'emulatePrepare' => true, 'användarnamn' => $ config ['mysql_un'], 'lösenord' => $ config ['mysql_pwd'], 'charset' => 'utf8', 'tablePrefix' => 'fox_'), // parametrar på applikationsnivå som kan nås / / using Yii :: app () -> parametrar ['paramName'] 'parametrar' => array ('pushover' => array ('key' => $ config ['pushover_key'],), 'google' => array ('maps_api_key' => $ config ['google_maps_api_key'],),), ...); >?Detta tillvägagångssätt har visat sig vara ganska enkelt och hanterbart för mig.
Om du är en WordPress-administratör bör du också vara medveten om dina API-nycklar som används av vanliga plugins. Dessa lagras i din WordPress-databas. Håll dig uppdaterad med OS, WordPress och plugin-uppdateringar för att undvika att ha nycklar som äventyras av andra sårbarheter.
Min inställning är tänkt att erbjuda ett grundläggande alternativ, men det är verkligen inte det sista ordet. Jag skulle gärna höra dina idéer och förslag. Vänligen skicka några kommentarer och idéer nedan. Du kan bläddra i mina andra Tuts + handledning på min instruktörssida eller följa mig på Twitter @ reifman.
