Perspectivas sobre el código seguro

Tapjacking, una combinación de «toque» y «secuestro», significa precisamente eso. Se trata de un ataque en el que el atacante secuestra los toques del usuario y lo engaña para que haga algo que no pretendía. Entonces, ¿cómo funciona y cómo lo prevenimos?

Empezaremos nuestra historia con superposiciones de pantalla. Superposiciones de pantalla o, como las llama Google, ventanas con el tipo TYPE_APPLICATION_OVERLAY. Se trata de ventanas que se dibujan sobre otras aplicaciones y, por lo general, solo ocultan una parte de la pantalla. Se utilizan con frecuencia (como en la imagen de ejemplo que aparece a continuación) cuando una aplicación solicita nuevos permisos.

De hecho, esta es una función genial y divertida, y cada vez más aplicaciones comienzan a usarla, piense en las burbujas de chat de Facebook o en la navegación de Google Maps en una esquina de la pantalla, como en la captura de pantalla de abajo.

Sin embargo, existen algunos riesgos de seguridad relacionados con estas superposiciones. Cualquier pantalla superpuesta activa puede escuchar los toques. ¿De qué otra manera sabría Facebook que hemos pulsado o arrastrado la burbuja? Esto permite que las aplicaciones te espíen y, potencialmente, roben contraseñas y datos de tarjetas de crédito.

Un paso más allá, y de ahí proviene el término tapjacking, las superposiciones pueden dibujar cosas sobre otras aplicaciones engañando al usuario para que realice diferentes acciones. El usuario cree que está interactuando con la superposición, pero en realidad, sus toques también realizan acciones en la aplicación subyacente. De esta forma, la superposición puede engañarte para que habilites ciertos permisos o cambies algunas configuraciones peligrosas, como se demuestra en este artículo vídeo antiguo de YouTube.

El vídeo de demostración de arriba se subió a YouTube en 2010, por lo que se hizo en una versión anterior de Android. Sin embargo, el ataque sigue siendo relevante hoy en día, ya que vulnerabilidades salió a la luz que permite el tapjacking en versiones más recientes de Android, como Nougat y Marshmallow.

Entonces, ¿qué puedes hacer al respecto? Como usuario, es importante darse cuenta de las consecuencias de estas superposiciones y estar al tanto de las aplicaciones que las utilizan. A partir del nivel 23 de API (Android 6.0 Marshmallow), se ha convertido en un permiso que tiene que ser otorgado explícitamente por el usuario. Sin embargo, eso deja 50% de Androidlos usuarios siguen siendo vulnerables. Aún puedes comprobar qué aplicaciones hacen uso de este permiso en la configuración, en la sección «Mostrar en lugar de otras aplicaciones».

Como desarrolladores, nos corresponde a nosotros asegurarnos de que las acciones de los usuarios se realicen con el pleno conocimiento y consentimiento del usuario. Android proporciona una configuración para tus vistas que hace precisamente eso, denominada Filtra los toques cuando están oscurecidos. Cuando está habilitada, el marco descartará los toques que se reciban cada vez que la ventana de vistas quede oculta por otra ventana visible. Es tan simple como eso, ¡listo! Filtra los toques cuando están oscurecidos a la verdad, y tu aplicación está a salvo del robo de información.

¡Buena suerte y nos vemos la semana que viene!

A veces es esencial que una aplicación pueda verificar que una acción se está realizando con el pleno conocimiento y consentimiento del usuario, como conceder una solicitud de permiso, realizar una compra o hacer clic en un anuncio. Lamentablemente, una aplicación malintencionada podría intentar engañar al usuario para que realice estas acciones sin saberlo, ocultando el propósito previsto de la visualización.

https://developer.android.com/reference/android/view/View.html

Publicado originalmente en Blog de DevSecCon.

Al haber estado en ambos lados de la valla, sé muy bien la tensión que puede surgir entre el equipo de desarrollo y los especialistas de AppSec cuando se trata de mantener las mejores prácticas de seguridad.

Es difícil; al final del día, la principal prioridad de un desarrollador es ofrecer funciones de software. Deben ser atractivas, funcionales y ayudar a mostrar el poder de la aplicación. Hoy en día, las prácticas de desarrollo ágiles son habituales, por lo que estas funciones deben completarse dentro de plazos estrictos... y la seguridad rara vez ocupa un lugar destacado en la lista de preocupaciones cuando hay mucho más en juego.

La seguridad es vista como el dominio del equipo de AppSec, que tiene la poco envidiable tarea de escanear el código (o, lo que es peor, revisarlo manualmente, línea por línea) e informar al equipo de desarrollo de que su código es inseguro o, de hecho, totalmente inutilizable. Son los palos a la antigua que destrozan su buen trabajo, frenan la innovación y, por lo general, suponen un quebradero de cabeza para los desarrolladores. Al fin y al cabo, muchos problemas de seguridad son soluciones bastante sencillas: quizás una sola línea de código podría reforzar una puerta trasera vulnerable en cuestión de minutos.

Pero este es el problema. Dado que la «seguridad» es sinónimo de experiencia negativa, los desarrolladores simplemente no están tan comprometidos con ella como deberían. Esas soluciones de una sola línea no están ocurriendo: al fin y al cabo, los chicos de AppSec se encuentran continuamente con los mismos problemas. Debe resultar bastante desalentador para ellos seguir señalando fallos en las inyecciones de SQL, más de veinte años después de que los descubriéramos por primera vez (y su subsiguiente solución).

Lo que hemos hecho hasta la fecha no funciona ni de lejos con la eficacia que esperábamos. Tenemos que centrarnos en reparar el puente entre los desarrolladores y los especialistas en AppSec, esforzándonos por lograr una cultura de seguridad positiva en la que los desarrolladores reciban las herramientas y la formación necesarias para tener un impacto real en el sector.

¿Quién sabe? ¡Puede que incluso se enamoren de él como yo!

La seguridad positiva es la forma más rápida y sencilla de mejorar la seguridad de las aplicaciones

City «y no, no se trata de un guau sobre los resultados intangibles. Es un ingrediente absolutamente vital en la receta del éxito de la codificación segura.

Los desarrolladores tienen la clave para mejorar la seguridad desde el principio de la producción, escribiendo código seguro en primer lugar. Si se crea una cultura de seguridad positiva y se consigue que los desarrolladores se entusiasmen con la seguridad de las aplicaciones, es posible eliminar las vulnerabilidades más comunes antes de que puedan escanearlas o revisarlas manualmente en el mundo de AppSec.

Es es treinta veces más caro corregir vulnerabilidades en un código que ya está comprometido, por lo que encontrar una formación que aproveche las fortalezas de los desarrolladores, despierte el interés y realmente funcione es un gran paso en la futura reducción de costos para identificar y corregir esas vulnerabilidades recurrentes.

Las iniciativas positivas centradas en los desarrolladores fomentan la cultura de seguridad adecuada.

Cuando todos están de acuerdo con las mejores prácticas de seguridad, una cultura de seguridad positiva es un subproducto positivo y vital.

Las iniciativas positivas y escalables centradas en los desarrolladores fomentan la cultura de seguridad adecuada. Involucrar a los desarrolladores con mentes creativas y que resuelven problemas es esencial para ganárselos, así como para garantizar que los nuevos empleados puedan cumplir rápidamente con las expectativas de seguridad del equipo. Ponte en contacto para obtener información general sobre cómo ha evolucionado la relación de seguridad entre los desarrolladores e ideas sobre cómo implementar un programa de concienciación sobre seguridad exitoso en sus propias organizaciones.

Deleting files on a computer system is tricky. Everybody, even your mother, has deleted a file too many before and has been happy to find it still in the trash and able to recover it.

Data in computer systems is represented by a sequence of bits. That means the system needs to do some bookkeeping within the file system to know which bits represent which file. Among this information is the size of the file, the time it was last modified, its owner, access permissions and so on. This bookkeeping data is stored separately from the contents of the file.

Usually, when a file is removed nothing happens to the bits representing the file, but the bookkeeping data is changed so that the system knows this part of the storage is now meaningless and can be reused. Until another file is saved in this location and the bits in this location are overwritten, you can often still recover the data that was saved. This not only improves the speed of deleting files but is often a useful feature to undo the deletion.

However, there are downsides to this approach. When an application on a computer system handles sensitive information it will save this data somewhere on the file system. At some point, when the information is no longer needed, this data may be deleted. If no extra care is taken this data may still be recoverable even though the intention of the developer was that all data was deleted.

The easiest way to completely erase that data is to rewrite the file content with random data (sometimes even several times over). There are several existing methods of secure file removal and they vary across storage types and file systems such as the Gutmann method. However, for day to day application use, these are a bit overkill and you can just overwrite the data yourself.

Be careful though! Do not use all zeros or other low entropy data. Many filesystems may optimize writing such sparse files and leave some of the original content. It is recommended to generate securely random data to overwrite the entire file contents before deleting the file itself.

Data remanence is the residual physical representation of data that has been in some way erased. After storage media is erased there may be some physical characteristics that allow data to be reconstructed.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

A medida que la cantidad de ciberamenazas sigue creciendo, las organizaciones están haciendo concesiones diarias entre seguridad, practicidad y velocidad, exponiéndose a riesgos en el proceso. Se necesitan nuevos enfoques para proteger la codificación, así que Secure Code Warrior colaboró con Evans Data Corp. para realizar una investigación primaria sobre las actitudes de los desarrolladores hacia la codificación segura, las prácticas de código seguro y las operaciones de seguridad (descargue el documento técnico) aquí).

Lo que reveló este informe es que, si bien el pensamiento reactivo de la «vieja escuela» sigue dominando, existe una creciente conciencia de la necesidad de soluciones más proactivas, que conviertan a los propios desarrolladores en la primera línea de defensa.

Cualquier exploración de la adopción de prácticas de codificación seguras debe comenzar con una comprensión de las personas involucradas en su implementación, sus percepciones al respecto y su capacidad para implementarla. Esto nos lleva entonces a la pieza más importante del rompecabezas: ¿cómo se les puede capacitar para programar de forma más segura desde el principio y para enviar código de calidad más rápido y con confianza?

Codificación segura: ¿dónde estamos ahora y qué tiene que cambiar? Descargar la infografía «El elemento humano» ahora.

Perspectivas actuales: reactivas frente a proactivas

Cuando se preguntó a los desarrolladores y gerentes de desarrollo sobre las actividades que asocian con la codificación segura, las tres respuestas principales fueron:

• Uso de herramientas de escaneo en aplicaciones implementadas.
• Revisar manualmente el código en busca de vulnerabilidades.
• La práctica activa y continua de escribir software que esté protegido contra las vulnerabilidades.

Como podemos ver, dos de las tres respuestas principales seguían centrándose en enfoques reactivos: la primera dependía de las herramientas (escáneres) y la segunda de que el desarrollador (es decir, el ser humano) realizaba comprobaciones manuales.

Al mismo tiempo, dos de las tres actividades nominadas se basan en el elemento humano. Esto apunta a una percepción cada vez mayor de la seguridad como un problema humano. Sin embargo, de todas las actividades nominadas, la más reveladora es la número 3, que identifica el factor humano escribiendo software que esté protegido contra las vulnerabilidades en primer lugar. Esto pone de manifiesto un cambio hacia la izquierda: un enfoque proactivo y preventivo que convierte la seguridad en software desde el principio del SDLC.

¿Dónde encaja la seguridad en el SDLC?

Cuando se pregunta a los desarrolladores y gerentes de desarrollo dónde ven que las prácticas de código seguro se integran en el SDLC, las opiniones difieren. El 55% de los gerentes cree que la codificación segura está integrada en todo el proceso de desarrollo, en comparación con solo el 43% de los desarrolladores. La diferencia podría reflejar las diferentes funciones de estos dos grupos dentro del SDLC. La administración suele involucrarse menos en el trabajo real de programación y tiende a tener una visión de más alto nivel, mientras que los desarrolladores pueden preocuparse más por los aspectos prácticos.

Sin embargo, desde el punto de vista general de la seguridad y la calidad del código, lo alarmante es que solo el 13% de los desarrolladores y el 10% de los administradores afirman que las prácticas de código seguro deberían integrarse en las etapas de diseño, justo al principio del SDLC. Se trata de una oportunidad enorme que no se ha aprovechado. Según un estudio de IBM, es treinta veces más caro corregir las vulnerabilidades en el código posterior al lanzamiento que si se detectaran y corrigieran desde el principio.1 Este es un poderoso incentivo para emprender una nueva defensa proactiva y dirigida por personas de la seguridad del software, que permita a los desarrolladores programar de forma más segura desde el principio. La seguridad del software no se puede resolver confiando únicamente en las herramientas, sino que hay que tener en cuenta el elemento humano.

¿Está preparado el elemento humano?

El 97% de los desarrolladores encuestados cree que ha recibido suficiente formación en codificación segura, y el 95% está de acuerdo en que la formación en codificación segura ha sido valiosa para su carrera. Pero antes de aceptar estas afirmaciones al pie de la letra, debemos preguntarnos: ¿Por qué las vulnerabilidades del código siguen siendo tan frecuentes? ¿Las afirmaciones de los desarrolladores sobre su experiencia en código seguro son solo un caso de ego humano? La evidencia ciertamente apunta en esta dirección. En una admisión más modesta, más del 88% de los desarrolladores encuestados admiten que la programación segura es difícil de aprender, y el 91% de los directores de desarrollo reconoce que es difícil implementar prácticas de codificación segura. Cuando se les pide que identifiquen sus principales preocupaciones personales en torno a la implementación de código seguro, el 28% de los desarrolladores considera que el proceso de aprendizaje es difícil, mientras que el 24% lo considera aburrido. Esto apunta al hecho de que la formación de los desarrolladores debe mejorar.

¿Qué necesita el elemento humano?

Para superar el factor «desafiante», una formación segura que valga la pena requiere un proceso de «andamiaje» que ayude al desarrollador a desarrollar habilidades de codificación segura paso a paso. Para lograr la máxima relevancia y aplicabilidad inmediata, esa formación debe llevarse a cabo en el idioma o marco específico que utilizan todos los días.

Para superar el factor «aburrimiento», la formación sobre código seguro debe impartirse de forma práctica; se ha demostrado que es mucho más atractiva para los desarrolladores que los modelos anticuados de aula o «mira este vídeo». Estos deben incluir simulaciones en vivo que permitan a los desarrolladores abordar desafíos de seguridad, a veces riesgosos, en un entorno seguro. El objetivo debería ser enseñar a los desarrolladores cómo encontrar y corregir las vulnerabilidades en el código mientras trabajan y hacer que la codificación segura forme parte de su flujo diario. Otro factor facilitador clave es el aprendizaje y la formación desde dentro del IDE, que ayudan a los desarrolladores a aprender y mejorar constantemente sus habilidades a medida que codifican, previniendo y eliminando las vulnerabilidades a medida que avanzan.

Si quieres saber cómo ofrecer a tus desarrolladores este nuevo nivel de herramientas y formación centradas en los desarrolladores, reserve una demostración ahora.

También puedes descarga tu copia del documento técnico Pasar de la reacción a la prevención: la cara cambiante de la seguridad de las aplicaciones.

‍

Los ciberataques, sin duda, van en aumento. Según el informe de investigación de violaciones de datos de 2021 de Verizon, el panorama de amenazas es más peligroso hoy más que nunca. Las organizaciones de todos los tamaños están sufriendo un mayor volumen de ataques y un mayor nivel de sofisticación por parte de los actores de amenazas que las atacan. Además, las tasas de éxito de los atacantes también se están disparando.

El análisis de los ataques más recientes ayuda a revelar algunas de las vulnerabilidades y técnicas más comunes que utilizan los piratas informáticos durante este ataque sin precedentes contra las ciberdefensas. Algunos de los ataques más populares, como los perpetrados por el Open Web Application Security Project (OWASP) Los 10 principales riesgos y vulnerabilidades de seguridad para 2021, implicaba el robo o la puesta en peligro de cualquier otro modo las credenciales. Y según una investigación de seguridad realizados por Akamai, la inmensa mayoría, casi el 75%, se dirigió directamente a las credenciales de las API.

El auge y la posible ruina de las APIs

No es de extrañar que las interfaces de programación de aplicaciones, en su mayoría denominadas simplemente API, estén aumentando en las redes de casi todas las organizaciones. Son un componente fundamental de la mayoría de los servicios basados en la nube, que están asumiendo rápidamente las funciones de los activos locales en la mayoría de las empresas, organizaciones y agencias gubernamentales. Hoy en día, casi no se puede administrar ningún tipo de negocio o tarea sin la nube, especialmente las que están orientadas al público. Y eso significa que las API van a ser, sin duda, el elemento que unirá a un buen número de servicios en todas las redes.

Lo sorprendente de las API es que, en su mayoría, son pequeñas y discretas en términos de asignación de recursos de red. Además, son completamente flexibles, por lo que se les puede asignar la tarea de realizar casi cualquier trabajo. En esencia, las API son piezas individuales de software diseñadas para controlar o administrar un programa en particular. Se pueden utilizar para realizar funciones muy específicas, como acceder a los datos desde un sistema operativo, una aplicación o un servicio host.

Desafortunadamente, es esta misma flexibilidad, y el hecho de que a menudo son pequeñas y los equipos de seguridad las pasan por alto, lo que convierte a las API en objetivos atractivos. La mayoría de las API están diseñadas por desarrolladores para ofrecer una flexibilidad total, de modo que puedan, por ejemplo, seguir funcionando incluso si se modifica o cambia el programa principal que administran. Y hay pocos estándares. Casi como los copos de nieve, muchas API son únicas porque se crean para cumplir una función en particular con un solo programa en una red específica. Si están codificadas por desarrolladores que no son muy conscientes de la seguridad o que no se centran específicamente en la seguridad, pueden y probablemente tendrán cualquier cantidad de vulnerabilidades que los atacantes pueden encontrar y explotar.

Lamentablemente, el problema se nos va de las manos rápidamente. Según Gartner, para 2022, vulnerabilidades relacionadas con las API se convertirá en el vector de ataque más frecuente en todas las categorías de ciberseguridad.

La razón principal por la que los atacantes quieren comprometer las API no es para poder hacerse cargo de cualquier función específica que desempeñe la API, sino para robar las credenciales asociadas a ella. Uno de los mayores problemas de las API, además de estar plagadas de vulnerabilidades, es que a menudo muy sobreautorizado en lo que respecta a su funcionalidad principal. En aras de la simplicidad, la mayoría de las API tienen un acceso casi a nivel de administrador en una red. Si un atacante se hace con el control de una, con frecuencia puede usar sus permisos para lanzar incursiones más profundas y sustanciales en una red. Además, dado que la API tiene permiso para realizar cualquier tarea hacia la que lo redirija el atacante, sus acciones a menudo pueden eludir la supervisión tradicional de la ciberseguridad, ya que la API no infringe ninguna regla gracias a su pase VIP entre bastidores que permite acceder a todas las áreas.

Si las organizaciones no tienen cuidado, el aumento de las API dentro de su red y sus nubes también puede significar un gran problema si son el objetivo de los atacantes.

Defensa de las API

A pesar de lo peligrosa que se está volviendo la situación con las API, está lejos de ser inútil. Hay un gran esfuerzo a través de los movimientos como DevSecOps para ayudar a que los desarrolladores sean más conscientes de la seguridad e incorporar la seguridad y las mejores prácticas en todos los aspectos de la creación de software, desde el desarrollo hasta las pruebas y la implementación. Incluir la seguridad de las API como parte de esa formación será fundamental para cualquier organización que quiera superar la tendencia de explotación de las API hasta 2022 y más allá.

Dicho esto, hay algunas buenas prácticas recomendadas que se pueden implementar ahora mismo en términos de seguridad de API.

Lo primero es incluir controles de identidad estrictos para todas las API. Casi deberías considerarlos como usuarios humanos a la hora de asignar permisos. Dado que una API solo está diseñada para realizar una función específica, hay que pensar en lo que podría suceder si un atacante pudiera comprometerla. Considera la posibilidad de usar un control de acceso basado en roles. Lo ideal sería que, en última instancia, aplicaras los principios de confianza cero a tus API y usuarios, pero eso suele ser un largo camino. Una buena gestión de identidades es un buen punto de partida. Solo asegúrese de incluir las API como parte de ese programa.

También debes controlar estrictamente las diversas llamadas que realizan tus API en la medida de lo posible. Si limitas esas llamadas a solicitudes muy centradas en el contexto, será mucho más difícil para un atacante modificarlas con fines nefastos. Incluso puedes estratificar tus API, de modo que una API inicial haga una llamada altamente contextual a otra API que sepa exactamente qué buscar y qué ignorar. Esta puede ser una forma eficaz de limitar la funcionalidad disponible para un agente de amenazas, incluso si es capaz de aprovechar y comprometer una API dentro de esa cadena.

No cabe duda de que las amenazas dirigidas contra las API pueden parecer abrumadoras. Sin embargo, si se implementan las mejores prácticas y se ayuda y recompensa a los desarrolladores que se convierten en campeones de la seguridad, la situación puede parecer mucho menos desesperada. Con una buena formación y práctica, puedes crear un programa de seguridad sólido que dé a los atacantes poco margen de maniobra, incluso si de alguna manera ponen en peligro una de tus pequeñas pero esenciales herramientas de API.

Como profesional de seguridad de aplicaciones, es su trabajo garantizar la seguridad cibernética de las aplicaciones de su organización. Sin embargo, no eres responsable de escribir el código en el que se ejecuta la aplicación. Los ingenieros del equipo de desarrollo sí lo son. Entonces, ¿cómo se asegura de que están desarrollando esos sistemas teniendo en cuenta la seguridad?

Lo más probable es que estés realizando algunas o incluso todas las siguientes acciones:

• Revisar todo el código en busca de fallas de seguridad e informar al equipo de desarrollo para que las corrija.
• Imponer un estricto proceso de revisión por pares a lo largo de su ciclo de vida de desarrollo seguro.
• Que equipos de seguridad internos o externos realicen evaluaciones periódicas de las aplicaciones o pruebas de penetración.
• Implementación de herramientas de escaneo para detectar vulnerabilidades.
  

Estas son excelentes prácticas recomendadas, pero también son costosas y similares a tomar una ronda de antibióticos cada vez que te enfermas. Esto no solo tiene un costo elevado, sino que pierde eficacia y, con el tiempo, puede debilitar el sistema inmunitario.

¿Cómo se garantiza realmente que el código que envían los desarrolladores esté escrito de forma segura desde el principio?

Dejando a un lado la codificación segura, primero piense en cómo aprenden las personas. La mayoría de nosotros aprendemos de forma visual y aprendemos haciendo. Sin embargo, la formación sobre código seguro se imparte a menudo como una actividad que se puede cumplir y no es relevante para el trabajo diario de un desarrollador. Está diseñada para demostrar que los desarrolladores han recibido formación en seguridad con frecuencia para cumplir con los estándares del sector, y no para que los desarrolladores conserven realmente esos conocimientos, y mucho menos para que disfruten del proceso de aprendizaje.

Otra forma en que los humanos tienden a aprender es a través de nuestros errores de la misma manera que lo hace nuestro sistema inmunológico. Las células T recuerdan qué tipo de patógenos encontraron y erradicaron con éxito en el pasado, para poder protegerse contra ellos en el futuro. Este es exactamente el papel que los desarrolladores deberían desempeñar en tu seguro SDLC.

No es realista esperar que no cometan errores, pero puedes prepararlos de manera que puedan reconocer los patrones de codificación que se traducirán en vulnerabilidades de seguridad en el futuro.

También es así como un sólido proceso de revisión por pares se vuelve tan poderoso. El hecho de que un desarrollador no se dé cuenta de un fallo de seguridad no significa que otro no lo haga. Y cuanto mejor formado esté el equipo de desarrollo en su conjunto, más probabilidades hay de que las vulnerabilidades queden atrapadas y nunca lleguen a la fase de producción.

Las vulnerabilidades del software son como los patógenos

Las vulnerabilidades del software son como los patógenos en el sentido de que hay que recordarlas para poder combatirlas. En el caso de los patógenos, nuestro sistema inmunitario a menudo necesita estar expuesto varias veces antes de recordar cómo combatirlos, a fin de evitar enfermedades graves o peores.

Un ciberataque exitoso de software vulnerable puede paralizar gravemente o matar a una organización. Sin embargo, si los desarrolladores descubren las vulnerabilidades del software por primera vez en un entorno controlado, pueden trabajar para aumentar su inmunidad frente a las amenazas aumentando y practicando regularmente sus conocimientos y habilidades de codificación segura.

Exponga a los desarrolladores a fallas de seguridad en un entorno controlado

Nunca podemos protegernos por completo de enfermarnos, pero hay cosas que podemos hacer para reforzar nuestro sistema inmunitario y mantenernos lo más sanos posible. Algunas de las opciones de estilo de vida que suelen asociarse con un sistema inmunitario fuerte son algunas de las opciones de estilo de vida que suelen asociarse con un sistema inmunitario fuerte. Pero todas esas cosas requieren un poco de esfuerzo y deben ser continuas. Salir a correr todos los días durante una semana o dejar de beber durante un mes apenas afectará su salud en general. Tampoco es recomendable salir a correr 10 km el primer día que comencemos a correr. Primero necesitamos exponer nuestros corazones y músculos al ejercicio. También sabemos que se necesita un poco de experimentación hasta que encontremos un buen equilibrio para nuestro cuerpo y los alimentos y ejercicios saludables que nos encantan.

No es tan diferente cuando se trata de un desarrollo de software seguro. El aprendizaje se produce con el tiempo y con la práctica, y los desarrolladores necesitan la misma formación continua para mejorar regularmente sus habilidades de codificación segura. Sin mencionar que el desarrollo de software siempre está evolucionando y adaptándose, lo que significa que las vulnerabilidades también lo están. Por eso, un simple curso de formación no es suficiente. Los desarrolladores necesitan mejorar sus habilidades con regularidad para estar lo suficientemente familiarizados con las amenazas potenciales y estar equipados adecuadamente para defenderse de ellas.

Intenta lograr la inmunidad colectiva dentro del equipo de desarrollo

Una sola persona no puede evitar todos y cada uno de los problemas de seguridad. Es fantástico contar con expertos en seguridad en el equipo, pero para obtener la mejor protección, cuantas más personas hayan aprendido sobre las vulnerabilidades de seguridad y cómo prevenirlas, más posibilidades tendrá la organización de prevenirlas. Una vez más, no es muy diferente a la forma en que el sistema inmunitario tiene diferentes tipos de células T para diferentes propósitos. Cada desarrollador forma parte de un equipo que garantiza la seguridad. Si están capacitados para asumir responsabilidades, hacerlo bien e incluso disfrutar haciéndolo, entonces puedes crear una inmunidad colectiva contra las ciberamenazas dentro del equipo de desarrollo.

Mantenga la seguridad como prioridad con la exposición repetida

Nuestros cerebros aprenden de manera similar al funcionamiento de nuestro sistema inmunitario. Psicólogo alemán Hermann Ebbinghaus fue pionero en el campo de la memoria y el aprendizaje. Dedujo que el aprendizaje tiene que ocurrir con el tiempo y con múltiples sesiones de aprendizaje. Cuando estamos en la escuela, nunca se espera que mantengamos nuevos conocimientos después de la primera introducción. Primero se nos presenta la información, luego la practicamos con orientación y luego la practicamos por nuestra cuenta. E incluso después de haberla aprendido lo suficientemente bien como para aprobar un examen, la información tiende a olvidarse poco después si no utilizamos con regularidad los conocimientos que hemos dedicado tiempo y esfuerzo a aprender. ¿Cuántos de nosotros podemos decir que recordamos el francés de la escuela secundaria?

Entonces, ¿cómo podemos creer que un solo día viendo diapositivas y escuchando a alguien hablar sobre seguridad lleve realmente a los desarrolladores presentes a programar de forma más segura?

Los patrones de vulnerabilidades recurrentes nos muestran que esto simplemente no funciona.

¿Cómo se logra una inmunidad de desarrollo segura?

La respuesta está en nuestra naturaleza. Nuestros cuerpos y mentes funcionan de la misma manera y brindan hermosas soluciones a los problemas, siempre y cuando trabajemos con ellos y no contra ellos.

Para garantizar la seguridad de sus aplicaciones, debe empezar por mejorar las habilidades de los desarrolladores para escribir código seguro. De lo contrario, AppSec seguirá dedicando todo su tiempo a revisar todo el código en busca de fallos de seguridad y a denunciar las mismas vulnerabilidades recurrentes para el desarrollo, solo para corregirlas rápidamente sin aprender nada. Y, a continuación, vuelva a hacerlo para la próxima versión.

Así que vamos a reiterar.

Si colaboras con tus gerentes de desarrollo para lograrlo, no solo implementarás un SDLC seguro y cumplirás con los requisitos de capacitación en seguridad para cumplir con los requisitos, sino que también lograrás un impacto real en el proceso de desarrollo. Como guinda del pastel, AppSec ya no detectará vulnerabilidades repetidas ni las denunciará a los equipos de desarrollo, y los desarrolladores dedicarán menos tiempo a solucionarlas. Esto significa que pueden dedicar más tiempo a crear y mejorar el increíble software que hace que nuestro mundo sea mejor.

¿Estás listo para mejorar las habilidades de tu equipo de desarrollo? Adelante y reserve una demostración con nosotros.

Although it may seem counterintuitive to anyone working outside of software development, many of the professionals employed in application security over the years have worked in those critical roles with little or no programming experience. These AppSec professionals are part of the team that is responsible for making sure that no vulnerabilities creep into the applications that have become the lifeblood of many industries and organizations, and yet few of them can actually directly evaluate or fix the code themselves. 

Instead of coming from a coding background, many security professionals approach their roles from the perspective of key knowledge around attack vectors, threats, exploits, and business risk; they have a limited view of code. While not every AppSec guru has the same skillset, a typical day for many involves working with code reviewers and scanning tools to ensure that programs and systems are secured according to organizational standards, or relevant industry and government frameworks. They then write up reports about their findings, and send back information on the attack vector that may break the code. It is then up to developers to make necessary fixes, no matter how disruptive it may be to current work.

The reason the situation developed this way is because the prevailing logic over the years was that the job of protecting networks and applications was so vast, that it didn’t make sense to expect everyone working in cybersecurity to perform every role. Deep coding skills were left to the developers, and little value was placed on the ability to write or edit code farther down the development pipeline.

That mindset is changing fast, and that presents a unique opportunity for developers to make the lucrative jump and career shift into AppSec. Not every developer will want to embrace the so-called dark side, and many developers aren’t particularly positive in their opinions regarding AppSec teams. But for those who do, there has never been a better time to grab that increasingly tempting brass ring.

DevSecOps drives nearly every industry

One of the biggest factors in elevating the value of security-aware programmers and developers in any organization, is the almost universal move to embrace more agile development practices like DevSecOps. When development, security, and operations are combined, cybersecurity becomes a shared responsibility integrated into the development of new software from end to end. In that environment, the ability to code is increasingly being seen as a valuable asset across the board, and this is especially true for engineers who also inherently understand security. 

An AppSec professional who not only understands cybersecurity at a high level, but also the code that makes everything work, is inherently more valuable to any organization than someone whose knowledge is concentrated on the theoretical. Being able to quickly discover and evaluate vulnerabilities found within code, and then mitigate those problems, is at the core of why DevSecOps is seeing such popularity.

Developers working in AppSec also bring another big advantage to any organization that employs them. Coming from the development side of the house makes it easy for them to talk with developers about security and vulnerabilities. It also makes it much easier to become coaches for the development teams, helping them to become better coders. Over time, they might even be able to remove the “dark side” stigma from AppSec and help to unify teams within software development across an organization.

The cybersecurity skills shortage is getting worse

Shakespeare mused that it’s an ill wind that blows nobody any good. What he meant was that even the darkest situation probably benefits someone. The cybersecurity skills shortage is a great example of this.

The shortage of personnel is being felt acutely almost everywhere. In a recent survey conducted by the Center for Strategic and International Studies, 82% of IT decision-makers said their organizations suffered from a shortage of cybersecurity skills, and 71% said that the shortage had resulted in direct and measurable damage to their organizations. To put this crisis in an even better perspective, the report pointed out that just in the United States alone, there were more than 520,000 unfilled cybersecurity jobs in 2020 for a field where only about 940,000 are employed.

The cybersecurity personnel shortage is bad news for organizations trying to protect their infrastructure, business and data from an increasingly dangerous threat landscape. But it makes a good opportunity for developers looking to get into AppSec and security. Chances are, that cybersecurity and AppSec positions are available almost everywhere. And with cybersecurity positions taking an average of 21% more time to fill these days, salaries are rising across the board.

Making the jump to AppSec

There may never be a better time for developers to make the lucrative jump to the sunny security side of life. Security-aware developers are no longer seen as just part of a stopgap security method, but are instead filling out a full and respected role as cybersecurity defenders. This is especially true for organizations that have embraced DevSecOps and other more agile development methodologies. And the cybersecurity talent shortage means that positions are available at nearly every company, government agency or organization. Those with the right skills can pick and choose where they want to work.

Moving to AppSec may not be for everyone, and of course, most developers will remain focused on building amazing features. But for those who are considering making the jump, investing in security training to augment their existing coding skills can open up a lot of doors. The best AppSec people come out of engineering, because they deeply understand the tech and have empathy for the plight of their fellow developers. DevSecOps means that everyone is now responsible for security anyway, so why not take advantage of the current critical skills shortage to advance your career into application security? There has never been a better time to make a positive move for yourself, your family, and your career.

Un ataque de canal lateral se produce cuando un pirata informático puede recopilar información de la implementación física de un sistema de software en lugar de una debilidad teórica en el algoritmo o un error en el código del software.

Un ejemplo que me gusta usar para dejar esto más claro es una forma de enumerar nombres de usuario. Si quieres saber qué es la enumeración de nombres de usuario o por qué es mala, visita nuestro sitio web para ver explicación en vídeo o juega un desafío para ver si puedes identificarlo en código.

Ahora, para entender cómo se puede realizar la enumeración de nombres de usuario mediante un ataque de canal lateral, es necesario tener un cierto conocimiento de cómo se gestionan (o al menos se deben gestionar) las contraseñas en las aplicaciones web modernas. Una buena aplicación web no conoce tu contraseña, no la guarda ni la almacena en ningún sitio. Entonces, ¿cómo sabe que lo que escribiste es correcto y, de hecho, tu contraseña? Bueno, tu contraseña está cifrada.

Una función de hash es una operación matemática que es fácil de realizar de una manera (aunque es algo costosa desde el punto de vista computacional) pero muy difícil de revertir y, en el caso de buenos algoritmos de hash, la salida es única según la entrada. Cuando te registras en un sitio web, ese hash se almacena de forma segura, no tu contraseña en sí. Esto significa que cada vez que inicias sesión, la aplicación web aplica un hash a los datos introducidos y compara los resultados del hash con el hash almacenado. Si quieres obtener más información sobre almacenamiento seguro de contraseñas, puedes hacerlo en nuestra plataforma.

El hash de la entrada lleva algo de tiempo en una computadora y los desarrolladores siempre intentan optimizar todo lo que escriben para que los usuarios tengan una experiencia fluida. Una cosa que acelera el programa es omitir el hashing cuando no es necesario. Por ejemplo, cuando el nombre de usuario no existe (por lo que no es necesario comprobar ninguna contraseña), pueden responder al usuario de inmediato. De esta forma, pueden evitar el lento cálculo que supone el uso del hash de la contraseña. Si el nombre de usuario era correcto, codificarán la contraseña ingresada y la compararán con el hash almacenado.

En este punto, es posible que haya adivinado dónde pueden ir mal las cosas. Aunque en realidad el hashing solo tarda unos pocos milisegundos, un hacker puede aprovechar este retraso adicional para averiguar si el nombre de usuario que ha introducido es correcto o no, ya que un nombre de usuario incorrecto responderá un poco más rápido porque no se ha realizado ningún hashing. Este tipo de ataque de canal lateral se denomina ataque cronometrado y es un buen ejemplo de cómo diferentes requisitos no funcionales pueden contrarrestarse entre sí. A veces, el código no puede ser rápido y seguro al mismo tiempo.

Por lo tanto, aunque las contraseñas se manejan perfectamente y el mensaje que se muestra es genérico y no informa si la contraseña o el nombre de usuario eran incorrectos, el sistema sigue siendo vulnerable. La solución es sencilla: usar siempre un hash para la contraseña o retrasar el envío de la respuesta el tiempo necesario para hacerlo.

Un atacante puede utilizar la información obtenida para obtener una lista de usuarios del sistema. Esta información se puede usar para atacar la aplicación web, por ejemplo, mediante un ataque de fuerza bruta o con un nombre de usuario o contraseña predeterminados.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

El lenguaje de marcado extensible (XML) es un lenguaje de marcado que se utiliza para codificar documentos en un formato fácil de manejar para las máquinas y legible por humanos. Sin embargo, este formato de uso común incluye varios fallos de seguridad. En esta primera entrada de blog relacionada con XML, explicaré los aspectos básicos del manejo seguro de documentos XML mediante el uso de un esquema.

OWASP divide las diferentes vulnerabilidades relacionadas con los esquemas XML y XML en dos categorías.

Documentos XML con formato incorrecto

Los documentos XML mal formados son documentos que no siguen las especificaciones XML del W3C. Algunos ejemplos que dan como resultado un documento con formato incorrecto son la eliminación de una etiqueta final, el cambio del orden de los diferentes elementos o el uso de caracteres prohibidos. Todos estos errores deberían provocar un error fatal y el documento no debería someterse a ningún procesamiento adicional.

Para evitar las vulnerabilidades causadas por documentos con formato incorrecto, debe utilizar un analizador XML bien probado que siga las especificaciones del W3C y que no tarde mucho más en procesar los documentos con formato incorrecto.

Documentos XML no válidos

Los documentos XML no válidos están bien formados pero contienen valores inesperados. En este caso, un atacante puede aprovechar las aplicaciones que no definen correctamente un esquema XML para identificar si los documentos son válidos. A continuación encontrará un ejemplo sencillo de un documento que, si no se valida correctamente, podría tener consecuencias imprevistas.

Una tienda web que almacena sus transacciones en datos XML:

<purchase></purchase>
<id>123</id>
<price>200</price>

Y el usuario solo tiene control sobre el <id>valor. Entonces es posible, sin las contramedidas adecuadas, que un atacante introduzca algo como esto:</id>

<purchase></purchase>
<id>123</id>
<price>0</price>
<id></id>
<price>200</price>

Si el analizador que procesa este documento solo lee la primera instancia de las <id><price>etiquetas y, esto generará resultados no deseados</price></id>.

También es posible que el esquema no sea lo suficientemente restrictivo o que otra validación de entrada sea insuficiente, de modo que se puedan introducir números negativos, decimales especiales (como NaN o Infinity) o valores extremadamente grandes donde no se esperan, lo que lleva a un comportamiento no deseado similar.

Para evitar las vulnerabilidades relacionadas con los documentos XML no válidos, se debe definir un esquema XML preciso y restrictivo para evitar problemas de validación de datos incorrecta.

En la próxima entrada del blog abordaremos algunos ataques más avanzados a documentos XML, como Jumbo Payloads y el temido número cuatro de OWASP Top Ten, XXE.

Mientras tanto, puede perfeccionar o poner a prueba sus habilidades en la validación de entradas XML. en nuestro portal.

Las especificaciones para XML y los esquemas XML incluyen varios fallos de seguridad. Al mismo tiempo, estas especificaciones proporcionan las herramientas necesarias para proteger las aplicaciones XML. Aunque utilizamos esquemas XML para definir la seguridad de los documentos XML, pueden usarse para realizar diversos ataques: recuperación de archivos, falsificación de solicitudes del servidor, escaneo de puertos o uso de fuerza bruta.

https://www.owasp.org/index.php/XML_Security_Cheat_Sheet