X
BLOG

Inyecciones SQL y seguridad electoral

Inyecciones SQL y seguridad electoral Tiempo de leer: 5 minutos
¿Está tu cabeza en la arena? No realizar las pruebas de seguridad adecuadas puede hacer que sentir seguro, pero no conocer las vulnerabilidades de su código no mantendrá sus sistemas seguros. Aprenda cómo obtener más visibilidad y crear seguridad en su código.

Así como las elecciones justas y precisas son la base de la democracia, el software seguro es fundamental para nuestra vida digital moderna. No estoy comparando estos para que sean lindos, sino más bien, indagando en la intersección de los dos, lo que puede ser desastroso. Análisis reciente de nuestros sistemas de votación en los EE. UU. nos han demostrado que son plagado de inseguridadesDatos del votante se roba con facilidad y con frecuencia. Ahora, cuando piensa en esta vulnerabilidad en las aproximadamente 10,000 jurisdicciones de votación locales, por supuesto, parece probable que algunos de estos sistemas no sean seguros.

Quizás lo más aterrador e informativo de estas historias es que en un reciente DefCon Hackathon, un niño de 11 años pudo acceder a los datos de los resultados de las elecciones en un sistema de prueba utilizando mi antiguo favorito, la inyección SQL. Tomó todo 10 minutos. Supongo que no me sorprende, ya que durante mucho tiempo pensé en la inyección SQL como un juego de niños (por eso hice el Salón de la vergüenza de SQLi). Un organizador de DefCon señaló:

"Estos sitios web son tan fáciles de piratear que no podríamos dárselos a piratas informáticos adultos; se reirían de ellos fuera del escenario"

Los funcionarios electorales, en este caso, afirman que los sistemas reales son mucho más difíciles de piratear, pero soy escéptico. Este tipo de negación es común en la industria de la seguridad del software hasta el momento en que ocurre un pirateo real. Basta recordar Heartbleed, que la mayoría no se tomó en serio hasta que se probó a fondo. O cuando las vulnerabilidades en sensores de presión de neumáticos se descubrieron después de que la gente de la industria dijera que era demasiado difícil, con demasiadas variedades, no importaba, etc. Hace unas pocas semanas.

En otro movimiento demasiado común, muchos funcionarios electorales no he hecho ninguna prueba. Este enfoque de cabeza en la arena puede ayudarlos a sentirse mejor, pero no saber cuáles son sus riesgos de seguridad no mantiene sus sistemas seguros. Les garantizo que los malos actores saben exactamente qué vulnerabilidades existen.

Tenemos que hacerlo mejor

Tenemos que empezar a hacer un mejor trabajo. Ya es bastante difícil proteger los sistemas conectados a Internet; no necesitamos darles a los piratas informáticos fácil acceso.

Hay un refrán común en la comunidad de ciberseguridad de que no es posible el 100% de seguridad. Pero si bien eso es cierto, por el momento ese NO es el problema. El problema es que ni siquiera estamos haciendo el cosas fáciles para proteger nuestro software, por ejemplo, ni para el sitio web de votantes ni para máquinas de votación. Sé que cualquiera que realmente quiera mi coche puede robarlo, pero sigo cerrando las puertas y no dejo las llaves en él. No proteger su aplicación conectada a Internet contra ataques basados ​​en entradas significa que está dejando que alguien se lleve todos sus datos.

¿Cómo hacemos un mejor trabajo?

Independientemente de las motivaciones de los piratas informáticos electorales, ya sean estados-nación, organizaciones políticas o piratas informáticos en su sótano en busca de diversión, es importante hacer todo lo posible para aumentar la seguridad y confiabilidad de nuestros sistemas de votación. Los problemas pueden parecer enormes, pero de hecho hay algunas cosas básicas que podemos hacer que serán efectivas tapando los agujeros más obvios en nuestro sistema con fugas.

Seguro por diseño

El diseño seguro significa que tenemos que empezar a pensar de manera diferente sobre la seguridad de las aplicaciones y la codificación segura. Significa que no podemos probar la seguridad en nuestro software más de lo que podemos probar la calidad en un producto. La parte "por diseño" significa que pensamos en la seguridad primero, y luego creamos aplicaciones seguras, y hacemos pruebas de seguridad como pruebas de penetración con el propósito de validar la seguridad, NO con el propósito de encontrar fallas de seguridad.

Pregúntese: ¿qué hace cuando la prueba de penetración encuentra algo? ¿Lo sigue con análisis de flujo para encontrar vulnerabilidades similares? ¿Busca entonces estándares como los de CERT en busca de estrategias que le muestren cómo codificar de una manera que evite lo que encuentra su prueba de penetración? En el caso de SQLi, esto significa realizar la validación de entrada de una manera determinista que no tiene posibilidades de perder la entrada del usuario.

contraseñas

Una forma común en que los atacantes acceden a los dispositivos es a través de contraseñas. Si los dispositivos permiten contraseñas de baja calidad o no se protegen contra los intentos de adivinar las contraseñas, serán vulnerables. En el peor de los casos, los dispositivos se envían sin contraseñas hasta que configure una, o con algunas credenciales predeterminadas codificadas. Este es un problema que la industria conoce desde hace varias décadas, pero que aún persiste. La legislación reciente en California requiere que los fabricantes de dispositivos tomen medidas básicas en esta área. Ciertamente no es una solución completa, pero es un excelente comienzo.

Estándares de codificación seguros

Existen muchos estándares y marcos de ciberseguridad que puede utilizar como guía sobre qué prácticas y procesos se deben implementar para crear un código seguro, como pruebas unitarias, medición de cobertura, ejecución de análisis estático, revisión por pares, etc. A nivel de software, esto debe en última instancia conducen a estándares de codificación específicos.

Los estándares de codificación incluyen pautas de diferentes variedades. Algunos de ellos buscan defectos de codificación, identificando problemas de seguridad sin tener que ejecutar realmente el código. Otros son anti-patrones, lo que significa que buscan un código incorrecto que nunca debes usar, o "el código huele". Otros son prescriptivos y le indican una forma mejor de codificar.

Este último grupo es la única forma de adelantarse a la ciberseguridad. Estos estándares se adaptan bien a una iniciativa de diseño seguro y, en primer lugar, le ayudarán a crear un código más seguro. Cuando esté implementando su iniciativa de análisis estático para una codificación segura, asegúrese de mirar los comprobadores disponibles y asegúrese de tener una buena combinación de detectores, olores y prevención. Juntos, los tres pueden fortalecer su aplicación, no solo contra la inyección de SQL, sino contra todos los otros ataques comunes basados ​​en entradas.

¿Cómo empezar

Parasoft proporciona soporte para una amplia variedad de estas reglas para desarrolladores que usan C, C ++, Java y .NET. Tenemos soporte para estándares de seguridad comunes como CWE, OWASP, CERT y UL 2900, y debido a que comenzamos nuestras ofertas de análisis estático basados ​​en estándares de ingeniería, parece ser que tenemos el mayor conjunto de reglas preventivas disponible en cualquier lugar. Por ejemplo, tenemos una regla de validación de entrada simple que cuando se sigue termina la posibilidad de SQLi. No hace esto tratando de perseguir datos contaminados a través de la miríada (y casi infinita) de flujos de una aplicación (seguro por prueba) sino más bien creando código donde no hay rutas para que se omita la validación de entrada (seguro) por diseño).

Esta es una forma fundamentalmente diferente de pensar sobre la seguridad. Si tiene un título en ingeniería, este tipo de enfoque basado en estándares le resultará muy familiar. Si se ha pasado la vida creando software, esto puede parecer nuevo. Pero lo llevará a la vanguardia en seguridad de software. Llámanos y pruébalo por ti mismo.

Incorpore seguridad a su aplicación desde el principio

Escrito por

Arthur Hicken

Arthur ha estado involucrado en seguridad de software y automatización de pruebas en Parasoft durante más de 25 años, ayudando a investigar nuevos métodos y técnicas (incluidas 5 patentes) mientras ayuda a los clientes a mejorar sus prácticas de software.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft