Habrá muchas charlas en la conferencia de
RubyRussia sobre cómo escribir código y cómo hacerlo mejor que otros. Pero si el producto que lanza su empresa no es seguro, esto puede generar grandes problemas. Grigory Petrov discutió este importante tema con Mikhail Pronyakin de la compañía ONSEK, el desarrollador de la plataforma integrada
Valarm .
¿Dime qué haces y cómo usas Ruby?Érase una vez, trabajé como especialista en el campo de la seguridad de la información. Hizo algo como la última aplicación web y varios dispositivos físicos. Paralelamente a esto, se dedicó a la programación del sistema en C. En ese momento, como ahora, el marco Metasploit era popular, y podía expandirse con sus propios módulos de explotación y búsqueda de vulnerabilidades. Estaba escrito en Ruby, así que comencé a conocer este idioma. Luego fui a trabajar para Onsek, donde al principio aceleré algunas partes críticas del backend del proyecto al reescribir el código de Ruby a C, y luego comencé a escribir nuevas funciones solo en Ruby. Las actividades de nuestra empresa están relacionadas con la seguridad de la información, estamos haciendo
Valarm, una plataforma para proteger y probar aplicaciones web (y no solo). Resulta que soy un desarrollador de Ruby y un especialista en seguridad de la información.
Su informe estará relacionado con este tema. Cuéntame másRoR le brinda al programador grandes oportunidades para escribir código, pero también hay puntos obvios que pueden conducir a problemas de seguridad. En la conferencia, hablaré sobre las vulnerabilidades típicas de las aplicaciones de Ruby y daré ejemplos prácticos que ayudarán a prevenir errores.
En su opinión, ¿cómo es Rails en términos de seguridad?En la filosofía de Ruby and Rails, existe una "prioridad de acuerdo sobre la configuración". Si todo está pensado en el acuerdo, no aparecerán problemas de seguridad. Pero si surge de repente una situación en la que puede escribir código vulnerable de forma predeterminada, entonces esto ya puede causar serios problemas. Especialmente para los desarrolladores novatos que acaban de comenzar a aprender Rails y ni siquiera piensan en la seguridad de su código. Mirando hacia el pasado, solía ser peor en todas partes con seguridad que ahora. Esto se aplica no solo a Ruby, sino también a otros lenguajes y marcos. Cada año, las características de seguridad se integran cada vez más profundamente en los marcos. Por ejemplo, Rails ya tiene tokens CSRF listos para usar en todas partes, lo cual es muy bueno. Y todo esto funciona bajo el capó, pero si no sabe cómo y desea hacer algo personalizado, la seguridad de la aplicación puede verse comprometida.
Si consideramos las vulnerabilidades, se pueden dividir en dos tipos: estas son vulnerabilidades en tiempo de ejecución y vulnerabilidades del lenguaje en sí. Había una vez una historia triste en Python: resultó que en Python el hash para el diccionario se calcula sin sal. Uno podría provocar maliciosamente un número infinito de colisiones. Como resultado, los diccionarios se desbordaron y los servidores murieron por varios megabytes de solicitudes de ataque. Dime, en tu mundo Rails, según tu experiencia, ¿cuántas vulnerabilidades hay en el propio Ruby y cuántas vulnerabilidades hay en los rieles?Si miramos el tema de las vulnerabilidades, entonces es mucho más extenso que solo Ruby y Rails. Por ejemplo, tenemos nginx. Si no está configurado correctamente, simplemente puede leer algunos archivos del servidor y obtener el secreto de la aplicación Rails. Y eso es todo, la aplicación está pirateada: haz lo que quieras. Debe comprender que la seguridad no se limita a un solo idioma y marco: hay un entorno donde se ejecuta, un entorno donde se ensambla y otro millón de matices diferentes.
Y en términos de cantidad, ¿puedes de alguna manera descubrir dónde hay más vulnerabilidades? ¿Fuera de Ruby and Rails, en el lenguaje mismo, en su tiempo de ejecución, en la biblioteca estándar o en Rails como un marco que usa Ruby?Diría que la mayoría de las vulnerabilidades se encuentran en la unión entre la lógica de la aplicación y los Rails mismos u otras funciones de la biblioteca.
En los últimos años, ¿cuál fue la vulnerabilidad más divertida que usted o sus colegas encontraron? De la serie "Ahh, bueno, eso fue lo que tuviste que fastidiar así".La vulnerabilidad más memorable estaba en la gema, permitiendo textos de voz. Le das el texto y él lo expresa. Gem llamó a la utilidad de la consola y le pasó los parámetros sin la detección adecuada. Como resultado, se descubrió una inyección en Bash, y se podía escuchar el resultado de ejecutar un comando arbitrario. Envía el comando "ls /" a la entrada, y la voz en respuesta dicta "slash dev slash, etc." y así sucesivamente.
En los últimos años, el ecosistema de lenguajes de nivel súper alto (Python, Ruby, JavaScript) se ha basado en una gran cantidad de pequeñas bibliotecas. Hay muchos de ellos, y dependen unos de otros para eliminar algo de la almohadilla izquierda, y esto mata el ecosistema. Los atacantes comienzan a crear sus propias bibliotecas o toman el control de extraños y les agregan un código malicioso que no pueden encontrar. ¿Qué tan grande y terrible es esto ahora?Hay un problema, pero hasta ahora nadie lo piensa realmente, todos confían "al azar". Si un atacante tiene el objetivo de atacar a una compañía específica de cierta manera, nadie lo detendrá hoy. Nada impide hacer una buena gema, ganar muchas estrellas en GitHub y esperar a que todos comiencen a usarla. Luego, incrusta secretamente código malicioso en él, lo que no es nada difícil. Creo que la cuestión de las dependencias hoy es una cuestión de confianza: el problema está abierto y aún está esperando su solución.
¡Nos vemos en RubyRussia!Las preguntas sobre el tema de la seguridad se pueden hacer a Mikhail después del informe, y también se pueden discutir en el stand de su empresa. Puede ver qué otros temas discutirán los rubistas el 28 de septiembre
en el sitio web .
Además de los oradores y participantes, puede familiarizarse con las maravillosas empresas que apoyan la conferencia:
Organizador -
EvroneSocio general -
ToptalGold Partner -
GettSocios de plata:
Valarm ,
JetBrains ,
Bookmate y
CashwagonSocio de bronce -
InSales