Share
Wat je gaat creërenIn december 2014 had Slashdot een alarmerend verhaal Bots Scanning GitHub om Amazon EC2 Keys te stelen, gebaseerd op de ervaring van ontwikkelaar en blogger Andrew Hoffman die Ruby on Rails op Amazon probeerde uit te proberen met AWS S3. Hij pleegde per ongeluk een application.yml bestand met zijn AWS-sleutels. Hoewel hij het zag en snel wist, konden hackers met bots $ 2.375 aan uitgeven voordat Amazon tussenbeide kwam. Gelukkig hebben ze hem voor Hoffman niet verantwoordelijk gehouden voor de kosten.
Maar dit was niet bepaald een nieuw verhaal. In januari 2014 meldde Forbes 'Runa Sandvik: Aanvallers schrapen GitHub voor clouddienstreferenties, kapen account aan mijn virtuele valuta, gebaseerd op de ervaring van beveiligingsblogger Rich Mogull. Hackers haalden $ 500 aan kosten voor zijn rekening.
Wie kan zich niet verhouden tot zijn vertelling:
Ik was op de bank en maakte een aflevering af van Marvel's Agents of S.H.I.E.L.D. Hoe dan ook ... na de show controleerde ik mijn e-mail voordat ik naar bed ging. Dit is wat ik zag: "Geachte AWS klant, Uw veiligheid is belangrijk voor ons. We hebben onlangs ontdekt dat uw AWS toegangssleutel (eindigend met 3KFA) samen met uw geheime sleutel openbaar beschikbaar is op github.com." Crap. Ik sprong van de bank af, mompelend naar mijn vrouw, "mijn Amazon is gehackt" en verdween in mijn kantoor. Ik heb me onmiddellijk aangemeld bij AWS en GitHub om te zien wat er is gebeurd.
Het is een gemakkelijke fout en de meesten van ons hebben waarschijnlijk op een bepaald moment iets soortgelijks gedaan. En het zijn niet alleen AWS-sleutels die gevaar lopen. Naarmate ons gebruik van cloudservices toeneemt, kan het groeiende gebruik van een breed scala aan service API-sleutels worden gebruikt door hackers en spammers..
In deze zelfstudie laat ik je een oplossing zien die ik gebruik in mijn eigen toepassingen om mijn repositorycode van mijn sleutels te scheiden. Hoewel dit misschien niet geschikt is voor grotere omgevingen, is het een praktijk die ik regelmatig gebruik die me heeft geholpen om dit soort fouten te beperken - ja, ik heb ze ook gemaakt.
Zeker. In theorie zou dat moeten werken. Maar ik heb ervaringen gehad waarbij Git's negeren niet werkte zoals ik verwachtte (waarschijnlijk vanwege mijn eigen fout). Verder, als je erop vertrouwt gitignore en je maakt een fout, je zult het misschien niet ontdekken totdat het te laat is.
Een andere benadering is om te betalen voor privé-repositories. Als je een flexibel budget hebt, werkt dat goed. Maar als je aan open sourceprojecten werkt of ooit besluit een legacyproject te openen, is het ook geen onfeilbare aanpak.
Programmeerbare websites Waarom blootgestelde API-sleutels en gevoelige gegevens groeien Oorzaak van bezorgdheid bevat een aantal best practices en suggesties, zoals:
Ze bevelen ook aan:
Sluit geen API-sleutels, wachtwoorden enz. Rechtstreeks in de code in, bewaar deze altijd apart. Zet API-sleutels, wachtwoorden, enz. In een apart configuratiebestand. Als een configuratiebestand deel uitmaakt van een project in een IDE, verwijdert u gevoelige gegevens voordat u deze distribueert of deelt.
Dit is de aanpak die ik gebruik voor mijn eigen projecten en zal hieronder met u bespreken.
Ik vind het het beste om sleutels in een configuratiebestand te plaatsen dat wordt gehost buiten de openbaar toegankelijke webserver-directory's - en manueel beheerd, behalve mijn Git-repository.
Ik begon deze oplossing te gebruiken toen ik met Yii 1.1 begon te werken. Yii 2.0 biedt configureerbare omgevingen als onderdeel van de geavanceerde toepassingssjabloon, maar lost het beveiligingslek niet op .gitignore fouten.
Mijn aanpak is relatief eenvoudig. In plaats van service-sleutels en -referenties rechtstreeks in mijn coderingsbestanden in te bedden, plaats ik mijn sleutels in een afzonderlijk configuratiebestand dat wordt geparseerd tijdens initialisatiescripts.
Hier is bijvoorbeeld wat de traditionele aanpak eruit zou kunnen zien. Yii biedt een configuratiescript dat wordt geladen op elke paginabezoekmelding dat al mijn gebruikersnamen, wachtwoorden en API-sleutels kwetsbaar zijn voor verkeerde check-ins:
Accentsconagua
array ('connectionString' => 'mysql: host = localhost; dbname = mydatabase', 'emulatePrepare' => true, 'gebruikersnaam' => 'jeff', 'wachtwoord' => 'whitefoxesjumpfences', 'charset' => ' utf8 ',' tablePrefix '=>' fox_ ',), // parameters op toepassingsniveau die kunnen worden geopend // met Yii :: app () -> params [' paramName ']' params '=> array (' pushover '=> array (' key '=>' H75EAC19M3249! X2 ',),' google '=> array (' maps_api_key '=>' W69uHsUJZBPhsFNExykbQceK ',),), ...); ...?>In plaats van dit risico te lopen, maak ik een app-config.ini bestand en plaats het buiten de github repository directory. Het ziet er ongeveer zo uit:
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"
Vervolgens pas ik het configuratiescript aan om het bestand met parse_ini_file op te nemen en de hardcoded instellingen te vervangen door variabelen van de ini het dossier:
array ('connectionString' => 'mysql: host ='. $ config ['mysql_host']. '; dbname ='. $ config ['mysql_db'], 'emulatePrepare' => true, 'gebruikersnaam' => $ config ['mysql_un'], 'wachtwoord' => $ config ['mysql_pwd'], 'charset' => 'utf8', 'tablePrefix' => 'fox_',), // parameters op applicatieniveau die toegankelijk zijn / / using Yii :: app () -> params ['paramName'] 'params' => array ('pushover' => array ('key' => $ config ['pushover_key'],), 'google' => array ('maps_api_key' => $ config ['google_maps_api_key'],),), ...); >?Deze aanpak is voor mij vrij eenvoudig en hanteerbaar gebleken.
Als u een WordPress-beheerder bent, moet u ook rekening houden met uw API-sleutels die worden gebruikt door veelgebruikte plug-ins; deze worden opgeslagen in uw WordPress-database. Blijf op de hoogte van updates voor uw besturingssysteem, WordPress en plug-ins om te voorkomen dat toetsen worden aangetast door andere kwetsbaarheden.
Mijn aanpak is bedoeld om een basisalternatief aan te bieden, maar het is zeker niet het laatste woord. Ik hoor graag uw ideeën en suggesties. Plaats hieronder eventuele opmerkingen en ideeën. Je kunt door mijn andere Tuts + tutorials bladeren op mijn instructeurspagina of me volgen op Twitter @reifman.
