Share
Lo que vas a crearEn diciembre de 2014, Slashdot publicó una historia alarmante Bots Scanning GitHub para robar claves de Amazon EC2, basada en la experiencia del desarrollador y blogger Andrew Hoffman al probar Ruby on Rails en Amazon con AWS S3. Inadvertidamente cometió un application.yml archivo con sus claves de AWS. A pesar de que lo notó y los eliminó rápidamente, los hackers que ejecutaban bots lograron gastar $ 2,375 en servicios antes de que Amazon interviniera. Afortunadamente, para Hoffman, no lo responsabilizaron por los honorarios.
Pero esto no era exactamente una nueva historia. En enero de 2014, Runa Sandvik de Forbes informó: Los atacantes rasparon GitHub para obtener credenciales de servicio en la nube, secuestrar una cuenta para extraer moneda virtual, según la propia experiencia del blogger de seguridad Rich Mogull. Los hackers acumularon $ 500 en cargos en su cuenta.
Quien no puede relacionarse con su narración:
Estaba en el sofá, terminando un episodio de Marvel agentes de S.H.I.E.L.D. De todos modos ... después del show revisé mi correo electrónico antes de irme a la cama. Esto es lo que vi: "Estimado cliente de AWS: Su seguridad es importante para nosotros. Hace poco nos dimos cuenta de que su Clave de acceso de AWS (que termina con 3KFA) junto con su Clave secreta están disponibles públicamente en github.com". Mierda. Salté del sofá, murmurando a mi esposa, "mi Amazon ha sido hackeado", y desaparecí en mi oficina. Inmediatamente inicié sesión en AWS y GitHub para ver qué sucedió.
Es un error fácil y la mayoría de nosotros probablemente hemos hecho algo similar en un momento u otro. Y no solo las claves de AWS están en riesgo. A medida que aumenta el uso de los servicios basados en la nube, los hackers y los spammers pueden aprovechar el uso creciente de una amplia variedad de claves de API de servicio..
En este tutorial, lo guiaré a través de una solución que uso en mis propias aplicaciones para separar el código de mi repositorio de mis claves. Si bien esto puede no ser apropiado para entornos más grandes, es una práctica que empleo regularmente que me ayudó a limitar este tipo de errores. Sí, los he cometido también..
Por supuesto. Teóricamente, eso debería funcionar. Pero he tenido experiencias donde la ignorancia de Git no ha funcionado como esperaba (probablemente debido a mi propio error). Además, si confías en gitignore y cometes un error, puede que no lo descubras hasta que sea demasiado tarde..
Otro enfoque es pagar por repositorios privados. Si tienes un presupuesto flexible, eso funciona bien. Pero si trabaja en proyectos de código abierto o alguna vez decide abrir un proyecto heredado, tampoco es un enfoque infalible..
Las claves API expuestas y los datos confidenciales de Programmable Web están creciendo Causa de preocupación Enumera algunas de las mejores prácticas y sugerencias, tales como:
También recomiendan:
No incruste claves de API, contraseñas, etc., directamente en el código, siempre manténgalos separados. Coloque las claves de API, contraseñas, etc., en un archivo de configuración separado. Si un archivo de configuración es parte de un proyecto en un IDE, elimine los datos confidenciales antes de distribuirlos o compartirlos..
Este es el enfoque que utilizo para mis propios proyectos y lo revisaré a continuación..
Creo que es mejor colocar las claves en un archivo de configuración alojado fuera de los directorios del servidor web de acceso público, y administrado manualmente, aparte de mi repositorio Git.
Comencé a emplear esta solución cuando comencé a trabajar con Yii 1.1. Yii 2.0 proporciona entornos configurables como parte de su plantilla de aplicación avanzada, pero no corrige la vulnerabilidad a .gitignore errores.
Mi enfoque es relativamente simple. En lugar de integrar claves de servicio y credenciales en mis archivos de codificación directamente, coloco mis claves en un archivo de configuración separado que se analiza durante los scripts de inicialización.
Por ejemplo, esto es lo que podría parecer el enfoque tradicional. Yii proporciona una secuencia de comandos de configuración que se carga en cada aviso de solicitud de página de que todos mis nombres de usuario, contraseñas y claves de API son vulnerables a registros erróneos:
Accentsconagua
array ('connectionString' => 'mysql: host = localhost; dbname = mydatabase', 'emulatePrepare' => true, 'username' => 'jeff', 'password' => 'whitefoxesjumpfences', 'charset' => ' utf8 ',' tablePrefix '=>' fox_ ',), // parámetros de nivel de aplicación a los que se puede acceder // utilizando Yii :: app () -> params [' paramName ']' params '=> array (' pushover '=> array (' key '=>' H75EAC19M3249! X2 ',),' google '=> array (' maps_api_key '=>' W69uHsUJZBPhsFNExykbQceK ',),),));En lugar de correr este riesgo, creo un app-config.ini Archivo y colóquelo fuera del directorio del repositorio github. Podría verse algo como esto:
mysql_host = "http://host33663.rds.amazon-aws.com" mysql_un = "amzn-app-db7293" mysql_db = "rds-foxesandfallaspaciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospucanospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospuciospucios.com google_maps_api_key = "W69uHsUJZBPhsFNExykbQceK"
Luego, modifico la secuencia de comandos de configuración para incluir el archivo usando parse_ini_file y reemplace la configuración codificada con variables del ini expediente:
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_',), // parámetros de nivel de aplicación a los que se puede acceder / / using Yii :: app () -> params ['paramName'] 'params' => array ('pushover' => array ('key' => $ config ['pushover_key'],), 'google' => array ('maps_api_key' => $ config ['google_maps_api_key'],),),…); >?Este enfoque ha sido bastante simple y manejable para mí..
Si eres un administrador de WordPress, también debes conocer tus claves API empleadas por complementos comunes; Estos se almacenan en su base de datos de WordPress. Manténgase al día con sus actualizaciones de SO, WordPress y plugins para evitar que las claves se vean comprometidas por otras vulnerabilidades.
Mi enfoque pretende ofrecer una alternativa básica, pero ciertamente no es la última palabra. Me encantaría escuchar tus ideas y sugerencias. Por favor, publique cualquier comentario e ideas a continuación. Puede navegar por mis otros tutoriales de Tuts + en la página de mi instructor o seguirme en Twitter @reifman.
