Una versión de este artículo apareció originalmente en Ayuda a la Seguridad en la Red. Se ha actualizado y sindicado aquí.

‍

Si tienes un papel práctico en la ciberseguridad -uno que requiere cierta familiaridad con el código- es muy probable que hayas tenido que pensar en la inyección SQL... una y otra vez. Se trata de una vulnerabilidad común que, a pesar de conocer su sencillo remedio a las pocas semanas de su primer descubrimiento, sigue plagando nuestro software y proporcionando una pequeña ventana de oportunidad a los posibles atacantes si no se detecta antes de su despliegue.

El 13 de diciembre de 2020 marcó el 22º cumpleaños de la inyección SQL, y a pesar de que esta vulnerabilidad es lo suficientemente vieja como para beber, estamos dejando que se apodere de nosotros en lugar de aplastarla para siempre. En agosto de este año, la empresa Freepik reveló que había sido víctima de un error de inyección SQL que comprometió las cuentas de 8,3 millones de usuarios. Mientras que un número de ellos utilizó inicios de sesión de terceros (por ejemplo, Google, Facebook), unos pocos millones tenían contraseñas sin cifrar expuestas junto con su nombre de usuario. Lamentablemente para ellos y para muchos otros, las consecuencias de estos incidentes son un gran dolor de cabeza, y reconstruir la confianza con la base de usuarios es un proceso a largo plazo.

Mientras "celebramos" este hito con lo que se considera un problema heredado, vamos a diseccionarlo por un momento. ¿Por qué sigue apareciendo, por qué sigue siendo tan peligroso que no se ha movido del primer puesto en el Top 10 de OWASP durante años, y por qué su solución relativamente sencilla no entra en los estándares generales de referencia para el desarrollo de software?

¿Por qué la inyección SQL sigue siendo relevante en 2021?

Un rápido vistazo a una reciente brecha de alto perfil, el devastador ciberataque a FireEye, revela un asombroso nivel de sofisticación: fue un ataque altamente coordinado, de un estado-nación, que utilizó una amplia gama de técnicas avanzadas que parecían estar adaptadas para un atraco a FireEye.En un comunicado, el CEO de FireEye, Kevin Mandia, dijo:

"Los atacantes adaptaron sus capacidades de clase mundial específicamente para atacar a FireEye. Están altamente entrenados en seguridad operativa y ejecutados con disciplina y enfoque... utilizaron una combinación novedosa de técnicas no presenciadas por nosotros o nuestros socios en el pasado.”

Es el combustible de una pesadilla para cualquier CISO, y si algo como esto puede sucederle a FireEye, entonces pone en perspectiva cuán vulnerables son realmente muchas empresas.

... excepto que es una noticia aún peor para la organización promedio. FireEye es una de las compañías de ciberseguridad más reconocidas del mundo, y el ataque exitoso contra ellos requirió de ladrones con nivel de mente maestra que lanzaron todo lo que tenían en una ejecución coordinada y a gran escala. Para muchas empresas, una lucrativa violación de datos podría ser posible explotando un simple fallo, de forma bastante rápida, sin necesidad de ninguna mente maestra. Y la inyección SQL es un ejemplo común de esto último, que sigue siendo aprovechado por los script kiddies que buscan ganar dinero rápido en la Dark Web.

En mayo de 2020, un hombre fue acusado de tráfico de tarjetas de crédito y delitos de piratería informática, cuando se le encontraron soportes digitales que almacenaban cientos de miles de números de tarjetas de crédito activas. Los cosechó todos utilizando técnicas de inyección SQL, en una operación que comprometió a muchas empresas y a millones de sus clientes.

Como industria, estamos mejorando todo el tiempo, pero la inyección SQL sigue siendo una amenaza significativa y afecta mucho más que los sistemas heredados o sin parches.

Por qué los desarrolladores lo mantienen vivo (y por qué no es culpa suya)

Seguimos diciendo que la inyección SQL es sencilla de arreglar, y que el código debería estar escrito de forma que no la introduzca en absoluto. Como la mayoría de las cosas, sólo es fácil cuando te han enseñado a hacerlo bien.

Aquí es donde la rueda empieza a tambalearse en el proceso de desarrollo de software. Los desarrolladores cometen los mismos errores, lo que lleva a que vulnerabilidades recurrentes como la inyección SQL se infiltren en el código base. Sin embargo, esto no debería ser una sorpresa. La mayoría de los ingenieros terminan su carrera sin haber aprendido mucho sobre codificación segura, si es que han aprendido algo. La mayor parte de la formación en el puesto de trabajo es inadecuada, especialmente en un entorno en el que la seguridad no se considera una prioridad empresarial en su función.

No estamos dando a los desarrolladores una razón para preocuparse por la seguridad, ni una plataforma sólida para empezar a ser más conscientes de la seguridad. Los patrones de codificación deficientes mantienen vivos errores como la inyección de SQL, y tenemos que hacer más hincapié en la concienciación de los desarrolladores en materia de seguridad, así como darles el tiempo necesario para que escriban un código de calidad y más seguro. Los patrones de codificación seguros pueden llevar más tiempo para escribir, pero el tiempo invertido crea eficiencias que son inestimables más adelante en el proceso.

¿Habrá alguna vez un funeral por inyección SQL?

Una metáfora funeraria es un poco mórbida, pero realmente, nuestros datos sensibles estarían más seguros si la inyección SQL fuera puesta a descansar para siempre. Sin embargo, estoy seguro de que celebraremos unos cuantos cumpleaños más antes de llegar a eso, porque la cultura en torno a la seguridad preventiva y el énfasis en la codificación segura simplemente no ha evolucionado lo suficiente como para empezar a clavar el ataúd.

Los lenguajes más nuevos y robustos en cuanto a seguridad, como Rust, están ayudando a erradicar algunos de los errores con los que hemos lidiado durante mucho tiempo al utilizar funciones más seguras, pero hay una enorme cantidad de software heredado, sistemas antiguos y bibliotecas que seguirán en uso y potencialmente vulnerables.

La responsabilidad compartida de la seguridad en el proceso de desarrollo (hola, DevSecOps) será crucial si queremos que los exploits "fáciles" se cierren definitivamente. Los desarrolladores deben participar en el proceso desde el principio y recibir apoyo para asumir la responsabilidad de su parte en la creación de un código más seguro y mejor.

¿Cómo deben abordar los desarrolladores la corrección de un fallo de inyección SQL en su código?

Hemos elaborado una guía completa para los desarrolladores que quieran aprender a identificar y corregir la inyección SQL. Completada con un desafío gamificado en el lenguaje de programación de su elección (¡incluso COBOL!), proporciona un gran aprendizaje básico que ayudará a todos los desarrolladores a crear un código más seguro y de mayor calidad.

Una versión de este artículo apareció en Revista de Ciberdefensa. Se ha actualizado y sindicado aquí.

Una relación que se construye sobre la base inestable de la desconfianza es, bueno, mejor abordarla con bajas expectativas. Lamentablemente, este puede ser el estado de la relación de trabajo entre los desarrolladores y el equipo de AppSec dentro de una organización. Por lo general, la situación no es ideal y conduce a malos resultados en un mundo de dependencias tecnológicas de alto riesgo.

Los desarrolladores prosperan en la resolución de problemas, la creación de características y la creatividad en su trabajo. La seguridad de las aplicaciones, por otro lado, tiene la poco envidiable tarea de encontrar fallos de seguridad en su código, devolverlo para que se corrija y proporcionar auditorías e informes que estropean el brillo de los proyectos favoritos de los ingenieros. No es justo culpar únicamente a los desarrolladores -la seguridad no es su prioridad ni forma parte de sus KPI- ni se puede penalizar al sobrecargado equipo de AppSec por hacer simplemente su trabajo. Sin embargo, para las mejores prácticas de ciberseguridad, y mejores resultados de seguridad a nivel organizativo, realmente necesitan empezar a jugar bien.

Y todo comienza con la confianza.

La imagen de "chico malo" de AppSec se interpone en el camino de la armonía de DevSecOps.

Si tus únicas interacciones con alguien se producen cuando te señalan dónde te has equivocado, lo más probable es que su aportación no se vea con buenos ojos.

Rara vez se ve a menos que haya un problema, las connotaciones negativas de la presencia del equipo de seguridad tienden a causar cierta fricción. La relación ha estado fracturada durante bastante tiempo, con los desarrolladores viendo al equipo de AppSec como bloqueadores de su creatividad, proceso y envío puntual de características, mientras que AppSec se cansa mucho de señalar continuamente errores de seguridad comunes que han existido (al igual que su remedio) durante décadas.

Con plazos cada vez más imposibles, equipos con pocos recursos y un fuerte deseo de evitar el retrabajo, los desarrolladores suelen esperar hasta el último momento posible para enviar su código, haciendo que la ventana de oportunidad para la revisión e intervención de AppSec sea lo más pequeña posible. Un proceso disfuncional, y que tiene un impacto inaceptable de aumento del riesgo de ciberseguridad para la organización.

Para los especialistas en seguridad, es un caso de "no disparar al mensajero" - después de todo, su trabajo es encontrar errores y reportarlos para que puedan ser remediados - nada personal. El problema es que a menudo pueden hacer recomendaciones que no son las más adecuadas para la pila tecnológica de la empresa, por lo que pueden considerarse poco útiles en el panorama general del desarrollo de software interno.

La noción de AppSec como el villano es contraintuitiva para la mayoría de las metodologías de desarrollo, pero para DevSecOps, es un desastre. El estándar de oro se ha movido mucho más allá de Waterfall, Agile, e incluso DevOps, en un proceso que ve la seguridad como una responsabilidad compartida desde el principio del SDLC como vital.

Para que el DevSecOps funcione, los ingenieros de software deben tener una razón para preocuparse por la seguridad, y eso pasa por entender por qué es tan importante para ellos hacer su parte para asegurar el software del mundo. Los especialistas en seguridad que se esfuerzan por extender la rama de olivo, trabajan con los directores de desarrollo para satisfacer las necesidades del equipo y asumen un papel más de mentores para fomentar la concienciación sobre la seguridad tienden a ver los beneficios a largo plazo de sus esfuerzos... y pasan algo menos de tiempo rasgándose las vestiduras por otro error XSS.

Los desarrolladores deben estar capacitados para ofrecer mejores resultados de codificación segura.

Cuando se trata de aprender codificación segura durante la educación terciaria, para muchos ingenieros es inexistente. Y no es porque estuvieran ocupados jugando al beer pong y al WoW: simplemente no forma parte de la mayoría de las titulaciones de informática y TI.

Para ello, la formación en el puesto de trabajo es a menudo la primera que recibe un desarrollador en el arte de la seguridad del software, y rara vez le hace arder el mundo. Las horas de vídeos aburridos son un método de formación habitual, al igual que los ejercicios de cumplimiento de normas que son demasiado infrecuentes como para tener un impacto real en la enseñanza de los desarrolladores de cómo codificar de forma segura, o hacer algún progreso en la reducción de las vulnerabilidades comunes en el software de una organización.

Tanto el equipo de AppSec como la cohorte de desarrollo están muy ocupados, por lo que cualquier formación debe ser significativa, atractiva y práctica. Hablando desde un entorno de desarrollo, nos encanta resolver problemas y utilizar las herramientas, por lo que la mayoría de la formación estática pasa de largo mientras nos concentramos en algo más urgente (o, seamos sinceros, interesante).

Los especialistas en seguridad de las aplicaciones están en un lugar de influencia, y pueden forjar una situación beneficiosa a largo plazo defendiendo los intereses de los desarrolladores. Buscar una formación viable que sea relevante para el trabajo y que se imparta en sus lenguajes y marcos preferidos es un gran paso para cambiar la aguja e inspirar una cultura de seguridad positiva de base dentro de una organización. Llevamos décadas intentando lo mismo, y está claro que el enfoque de formación "de talla única" no funciona. Al ayudar a proporcionar las herramientas y los conocimientos adecuados a los desarrolladores, éstos pueden mejorar su capacitación en materia de codificación segura, actuar con un mayor sentido de la seguridad y producir un código de mayor calidad.

Los esfuerzos para llegar a la misma página deben venir de ambas partes.

Es fácil que personas con objetivos diferentes se malinterpreten o, en el peor de los casos, se vuelvan algo desconfiadas. El objetivo de AppSec es mantenerse al día con la avalancha de código que se produce, y encontrar cualquier problema de seguridad que pueda poner en peligro los datos, el acceso no autorizado y los ataques maliciosos que tienen el potencial de destruir el sentimiento positivo de los clientes durante años.

Los desarrolladores, entre otras cosas, construyen funciones con una fecha límite. Tienen la tarea de hacer que el software sea funcional y bonito, y de ser los creadores de experiencias digitales únicas que mantengan a los clientes fieles. Ya tienen mucho que hacer, y lanzarles una bola curva en forma de responsabilidad por la seguridad es una perspectiva desalentadora. Se considera que el problema de la seguridad del código es de AppSec, y aunque eso era algo factible en los años 90 (ya sabes, antes de que se pudieran hackear nuestros coches y de que pudiéramos llevar toda nuestra vida en un superordenador de bolsillo llamado teléfono inteligente), simplemente hay demasiado código y no hay suficientes personas que lo hagan pasar por el guante de la seguridad.

Con una buena dosis de empatía, además de la habilitación para hacer de la seguridad una prioridad desde el principio del proceso de creación de software, AppSec y los desarrolladores pueden ver formas de alinear sus objetivos. Después de todo, una cultura de seguridad positiva depende de ello, y los desarrolladores conscientes de la seguridad son el ingrediente secreto para detener las vulnerabilidades comunes, incluso con una escasez de habilidades de ciberseguridad cada vez mayor.

El respeto mutuo del tiempo tiene inmensos beneficios.

Como he dicho antes, todo el mundo está muy ocupado cuando se trata de hacer magia (es decir, software increíble). Los desarrolladores necesitarán un tiempo de trabajo asignado para realizar una formación viable y práctica que desarrolle sus habilidades de codificación segura, y cualquier programa de formación debería ser hiperrelevante por diseño.

El personal de seguridad de las aplicaciones pierde su tiempo solucionando las mismas vulnerabilidades del Top 10 de OWASP una y otra vez, y los desarrolladores tienen el suyo reducido con ejercicios de poco compromiso que refuerzan la idea en sus mentes de que la seguridad es una tarea.

Las experiencias de aprendizaje seleccionadas son vitales, y ayudan a ir al grano mediante la entrega contextual y en tamaño de bocado de la formación pertinente, justo en el momento en que se necesita.

Al crear un curso de codificación segura personalizado que se adapte a los resultados deseados y a los itinerarios de aprendizaje internos, se respeta el tiempo y el flujo de trabajo del desarrollador y, al mismo tiempo, se trabaja para lograr una reducción cuantificable de las vulnerabilidades y los riesgos de ciberseguridad para la empresa. Es una victoria rápida en la búsqueda de acabar con las rivalidades blandas y avanzar en el salvaje oeste de la ciberseguridad como un frente unido.

La última función de aprendizaje contextual deSecure Code Warrior, Coursesya está disponible.

‍

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.

Cuando hablo con los desarrolladores sobre seguridad, uno de mis mantras es que "el único código de calidad es el código seguro". Esto sigue siendo cierto; puede que nos hayamos librado del desastre cuando el software vulnerable estaba en la calle en los años 90, pero no vale la pena correr el riesgo hoy en día. A lo largo de los años, muchos han trabajado duro para inculcar a los desarrolladores una mentalidad consciente de la seguridad y, al hacerlo, han conseguido que la seguridad sea sinónimo de calidad cuando se trata de un autoassessment de su código.

Sin embargo, después de reflexionar (y de debatir con mis compañeros), quizá sea simplificar demasiado el concepto. Es totalmente posible crear un código que sea realmente seguro, pero que muestre signos de una técnica de desarrollo novata, o de otras áreas problemáticas que lo hagan menos que ideal.

Nuestro sector habla largo y tendido sobre la noción de "desplazamiento hacia la izquierda". En mi opinión, se trata de "empezar" por la izquierda permitiendo a las cohortes de ingenieros compartir la responsabilidad de la seguridad (al ser un aspecto de la calidad), y dándoles el poder de borrar las vulnerabilidades comunes al alcance de su mano (literalmente). Sin embargo, a la luz de este enigma actual, parece que hay que ir un poco más allá.

El código de cierto nivel de calidad es, por definición, también seguro, pero todo el código seguro no es necesariamente de buena calidad. ¿Es la fórmula de empezar por la "izquierda de la izquierda" para garantizar unos estándares de codificación seguros puros?

¿Qué aspecto tiene un código seguro de "mala calidad"?

Pongamos la lupa sobre este fragmento de código:

Si analizamos este código desde el punto de vista de la seguridad, este fragmento es efectivamente seguro, y no es un punto de entrada para que un atacante explote una vulnerabilidad de inyección SQL.  

¿Es un ejemplo de código de alta calidad? Desgraciadamente, no. Un simple cambio en el argumento de un int(eger) a un valor String permite que la entrada del usuario de forma libre manipule la consulta, en contraste con un número que no puede. Ese cambio -o un copiado y pegado desordenado del String sql desde otro lugar- crea inmediatamente un entorno en el que son posibles las vulnerabilidades de inyección SQL, y todos los riesgos asociados a ellas:

Las medidas de seguridad tenían aquí un alcance muy limitado, mientras que un desarrollador más minucioso (o, experimentado) podría haber adoptado un enfoque diferente y haber considerado las implicaciones de una estructura de argumentos ineficiente. Enviar código de esta manera no sólo es una mala práctica, sino que da un mal ejemplo a otros miembros de la cohorte de desarrollo.

La "triple amenaza" del software: Forma, función, ¿fortaleza?

Una "triple amenaza" en la industria del entretenimiento es un individuo que puede actuar, bailar y cantar con un nivel igualmente alto de habilidad. Son las personas temidas y envidiadas en cada audición, y son los unicornios de un espacio ya competitivo. Cada industria tiene su propia versión de un ejemplo excepcional de sus productos y servicios, y el software no es una excepción.

Si pensamos en tres elementos clave en las aplicaciones que son difíciles de equilibrar con una calidad igual (alta), podrían ser la funcionalidad/elegancia, más la seguridad férrea, más la rentabilidad si se tiene en cuenta la velocidad de entrega requerida. Ahora bien, este último atributo es, sin duda, un factor definitorio de la aplicación de las otras dos opciones, y puede ser un catalizador para que la calidad general decaiga con el tiempo.

Sin embargo, ¿es necesario que todos los programas informáticos actúen como Hugh Jackman, o podemos salirnos con la suya con Nicolas Cage? Pongámoslo así: si puedes tener a Lobezno en tu equipo, entonces da lo mejor de ti.

Martin Fowler se preguntó si la alta calidad merecía la pena en el desarrollo de software, y llegó a la conclusión de que no sólo "merecía la pena", sino que además era más barata con el tiempo. La mayoría de los usuarios no van a mirar bajo el capó para evaluar si el código es un desastre, ni si la seguridad se hizo tan importante todo lo demás. Sin embargo, los que están en las herramientas perderán un tiempo precioso rehaciendo el código descuidado para añadir nuevas características, o rastreando las partes principales del proyecto para entender lo que está pasando, o, el peor de los casos: arreglar una vulnerabilidad que ha rebotado del equipo de AppSec y ha retrasado la producción. Dedicar tiempo ahora a hacer que el código sea seguro y de buena calidad ahorra muchos dolores de cabeza en el futuro, por no mencionar el coste de desentrañar un trabajo mal ejecutado.

Los desarrolladores expertos en seguridad escriben un código que mantiene su visión creativa y de resolución de problemas en la entrega de características, teniendo en cuenta la eliminación de las trampas de seguridad comunes que los ingenieros pueden controlar en su etapa del proceso. El código seguro no es terriblemente eficaz de forma aislada, y por eso la noción de empezar "por la izquierda de la izquierda" ayudará a respaldar una cultura de seguridad como segunda naturaleza para los desarrolladores, incorporada a su capacidad de ofrecer características sorprendentes con un riesgo reducido.

Empezar por la "izquierda de la izquierda" es fundamental para una experiencia de usuario segura.

La seguridad ha sido una consideración en la experiencia del usuario de software durante mucho tiempo, aunque claramente ha tenido un éxito desigual. Los errores de configuración de la seguridad representaron el 21% de las filtraciones de datos en la nube durante el año pasado, con errores de aficionados como el almacenamiento de contraseñas en texto plano que provocaron graves pérdidas de productividad, ingresos y confianza de los clientes en las empresas afectadas.

Además, los propios usuarios pueden ser su peor enemigo cuando se trata de proteger sus propios datos. Demasiada gente sigue usando "contraseña" como contraseña, o usando la misma combinación en varias cuentas sensibles.

No conozco a ningún desarrollador que se ponga a dar puñetazos cuando le dicen que tiene que trabajar en una pantalla de inicio de sesión, y no es de extrañar: es un equilibrio delicado diseñar un flujo de seguridad que sea robusto, funcional y que los usuarios puedan navegar de una manera que tenga sentido para ellos, con la menor interrupción.

Si se introducen demasiados pasos y restricciones complejas, los usuarios pueden desconectarse para no volver (un desastre para una aplicación nueva), si se hace demasiado confuso, se puede acabar provocando una migraña colectiva en el equipo de soporte mientras se atienden las consultas de los usuarios que intentan acceder a sus cuentas. Si lo haces demasiado fácil, estarás fallando en la parte de seguridad.

Una experiencia de usuario segura y satisfactoria debe integrar la seguridad en un flujo que tenga sentido y que se presente de forma que no desvirtúe todo lo demás que tiene de atractivo el software. Sin duda se puede cumplir el objetivo de codificar una función de inicio de sesión segura, poniendo todo tipo de requisitos de contraseñas complejas, CAPTCHA, mini-jefes y cuatro oleadas de zombis, pero si es un lío total que repele a los usuarios, se está perdiendo el objetivo.

Sentar las bases de la excelencia del software.

Como desarrollador, sé que la gran mayoría de nosotros nos sentimos orgullosos de nuestro trabajo y queremos hacer lo correcto. Las molestas bolas curvas, como las limitaciones de tiempo, los cambios repentinos en el objetivo actual o las correcciones urgentes, pueden interrumpir el flujo y conducir a errores, pero la cruda verdad es que muchos ingenieros de software no están preparados para el éxito.

Empezar por la "izquierda de la izquierda" es un concepto que da prioridad a los desarrolladores, y requiere que las organizaciones se tomen en serio la mejora de su cohorte de ingenieros. Los desarrolladores concienciados con la seguridad valen su peso en oro, y el apoyo en forma de formación, la provisión de las herramientas adecuadas y la oportunidad de ser tutelados por desarrolladores más experimentados fomentará un entorno en el que el código se elabore con una mentalidad que dé prioridad a la seguridad, con la precisión y la atención al detalle necesarias para llevar el software al siguiente nivel.

¿Listo para encender el fuego de la codificación segura en ti mismo? Acepta el reto.

‍

Una versión de este artículo apareció en DevOps.com. Se ha actualizado y sindicado aquí.

El campo de juego entre los héroes y los villanos de la ciberseguridad es notoriamente injusto. Los datos sensibles son el nuevo oro, y los atacantes se adaptan rápidamente para burlar las defensas, explotando los fallos de seguridad grandes y pequeños para obtener un potencial botín.

El volumen de código que se produce es demasiado grande para que los expertos en seguridad -cada vez más escasos- puedan enfrentarse a él, y el creciente coste de las violaciones de datos es la prueba de que algo tiene que ceder. Afortunadamente, por el bien de nuestra seguridad digital y la cordura de los CISO de todo el mundo, el movimiento DevSecOps está ayudando a incorporar a los desarrolladores en el viaje de la seguridad desde el principio del proceso de desarrollo de software. Se les está reconociendo como la primera línea de defensa contra los ciberatacantes, con el poder de eliminar las vulnerabilidades comunes a su alcance.

Sin embargo, sus capacidades defensivas sólo son tan buenas como la formación que reciben, y eso es otro guante que los equipos de seguridad deben correr. Para muchos desarrolladores que reciben formación en codificación segura en el trabajo, su principal desafío es mantenerse despiertos durante las actividades que no requieren intervención y que no son efectivas, ni les inspiran a mantener la seguridad en primer plano. El vídeo sin alma courses no nos está llevando a ese punto, los eventos anuales simbólicos de "marcar la casilla" son una pérdida de tiempo, y nadie está ganando contra el potencial actor de la amenaza maliciosa que está esperando para saltar en una pequeña ventana de oportunidad.

En esta etapa de nuestra industria, hemos descubierto que la educación contextual y práctica que se imparte en lenguajes y marcos de programación relevantes, con retos que imitan los que un desarrollador podría encontrar en el mundo real, es un enfoque mucho más atractivo.

Esta es la primera fase de la búsqueda de un desarrollador para ayudar a los gurús de AppSec a acabar con las vulnerabilidades comunes, pero la segunda fase es donde los escenarios deben ser reales para una fuerza defensiva supercargada y consciente de la seguridad.

El aprendizaje con andamios es fundamental en la educación de adultos

Cuando se trata de una formación extracurricular courses o en el puesto de trabajo, a menudo se pasa por alto que los adultos traen consigo un cierto nivel de experiencia y conocimientos existentes. Una buena formación se suma a esta base y está estructurada de manera que permite una comprensión más profunda y una autonomía más rápida en el proceso de aprendizaje.

La educación con andamiaje es un método de aprendizaje potente y positivo que trata de activar y mejorar la experiencia previa, al tiempo que continúa construyendo nuevas habilidades -en trozos manejables- que permiten al alumno abordar tareas cada vez más difíciles con más confianza. Por lo general, se trata de una metodología que se complementa con buenas dosis de demostración, ayudas visuales y exploración dirigida por el alumno.

Si relacionamos este enfoque con la formación en seguridad de los desarrolladores, no es de extrañar que se prefiera desde hace tiempo el método dinámico de aprender haciendo en lugar de la monotonía del aprendizaje estático basado en la teoría. Los desarrolladores son libres de ser los dueños de su dominio, y deben ver que su tiempo está bien empleado.

En ese sentido, aprender a codificar de forma segura en un entorno hiperrelevante y contextual es clave, pero el "nivel superior" de este paso es ver un exploit de código vulnerable en acción. Con el contexto de las vistas del frontend y del backend una al lado de la otra, hay un vínculo tangible entre las acciones realizadas durante el proceso de codificación, y lo que un atacante puede hacer potencialmente con esquinas cortadas, configuraciones erróneas, o accidentes que no son detectados y remediados.

Pase de la retirada a la aplicación para un enfoque de seguridad verdaderamente preventivo

Experimentar el impacto de las vulnerabilidades de seguridad de primera mano es una pieza vital del rompecabezas de la educación, y es una bestia bastante rara, incluso con las opciones de formación de seguridad más modernas para los desarrolladores. El trabajo fundacional dedicado a perfeccionar las habilidades para detectar y remediar las vulnerabilidades, y recordar esa experiencia para eliminar los mismos errores en el código a medida que se escribe es extremadamente importante, pero no es el cuadro completo. Ver cómo un código vulnerable es explotado por un actor malintencionado añade una poderosa capa de contexto, que realmente hace hincapié en la importancia de asegurar el código, y aplicar los conocimientos de seguridad ganados con esfuerzo para cerrar cada ventana de oportunidad.

Está generalmente aceptado que a los desarrolladores no les gusta la seguridad, y les gusta aún menos la formación en seguridad. Sus experiencias con los especialistas en seguridad de las aplicaciones pueden ser muy frías, y el retrabajo causado por el equipo de seguridad que devuelve el código vulnerable a los desarrolladores para que lo corrijan es la perdición de su existencia. Para un equipo de ingenieros que ya está muy disperso, la seguridad es un problema ajeno, no su prioridad, y un obstáculo para su creatividad natural y su objetivo principal de crear funcionalidades. Sin embargo, simplemente hay demasiado código, demasiadas infracciones y demasiado riesgo para los datos del mundo para que esta mentalidad continúe.

Un proceso funcional de DevSecOps hace que los desarrolladores trabajen en armonía con los equipos de seguridad desde el principio del SDLC, y la oportunidad de un aprendizaje aplicado en el que puedan interactuar con un exploit simulado y ver el impacto de un código mal protegido contribuye en gran medida a que los desarrolladores se pongan de acuerdo con esos molestos responsables de la seguridad de las aplicaciones (que no son tan malos después de todo).

El aprendizaje interactivo prepara a los desarrolladores para la lucha de jefes

En el momento de redactar este informe, se habían producido dos importantes filtraciones en un periodo de 7 días: Razer anunció que se habían expuesto más de 100.000 registros de datos sensibles, mientras que la cadena de suministros de oficina Staples también informó de una filtración de datos similar. Más de mil millones de registros sensibles han sido expuestos en lo que va de 2020, y esta preocupante tendencia no muestra signos de desaceleración. En pocas palabras, los actores maliciosos tienen la sartén por el mango, y los desarrolladores conscientes de la seguridad son muy necesarios para servir como primera línea de defensa.

Losretos interactivos que se centran en la simulación de tales infracciones hacen que los desarrolladores pasen de la memoria pasiva a la aplicación de habilidades que tienen un impacto en la verdadera lucha de jefes: detener a los atacantes en su camino.

‍

Es ese momento especial del año (para nosotros, al menos) en el que reflexiono sobre nuestra vuelta más reciente alrededor del sol, y sobre lo que se ha hecho en los trescientos sesenta y cinco días anteriores para posicionarnos para un nuevo año de crecimiento, lecciones e inevitable imprevisibilidad.

Aunque no creo que nadie pudiera prever los giros del año pasado -después de todo, creo que la mayoría de nosotros nos hemos enfrentado a más bolas curvas que los Dodgers de Los Ángeles-, seguimos aquí. El tic-tac del calendario no detuvo de golpe los puntos de dolor del Año que no puede ser nombrado, pero a mi alrededor veo la inquebrantable resistencia de las personas, las empresas y nuestro sector.

Entonces, ¿qué progresos hemos hecho en nuestro objetivo de asegurar el código en toda la galaxia?

Hemos ampliado nuestra gama de productos.

La plataforma de formación Secure Code Warrior siempre será el corazón y el alma de nuestra oferta, pero nuestras principales prioridades son crear más variedad y más herramientas elegidas por los desarrolladores.

Queremos inspirar a los desarrolladores para que adopten un enfoque de codificación segura y preventiva que permita a todos los equipos enviar software de calidad con confianza.

Estoy muy orgulloso de detallar lo que nuestro equipo de producto ha trabajado tan duro para lanzar; han pateado goles increíbles durante todo el año:

• Adquirimos Adversary.io e integramos su tecnología, su equipo increíblemente capacitado y sus clientes empresariales en menos de 9 meses.
• Hemos alcanzado el increíble hito de admitir más de 50 lenguajes de programación, incluidos los pilares de la infraestructura como código, como Docker, Ansible, Terraform, Kubernetes, Powershell y CloudFormation, así como los nuevos niños del bloque, como Rust y Go.
• Llevar el conocimiento de la seguridad al desarrollador mediante el lanzamiento de extensiones totalmente nuevas para GitHub Actions y Issues, además de Atlassian JIRA Cloud & Server, que proporciona aprendizaje contextual justo donde los desarrolladores juegan sin necesidad de cambiar de tarea
• Orientación sobre la calidad del código en tiempo real en el IDE con Sensei, ahora disponible en el mercado de JetBrains para que cada desarrollador detecte errores de seguridad, aplique las mejores prácticas, comparta conocimientos y evite problemas de rendimiento y deudas técnicas
• Facilitando a las empresas el compromiso con los desarrolladores y la ampliación de la codificación segura mediante el lanzamiento de Coursesuna nueva función que permite crear itinerarios de aprendizaje curados para los objetivos más relevantes para una organización y sus metas de seguridad. También hemos añadido Missionsuna emocionante mejora de la plataforma insignia, que pone a los desarrolladores en el asiento del piloto de un exploit. Se trata del siguiente paso en un enfoque de aprendizaje basado en andamios para ofrecer a los desarrolladores una base viable y permanente para el éxito.

... y si conoces a algún principiante en codificación, debería echar un vistazo a la aplicación gratuita, Secure Code Bootcamp, y comenzar su viaje por la seguridad.

Aterrizamos, nos expandimos, influimos.

Nos gusta enfocar la codificación segura de una manera un poco diferente y, naturalmente, esperamos que este espíritu se extienda por toda la industria. Es importante que los desarrolladores reconozcan su poder en la lucha contra los ciberatacantes, y conseguir que disfruten aprendiendo sobre seguridad es un objetivo primordial.

Miles de desarrolladores se unieron a nuestro tournaments virtual desde todo el mundo, con más de 80 celebrados solo en 2020. Nos encantó que la gente jugara como parte del Universo GitHub, los eventos globales de Cisco y la DevSecCon.

Hemos analizado nuestros datos y hemos visto que cientos de miles de usuarios únicos han jugado en nuestra plataforma en 2020, lo cual es alucinante si pienso en cómo empezamos hace seis años.

Me alegró mucho ver que habíamos aumentado significativamente nuestro alcance entre las empresas de la lista Fortune 1000, cada una de ellas dispuesta a probar algo nuevo como parte de sus programas de seguridad. Encontramos sinergias con las empresas tecnológicas en particular, muchas de las cuales pasaron a trabajar a distancia y vieron el valor de las opciones de formación a distancia.

El Equipo Asombroso se hizo más grande, y más fuerte, juntos.

Una de las mayores evoluciones que tuvimos como empresa el año pasado fue la adquisición de la empresa de ciberseguridad con sede en Islandia, Adversary. Teníamos mucho en común: una postura similar en el enfoque de la ciberseguridad centrado en las personas, valores alineados y productos complementarios. Acogimos a su equipo en el nuestro, ganando una experiencia y un talento inestimables entre grandes personas.

También hemos dado la bienvenida a John Wilson como vicepresidente senior de Ventas Globales, beneficiándose de su amplia trayectoria de 25 años impulsando el crecimiento y convirtiendo a las empresas de tecnología en la nube y de ciberseguridad en líderes del mercado. Sus amplios conocimientos técnicos han sido una fuerza innovadora en empresas como Symantec, Qualys, BlackBerry y Verizon, y no podríamos estar más contentos de tenerlo trabajando con nosotros.

La falta de oficinas físicas no nos impidió incorporar a sesenta nuevos empleados en cinco países y asegurarnos de que pudieran empezar a trabajar con apoyo virtual, presentaciones y, por supuesto, el codiciado paquete de regalos para empleados entregado en su puerta.

Seguimos creciendo en todos los departamentos, todos ellos de igual importancia para lograr nuestra misión global de permitir un código de calidad a gran velocidad. Y, sin embargo, sigue pareciendo que no hemos hecho más que empezar.

2021, el año de cambiar la conversación.

Hace tiempo que tengo la sensación de que la sociedad simplemente no se preocupa lo suficiente por la ciberseguridad, y sólo cuando ocurre algo increíblemente drástico podemos ver cómo se mueve la aguja de la acción y la concienciación.

Con la enorme brecha de SolarWinds que se produjo a finales del año pasado, están saliendo a la luz más detalles. Todavía no se conoce el alcance total de los daños, pero este incidente podría ser el catalizador de un cambio generalizado. Los departamentos gubernamentales estadounidenses ya están revisando sus programas de seguridad, y el ciberespionaje es un tema muy candente entre los que tienen mucho que perder.

Todavía podemos poner un poco de diversión en todo lo que hacemos, pero ahora es el momento de arremangarse y ponerse a trabajar para cambiar de verdad la conversación.

Cada desarrollador consciente de la seguridad hace que nuestro mundo sea un poco más seguro frente a los ciberataques, y darles los conocimientos necesarios para que tengan éxito -y tal vez incluso les guste- será siempre nuestro objetivo. Trabajamos duro cada día para crear herramientas que los desarrolladores elijan para aprender sobre seguridad y crear código de la más alta calidad. El código seguro debería ser el estándar, y todos podemos echar una mano para hacerlo realidad.

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y sindicado aquí.Las predicciones en materia de ciberseguridad son una especie de tradición en nuestro sector, ya que miramos hacia el año que viene y vemos lo que puede haber en un campo que puede tener más cambios que Lady Gaga en los GRAMMY. A veces acertamos, y otras veces llega una pandemia única en una generación y nos desafía de una manera que nunca hubiéramos esperado.

Sin embargo, no nos centremos en eso. Se trata de 2021, y aunque nos llevaremos algunas de las adaptaciones de 2020, hay muchas cosas en el futuro de la ciberseguridad, y las más interesantes ni siquiera están ocurriendo aquí en la tierra.

Así es, estamos prediciendo que 2021 es el año en el que llevamos un nuevo tipo de carrera espacial a la corriente principal: mantener nuestra galaxia a salvo de las amenazas cibernéticas.

La NASA ya emplea a personas de ciberseguridad que trabajan fuera del ámbito terrestre (y es más raro de lo que crees)

No es de extrañar que la NASA emplee a muchos expertos en seguridad, así como a ingenieros que se dedican a fortificar el software y las operaciones de la NASA para que resistan los ciberataques más potentes.

... lo que puede sorprender es el hecho de que empleen a un ingeniero de satélites senior -Kenneth F. Harris II, de 28 años- para proteger y defender los satélites en órbita. Lejos de un proceso automatizado, Kenneth es un Superman de la vida real que se interpone (metafóricamente) entre los satélites de la NASA y los numerosos intentos deliberados de atacarlos físicamente, además de ayudar a mitigar el riesgo de posibles amenazas cibernéticas que podrían venir de cualquier parte de la Tierra.

¿Qué está en juego si se dañan los satélites de un país? Una colisión deliberada o un agente malintencionado que aproveche una vulnerabilidad del software podría interrumpir las redes GPS, las alertas y previsiones meteorológicas y los sistemas de comunicación que damos por sentados todos los días.

Es una amenaza que podría estar literalmente fuera de nuestra órbita, pero confiamos en que el personal de seguridad centrado en la protección de activos espaciales será un nicho que experimentará una gran demanda en el futuro.

Los gobiernos ya están reuniendo fuerzas espaciales... y van a necesitar expertos en seguridad

En diciembre de 2019, el Gobierno de Estados Unidos presentó una nueva rama de sus operaciones militares, esta vez, en el espacio. La Fuerza Espacial de Estados Unidos es un departamento centrado en la tecnología con el objetivo de preservar el espacio como un "bien común global", según el secretario de Defensa estadounidense, Mark Esper: "Es importante no sólo para nuestra seguridad, sino para nuestro comercio, nuestro modo de vida, nuestra comprensión del planeta, el clima, lo que sea. Así que es muy importante que lo tratemos así y nos aseguremos de estar preparados para defendernos y preservar el espacio", dijo.

En octubre de 2020, se informó de que hasta 130 expertos en cibernética de las Fuerzas Aéreas de EE.UU. serían reasignados a las filas de las Fuerzas Espaciales, y la General de División Kimberly Crider, Jefa de Tecnología e Innovación de las Fuerzas Espaciales, identificó el espacio como "el próximo frente del conflicto cibernético".

Aunque Estados Unidos haya sido uno de los pioneros en la creación de una Fuerza Espacial, en un momento en el que podría parecer un poco exagerado y más parecido a la trama de un cómic que a un departamento serio, la ciberguerra espacial es ya un área de riesgo, y no hace falta decir que la mayoría de los países acabarán por seguir su ejemplo con un programa propio.

Tesla ya ha puesto un coche en el espacio, mientras los ordenadores circulan por nuestras carreteras

En 2018, Elon Musk envió al espacio un vehículo Tesla autodirigido. En octubre de 2020, el coche pilotado por un maniquí vestido con un traje espacial y apodado "Starman" ha recorrido 1.300 millones de millas y ha pasado por Marte.

Aunque esta situación no es un problema de ciberseguridad, es curioso que tengamos un coche haciendo una versión intergaláctica infinita de una carrera de NASCAR, mientras que nuestras carreteras aquí en la Tierra se están poblando, lenta pero seguramente, de coches conducidos por ordenadores. Cualquier cosa que funcione con software conlleva al menos algún elemento de riesgo cibernético, y el software de los automóviles ya se ha visto comprometido en otras ocasiones, con el resultado de una posible catástrofe. Los investigadores de seguridad ya han puesto a prueba a Tesla en varias ocasiones, y uno de los fallos provocó la aceleración autónoma e involuntaria del vehículo de 35 a 85 millas por hora. Vaya. Aun así, los exhaustivos programas de seguridad de Tesla establecen un alto estándar para la industria en términos de pruebas y cumplimiento.

Los vehículos autónomos son el futuro de nuestros desplazamientos personales, pero todas las miradas estarán puestas en el aspecto de la seguridad del software de su construcción a medida que entren en el mercado más actores que Tesla, y es probable que veamos cómo este mercado se dispara a partir de 2021.

Tantos avances y seguimos olvidando el factor humano

A pesar de los riesgos inherentes a las nuevas tecnologías, estamos en una época muy emocionante. La mayoría de las industrias están innovando con el uso de software de vanguardia, y no podemos esperar a ver qué es lo siguiente.

Sin embargo, parece que la industria de la ciberseguridad en su conjunto está un poco atascada. Por todas partes, el consejo más común para las organizaciones que quieren crear un software más seguro es seguir comprando herramientas, escáneres automatizados y otras soluciones que, en esencia, dejan todo en manos de los robots para resolver nuestros problemas de seguridad. El informe Hype Cycle for Application Security 2020 de Gartner detalla un amplio abanico de las últimas soluciones de seguridad; de hecho, es difícil pensar en una solución tecnológica que no se haya descrito como una opción viable para el desarrollo de aplicaciones seguras. Parece exhaustivo y parece un buen consejo. Sin embargo, lamentablemente, no hay ni una sola mención al factor humano que entra en juego en el desarrollo de aplicaciones seguras, ni al papel inmensamente beneficioso que pueden desempeñar los desarrolladores formados y conscientes de la seguridad para reducir las vulnerabilidades comunes del software. Es, con mucho, la solución más económica para los fallos recurrentes del software, y la que liberaría a las herramientas y a los expertos en seguridad para resolver los problemas más complejos.

Quizás debamos terminar con una pregunta, más que con una predicción. Será 2021 el año en que los analistas de la industria mantengan a los seres humanos al frente de la carrera por el desarrollo de software seguro?

‍

A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.

Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este fallo de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan los fallos de gestión de activos a las APIs?

El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.

En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.

En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.

Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.

Eliminación de los defectos de gestión de activos inadecuados

La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.

Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.

Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

‍

En una entrada anterior del blog se describía el Gotcha de Java "Bitwise vs Boolean Operator".

• Gotchas de Java - Operador Bitwise vs Boolean

Hemos añadido una variante de esto, y algunos otros Gotchas de Java en un pequeño y divertido concurso llamado "Challenge The Sensei".

• scw.typeform.com/to/rgw7q7OE

Si has leído la entrada del blog anterior, estarás en una buena posición para superar al menos una de las preguntas.

Pero es posible que tus amigos no lo hagan, así que si el cuestionario te parece divertido, puedes compartirlo con ellos y ver si obtienen la misma puntuación que tú.

Ya que no queremos limitarnos a hacer pruebas. Queremos tratar de usar esto para ayudar a educar y codificar el conocimiento. Así que hemos creado un repositorio de Github que tiene ejemplos de código ejecutables para el problema, y la solución.

• github.com/SecureCodeWarrior/challenge-the-sensei

Esta es una Sensei repo habilitado.

Cuando clones el repo y lo cargues en IntelliJ, asumiendo que tienes el Secure Code Warrior Sensei Plugin de IntelliJ instalado, entonces verá automáticamente que tienes una carpeta .sensei , y cargará las recetas de Sensei .

Cuando navegues por el código en el IDE deberías ver que IntelliJ te indica que el error existe en el código, y esto debería facilitarte ver el gotcha en el código:

• Pase el ratón por encima del código resaltado y verá un aviso que le indicará el error
• Utiliza la tecla de acción contextual: alt+entrada (Windows) opción+entrada (macOS) y es posible que tengamos un QuickFix disponible que pueda arreglar el código.

Se han añadido recetas deSensei para:

• Operadores Bitwise
• Dirección IP dividida
• Orden de afirmación

En el futuro añadiremos más recetas y más texto explicativo para cubrir el resto del código... pero no dejes que eso te impida echar un vistazo al código y detectar el error por ti mismo.

Y recuerda probar el test y"desafiar a la Sensei"

Gotchas de Java - Operadores Bitwise vs Boolean

> "Java Gotcha" - un patrón de error común que es fácil de implementar accidentalmente.

Un Gotcha de Java bastante sencillo en el que se puede caer accidentalmente es: utilizar un operador Bitwise en lugar de un operador de Comparación Booleana.

Por ejemplo, un simple error tipográfico puede hacer que se escriba "&" cuando en realidad se quería escribir "&&".

Una heurística común que aprendemos al revisar el código es:

> "&" o "|" cuando se utiliza en una declaración condicional probablemente no se pretende.

En esta entrada del blog, exploraremos la heurística e identificaremos las formas en que podemos identificar y solucionar este problema de codificación.

¿Cuál es el problema? Las operaciones Bitwise funcionan bien con los booleanos

El uso de operadores Bitwise con booleanos es perfectamente válido, por lo que Java no informará de un error de sintaxis.

Si construyo una prueba JUnit para explorar una tabla de verdad para ambos operadores Bitwise OR (|) y Bitwise AND (&) entonces veremos que las salidas del operador Bitwise coinciden con la tabla de verdad. Dado esto, podríamos pensar que el uso de los operadores Bitwise no es un problema.

Tabla de verdad AND

@Test
    void bitwiseOperatorsAndTruthTable(){
          Assertions.assertEquals(true, true & true);
          Assertions.assertEquals(false, true & false);
          Assertions.assertEquals(false, false & true);
          Assertions.assertEquals(false, false & false);
    }

La prueba pasa, esto es Java perfectamente válido.

Tabla de verdad de OR

   @Test
    void bitwiseOperatorsOrTruthTable(){
        Assertions.assertEquals(true, true | true);
        Assertions.assertEquals(true, true | false);
        Assertions.assertEquals(true, false | true);
        Assertions.assertEquals(false, false | false);
    }

Esta prueba también pasa, ¿por qué preferimos "&&'y "||'?

Las imágenes de la tabla de verdad se crearon con la herramienta herramienta de tabla de verdad de web.standfor.edu.

Problema: Funcionamiento en cortocircuito

El verdadero problema es la diferencia de comportamiento entre los operadores Bitwise (&, |) y Boolean (&&, ||).

Un operador booleano es un operador de cortocircuito y sólo evalúa lo necesario.

Por ejemplo

if (args != null & args.length() > 23) {
    System.out.println(args);
}

En el código anterior, ambas condiciones booleanas se evaluarán, porque se ha utilizado el operador Bitwise:

• args != null
• args.length() > 23

Esto deja mi código abierto a una NullPointerException si args es null porque siempre realizaremos la comprobación de args.length, incluso cuando args es null porque ambas condiciones booleanas tienen que ser evaluadas.

Operadores booleanos Evaluación de cortocircuitos

Cuando se utiliza un &&, por ejemplo

if (args != null && args.length() > 23) {
    System.out.println(args);
}

Tan pronto como sepamos que args != null se evalúa como falso, la evaluación de la expresión de la condición se detiene.

No necesitamos evaluar el lado derecho.

Sea cual sea el resultado de la condición del lado derecho, el valor final de la expresión booleana será falso.

Pero esto nunca ocurriría en el código de producción

Este es un error bastante fácil de cometer y no siempre es detectado por las herramientas de análisis estático.

Utilicé el siguiente Google Dork para ver si podía encontrar algún ejemplo público de este patrón:

filetype:java if "!=null & "
Esta búsqueda trajo un código de Android en el RootWindowContainer
isDocument = intent != null & intent.isDocument()

Este es el tipo de código que podría pasar una revisión de código porque a menudo usamos operadores Bitwise en las sentencias de asignación para enmascarar valores. Pero en este caso, el resultado es el mismo que el ejemplo de la sentencia if anterior. Si la intención es alguna vez nula, entonces se lanzará una NullPointerException.

Muy a menudo nos libramos de esta construcción porque solemos codificar a la defensiva y escribir código redundante. La comprobación de != null puede ser redundante en la mayoría de los casos de uso.

Este es un error cometido por los programadores en el código de producción.

No sé cómo de actuales son los resultados de la búsqueda, pero cuando ejecuté la búsqueda había resultados de vuelta con código de: Google, Amazon, Apache... y yo.

Un reciente pull request en uno de mis proyectos de código abierto fue para solucionar exactamente este error.

if(type!=null & type.trim().length()>0){
    acceptMediaTypeDefinitionsList.add(type.trim());
}

Cómo encontrarlo

Cuando comprobé mi código de muestra en unos cuantos analizadores estáticos, ninguno de ellos detectó este código de autodestrucción oculto.

Como equipo en Secure Code Warrior, creamos y revisamos una receta bastante simple de Sensei que podría recoger esto.

Dado que los operadores Bitwise son perfectamente válidos, y se utilizan a menudo en las asignaciones, nos centramos en el caso de uso de las sentencias if, y en el uso de Bitwise &, para encontrar el código problemático.

search:
  expression:
    anyOf:
    - in:
        condition: {}
    value:
      caseSensitive: false
      matches: ".* & .*"

Utiliza una expresión regular para que coincida con " & " cuando se utiliza como expresión de condición, por ejemplo, en una sentencia if.

Para solucionarlo, volvimos a recurrir a las expresiones regulares. Esta vez usando la función sed en el QuickFix para reemplazar globalmente el & en la expresión con &&.

availableFixes:
  - name: "Replace bitwise AND operator to logical AND operator"
    actions:
      - rewrite:
          to: "{{#sed}}s/&/&&/g,{{{ . }}}{{/sed}}"

Notas finales

Esto cubre el uso erróneo más común de un operador Bitwise, es decir, cuando se pretendía un operador Booleano.

Hay otras situaciones en las que esto podría surgir, por ejemplo, el ejemplo de la asignación, pero al escribir las recetas tenemos que intentar evitar la identificación falsa-positiva, de lo contrario las recetas serán ignoradas o desactivadas. Construimos las recetas para que coincidan con las ocurrencias más comunes. A medida que Sensei evolucione, es posible que añadamos más especificidad a la función de búsqueda para cubrir más condiciones de coincidencia.

En su forma actual, esta receta identificaría muchos de los casos de uso en vivo, y lo más importante, el que fue reportado en mi proyecto.

NOTA: Unos cuantos guerreros del código han contribuido a este ejemplo y a la revisión de la receta: Charlie Eriksen, Matthieu Calie, Robin Claerhaut, Brysen Ackx, Nathan Desmet, Downey Robersscheuten. Gracias por su ayuda.

---

Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"

Tenemos un montón de código fuente y recetas para estas entradas del blog (incluyendo esta) en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior .

https://github.com/securecodewarrior/sensei-blog-examples

Más información sobre Sensei