Información sobre el código seguro

Cuando construyes una aplicación empresarial, ya sea para uso interno o externo por parte de tus clientes, probablemente no permites que cada usuario realice todas las funciones. Si lo hace, puede ser vulnerable a un control de acceso roto.

Veamos qué es un control de acceso defectuoso, por qué es tan peligroso y cómo solucionarlo.

Comprender el control de acceso roto

El control de acceso roto se produce cuando el código de la aplicación no tiene las comprobaciones de seguridad o de acceso adecuadas. También puede ocurrir cuando una aplicación está mal configurada de alguna manera, permitiendo el acceso a funciones o páginas a las que el usuario no debería tener acceso.

Si usted maneja las finanzas de su empresa, puede tener acceso a depositar dinero en determinadas cuentas o a transferir dinero entre las cuentas de su empresa. Sin embargo, no debería tener acceso para retirar dinero de esas cuentas o transferir dinero a otras cuentas. Si no existen los controles de acceso adecuados, es posible que sus empleados puedan realizar más funciones de las necesarias.

Estas comprobaciones pueden realizarse dentro del código o en archivos de configuración. Por ejemplo, puede haber archivos de configuración XML que indiquen al marco de la aplicación web qué usuarios pueden acceder a qué páginas. Esto garantiza que los usuarios sólo puedan acceder a las funciones que están autorizados a utilizar.

Por qué es peligroso un control de acceso roto

Considere este ejemplo: Un atacante se ha dado cuenta de que su código de creación de cuentas de usuario puede ser manipulado, permitiendo al atacante crear un usuario administrador con una simple petición de correo. Pueden enviar una solicitud con el nombre de usuario y la contraseña, y luego cambiarla en el camino para incluir el rol de administrador en la URL como un parámetro, o en el cuerpo de la solicitud. El atacante entra en la aplicación y recibe instantáneamente derechos de administrador.

No siempre tiene que ser un atacante malicioso el que penetre en un sistema. Sin los controles de acceso adecuados, puede filtrarse información sensible que no debería compartirse entre departamentos. Imagínese que cualquier empleado de la empresa pudiera ver los datos de las nóminas de Recursos Humanos o los datos financieros. ¿Qué pasaría si cualquier empleado pudiera ver que se avecinan despidos por la mala situación financiera de la empresa? Esto podría ser perjudicial para la moral y la reputación de la empresa.

También podría perderse información sensible de los clientes. Las empresas suelen almacenar información personal de los clientes que utilizan sus servicios. Tenga cuidado de no exponerla accidentalmente por falta de control de acceso. Por ejemplo, si su sistema ofrece a los usuarios la posibilidad de solicitar su historial médico, ¿tienen también la posibilidad de solicitar y ver la información médica de otros? Si la URL contiene un número de identificación de cliente, los atacantes podrían incrementar ese número de identificación de cliente una y otra vez hasta encontrar uno que coincida con otro cliente, revelando así sus datos personales.

Derrotar el control de acceso roto

El control de acceso basado en roles (RBAC) es una herramienta muy eficaz para implementar un buen control de acceso. Aquellos que utilizan Active Directory pueden estar familiarizados con la idea de crear grupos y dar acceso a ciertos elementos a través del grupo, en lugar de al individuo. Las aplicaciones funcionan de la misma manera, utilizando roles para definir quién puede ver qué.

Esto tiene dos ventajas. En primer lugar, no es necesario cambiar una función cuando alguien deja el rol de administrador. Si alguien era previamente un administrador y ahora ya no debe serlo, entonces simplemente se coloca una nueva persona en el rol de administrador y se elimina a la persona anterior del rol. El código comprueba si el usuario tiene el rol de administrador en lugar de comprobar si cada usuario individual tiene acceso a una determinada página o función.

La segunda ventaja es evitar una pesadilla de mantenimiento. Un control de acceso tan granular que cada persona tenga asociaciones con todas las funciones o páginas posibles será imposible de gestionar con el tiempo. Los roles facilitan mucho las cosas, porque se pueden añadir varias personas a un rol. Un rol puede incluir a toda la empresa, mientras que otro puede tener sólo cinco personas. Esto hace que la gestión de los roles sea más eficiente, ya que habrá menos roles que gestionar. Una empresa de 10.000 personas podría tener sólo 100 roles en lugar de 10.000 veces el número de funciones de su aplicación. Investigue el marco de trabajo de su aplicación elegida para ver qué opciones existen para un control de acceso sólido.

También es fundamental utilizar el control de acceso a nivel de función. Proteja el acceso a todas las funciones exigiendo a los usuarios que pasen ciertas comprobaciones de control de acceso. Utilice el principio del mínimo privilegio, denegando el acceso por defecto y abriendo el acceso sólo cuando sea necesario. Puede ser difícil recordar la aplicación del control de acceso para cada función. Utilice un componente central para gestionar y aplicar el control de acceso.

Proteja sus funciones sensibles

Un control de acceso defectuoso puede dejar sus datos y su aplicación muy abiertos a los ataques y a la explotación. Los datos de los clientes que no están protegidos adecuadamente podrían dar lugar a una filtración masiva de datos, perjudicando su reputación y sus ingresos.

Un control de acceso roto también podría conducir a la toma de posesión de cuentas si los atacantes son capaces de acceder a la funcionalidad a la que no deberían acceder. Utilice un control de acceso de nivel funcional adecuado y mantendrá su aplicación a salvo de atacantes malintencionados, e incluso de personas con acceso interno accidental.

¿Cree que ya ha superado el nivel de acceso funcional? Ahora puedes desafiarte a ti mismo para reparar el control de acceso roto: [Comience aquí]

"Loslabios sueltos hunden los barcos" fue una frase que se hizo popular en Estados Unidos durante la Segunda Guerra Mundial. En Gran Bretaña, se escuchaba "Hablar sin cuidado cuesta vidas". El punto principal del dicho era que hablar sin cuidado sobre información sensible podía ser escuchado por espías y conducir a graves consecuencias.

El mismo principio es válido cuando se construyen aplicaciones web. Cuando tu aplicación web revela demasiada información, puede facilitar que los atacantes entren en ella.

En este artículo, explicaremos qué es la exposición a la información, por qué es peligrosa y cómo prevenirla.

Comprender la exposición a la información

La exposición de información se refiere a las aplicaciones web que exponen información interna a quienes no deberían verla. También puede referirse a la exposición de información sensible de los clientes a través de los archivos de registro o de la interfaz de usuario. De cualquier manera, los atacantes pueden utilizar la información que encuentran para atacar sus sistemas o a sus usuarios.

A menudo, el primer paso para un atacante es intentar crear un error dentro de su aplicación. Una mala gestión de los errores y la configuración de la aplicación web conducen a la exposición de la información con mensajes de error. ¿Qué sucede si el atacante crea un error dentro de su aplicación? Si aparece un mensaje de error técnico, incluyendo detalles técnicos como un seguimiento de pila, has revelado demasiada información. Estos detalles pueden incluir qué base de datos estás utilizando o qué versión del servidor de aplicaciones estás ejecutando.

La divulgación de información sensible puede ocurrir de otras maneras. ¿Hay campos ocultos en un formulario que contengan información sensible? Los atacantes pueden simplemente ver la fuente de la página y ver los valores.

En pocas palabras, la exposición de la información se produce cuando la información que debería estar en una base de necesidad de conocimiento con sus usuarios se hace demasiado fácilmente accesible.

Entender por qué la exposición a la información es peligrosa

¿Qué puede hacer un atacante con la información expuesta por la aplicación? Si la información es de naturaleza sensible, un atacante podría robar identidades o credenciales de usuario. Esto podría dar lugar a daños financieros, violaciones de la privacidad y multas reglamentarias

Si un atacante utiliza los mensajes de error para obtener información sobre una aplicación, esa información podría ser utilizada en un futuro ataque. De hecho, la Guía de Pruebas de OWASP tiene una sección entera sobre la recopilación de información.

La Guía de Pruebas de OWASP fomenta el uso de los motores de búsqueda para encontrar información sobre su sitio web que puede no estar prevista. Por ejemplo, ¿sus páginas administrativas están expuestas a los motores de búsqueda? Utilice el archivo robots.txt para indicar a los motores de búsqueda que no indexen determinadas páginas. Al mismo tiempo, el archivo robots.txt también puede filtrar información. A veces, las URL sensibles pueden residir en el archivo robots.txt. Los atacantes tiran del archivo y empiezan a conocer parte de la estructura de directorios del sitio.

Google has advanced search engine options which allow deep inspection of websites. For example, you can search on a specific site using the "site: <domain>" syntax. You can view cached pages which may have been deleted but still reside in a cache from a previous indexing job. Using different search engines, such as Bing and DuckDuckGo may yield different results, so test on each search engine what is revealed about your web application.</domain>

Las cabeceras HTTP, los banners del sitio web e incluso los comentarios dentro del código HTML y JavaScript podrían contener información que los atacantes no deberían ver. Las cabeceras HTTP pueden revelar servidores de aplicaciones y números de versión. Los atacantes pueden utilizar esta información para encontrar exploits que utilizar contra esas versiones específicas. Asegúrese de que entiende todos los diferentes lugares en los que los atacantes podrían encontrar su información y cómo ocultarla adecuadamente.

Vencer la exposición a la información

La divulgación de información suele ser un problema de configuración de las aplicaciones web. Muchos servidores de aplicaciones devuelven por defecto las trazas de pila en los mensajes de error. Asegúrese de cambiar esta configuración para que las aplicaciones de producción redirijan a una página de error genérica mientras se registra el error para la resolución de problemas. Los mensajes de error detallados nunca deben ser devueltos al navegador del usuario.

Si tiene algún archivo necesario para la aplicación que contenga información sensible, asegúrese de que un control de acceso adecuado garantice que sólo la propia aplicación pueda leerlo. Desactive el listado de directorios en el servidor y mueva estos archivos fuera del directorio raíz de la web. Esto evita que los atacantes naveguen hasta el archivo utilizando el navegador mediante un ataque de cruce de directorios.

Los registros pueden utilizarse para recopilar información cuando no están configurados correctamente. Cuando se produzca un error, no registre información sensible como contraseñas, testigos de sesión o información personal identificable (PII). Si un atacante pudiera acceder a los archivos de registro, encontraría un tesoro de información sensible para robar. No registre más de lo necesario, que suele ser un identificador de cuenta, un mensaje de error detallado y, tal vez, el método en el que se produjo el error o la operación que se estaba realizando. Asume que los archivos de registro no son secretos y que no tendrás la tentación de colocar información sensible en ellos.

No hunda sus aplicaciones web

¿Podría realmente haber filtrado información mientras hablaba con un amigo, lo que llevó directamente a la pérdida de un acorazado en la Segunda Guerra Mundial? Tal vez no. Pero, ¿por qué correr el riesgo? Esa es la lección del dicho: "Los labios sueltos hunden los barcos".

Del mismo modo, no hay razón para exponer el funcionamiento interno de su aplicación web al mundo exterior. No hay razón para ver números de tarjetas de crédito o contraseñas enteras. No hay razón para tener datos PII en los archivos de registro. Así que no lo hagas. Consulte nuestros recursos de aprendizaje para obtener más información sobre la exposición de la información.

Mantenga el funcionamiento interno de sus aplicaciones donde corresponde. No hundas tus aplicaciones web.

¿Crees que puedes poner fin a la exposición de la información ahora mismo? Acepta el reto, guerrero: [Empieza aquí]

¿Qué es lo que tienen todas las aplicaciones? Los componentes, también conocidos como dependencias o bibliotecas. Hay muy poco código en el mundo que no dependa de otro código en algún momento. Incluso se empieza con una montaña de dependencias desde que se crea la aplicación!

Dado que todas las aplicaciones utilizan componentes, la mayoría de los cuales no has escrito, las vulnerabilidades dentro de los componentes que utilizas pueden convertirse en pasivos. Vamos a discutir lo que significa el uso de componentes con vulnerabilidades conocidas, lo peligroso que es, y cómo resolverlo.

Comprender el uso de componentes con vulnerabilidades conocidas

Todo software complejo tiene vulnerabilidades. Es la naturaleza de la bestia. Así que sus componentes nunca serán 100% seguros. Sin embargo, cuando se encuentran vulnerabilidades en los componentes, ¿lo sabes? ¿Está preparado para ello?

Los problemas surgen con mayor frecuencia cuando los componentes se utilizan más allá de su vida útil o después de que se encuentren vulnerabilidades. La mayoría de los componentes y bibliotecas publican parches para las vulnerabilidades de seguridad en el mismo momento en que se anuncia la vulnerabilidad o antes. Por lo tanto, cuando se descubren y anuncian vulnerabilidades en los componentes, es de suma importancia actualizarlos lo antes posible. No deje el software vulnerable en producción.

Los componentes pueden provenir de varias fuentes. A veces se compran productos de terceros que se integran directamente con el código personalizado. Estos componentes pasan a formar parte de tu código y funcionan con el mismo nivel de privilegio. Otra fuente son los proyectos de código abierto alojados en sitios como GitHub. El código abierto puede ser peligroso, ya que no todas las bibliotecas de código abierto han sido cuidadosamente examinadas o auditadas en busca de vulnerabilidades.

Los atacantes utilizan la información sobre la vulnerabilidad de los componentes en su beneficio. Como las vulnerabilidades se anuncian públicamente, los atacantes las conocen al mismo tiempo que usted. Los atacantes también tienen técnicas que pueden utilizar para averiguar qué componentes estás utilizando. Una vez que conozcan esta información, sabrán cómo atacar tu aplicación si no está parcheada.

Sepa por qué los componentes vulnerables son peligrosos

Si buscas pruebas de lo peligroso que es utilizar componentes con vulnerabilidades conocidas, no busques más que la brecha de Equifax de 2017.

En julio de 2017, Equifax, una oficina de crédito de Estados Unidos, descubrió una filtración masiva de datos que filtró la información de identificación personal de más de 147 millones de personas. El alcance y el impacto de esta violación de datos no tiene precedentes. Recientemente, han salido a la luz noticias sobre las prácticas de seguridad poco rigurosas de Equifax.

Una de esas prácticas laxas era la gestión de parches. Equifax no tenía buenas prácticas de gestión de parches, lo que significaba que sus componentes pasaban bastante tiempo sin ser parcheados. Esta fue la causa directa de la brecha.

El sitio web de Equifax utilizaba el marco web Apache Struts. Varios meses antes de que los atacantes hackearan la red, se encontró una vulnerabilidad en el marco Struts, Apache Struts CVE-2017-5638. Sin embargo, Equifax no parcheó la vulnerabilidad. Los atacantes utilizaron esta vulnerabilidad para acceder a la red de Equifax. A partir de ahí, obtuvieron acceso a un tesoro de información personal.

Muchos sitios web se basan en marcos web no escritos por la empresa. Esto es una práctica habitual, ya que construir toda la funcionalidad necesaria desde cero sería una tarea demasiado grande. Sin embargo, depender fuertemente de un marco de trabajo puede abrirle a las vulnerabilidades. No te conviertas en el próximo Equifax.

Cómo protegerse de los componentes vulnerables

No existe una fórmula mágica para protegerse del uso de componentes vulnerables. Sin embargo, hay políticas y controles que puede utilizar para mitigar el riesgo de que se utilicen componentes vulnerables para comprometer sus sistemas.

Necesitas saber qué componentes y qué versión de cada componente estás utilizando para construir tus aplicaciones. Las herramientas de gestión de dependencias, como Dependency Check de OWASP, le ayudan a saber qué dependencias está utilizando. Dependency Check también le dirá si alguno de esos componentes tiene una vulnerabilidad públicamente divulgada.

También es esencial una metodología de gestión de parches. Cuando se descubren vulnerabilidades, hay que tener un sistema para que los parches se descarguen, se prueben y se pongan en producción sin problemas. Mantener el software parcheado evita que los atacantes utilicen vulnerabilidades de hace meses.

Por último, hay que contar con políticas que regulen el uso de componentes de código abierto y de terceros. A los desarrolladores no les gusta la burocracia, y es comprensible. Sin embargo, tiene que haber un proceso de investigación para el código no escrito por su organización. No tiene que ser pesado, pero es imprescindible para evitar que se utilicen componentes desconocidos. Como mínimo, hay que mantener actualizado un inventario de los componentes utilizados.

No se deje picar por el bicho de los terceros

Los componentes tendrán vulnerabilidades. Sus aplicaciones empresariales utilizarán componentes, ya sea de un proveedor o de una biblioteca de código abierto. Esto no significa que su organización tenga que ser vulnerable a los ataques.

Aunque los atacantes saben qué vulnerabilidades existen al mismo tiempo que usted, los parches suelen estar disponibles al mismo tiempo que los anuncios públicos. Por lo tanto, asegúrese de informarse sobre lo que utiliza su aplicación. Conozca lo que es vulnerable. Mantenga sus componentes parcheados.

¿Listo para descubrir (y derrotar) a algunos componentes vulnerables? Dirígete a la arena para participar en la batalla: [Comienza aquí]

Publicado originalmente en el Blog de la DevSecCon.

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

Es difícil; al fin y al cabo, la principal prioridad de un desarrollador es ofrecer funciones de software. Deben ser bonitas, funcionales y ayudar a mostrar la potencia de la aplicación. Con las prácticas de desarrollo ágil que suelen aplicarse hoy en día, estas funciones deben completarse con plazos estrictos... y la seguridad no suele ser una de las principales preocupaciones con tantas otras cosas en juego.

La seguridad se ve como el dominio del equipo de AppSec, que tiene la poco envidiable tarea de escanear el código (o 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 en el barro que destrozan su buen trabajo, frenan la innovación y, en general, crean un dolor de cabeza para los desarrolladores. A fin de cuentas, muchos problemas de seguridad tienen una solución bastante sencilla: quizás una sola línea de código podría reforzar una puerta trasera vulnerable en cuestión de minutos.

Pero, aquí está el problema. Dado que la "seguridad" es sinónimo de experiencia negativa, los desarrolladores simplemente no se comprometen con ella tan estrechamente como deberían. Esas correcciones de una sola línea no están ocurriendo: después de todo, los chicos de AppSec se encuentran continuamente con los mismos problemas. Debe ser bastante molesto para ellos seguir señalando los fallos de inyección SQL, más de veinte años después de que los descubriéramos por primera vez (y su posterior solución).

Lo que hemos hecho hasta ahora no está funcionando 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 conseguir una cultura de seguridad positiva en la que los desarrolladores reciban las herramientas y la formación necesarias para tener un impacto real en este espacio.

¿Quién sabe? Puede que 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

y no, no se trata de un juego de palabras sobre 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, se pueden eliminar las vulnerabilidades más comunes antes de que lleguen a un análisis o a una revisión manual del código en AppSec land.

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

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

Cuando todo el mundo está de acuerdo con las mejores prácticas de seguridad, una cultura de seguridad positiva es un subproducto feliz y vital.

Las iniciativas positivas y escalables centradas en los desarrolladores fomentan la cultura de seguridad adecuada. Para ganarse a los desarrolladores, es esencial involucrarlos en la resolución de problemas y en la creatividad, así como garantizar que los nuevos reclutas se pongan al día rápidamente con las expectativas de seguridad del equipo. Póngase en contacto con nosotros para obtener una visión general de cómo ha evolucionado la relación con los desarrolladores en materia de seguridad e ideas para poner en marcha un programa de concienciación en materia de seguridad con éxito en sus propias organizaciones.

En este blog cubriremos uno de los problemas más comunes a los que se enfrentan las organizaciones que gestionan sitios web, o que permiten a los empleados acceder de forma remota a los recursos informáticos - que es prácticamente todo el mundo. Y sí, probablemente has adivinado que vamos a hablar de la autenticación.

Si un pirata informático puede simplemente entrar en un sistema como administrador con un nombre de usuario y una contraseña válidos, entonces no hay necesidad de desplegar técnicas avanzadas para luchar contra las defensas de la red. El sistema simplemente abre la puerta y deja entrar al atacante. Peor aún, si el atacante no hace nada demasiado extravagante, su presencia es casi imposible de detectar ya que la mayoría de las defensas simplemente lo verán como un usuario o administrador válido haciendo su trabajo.

La categoría de vulnerabilidades de autenticación es bastante amplia, pero vamos a repasar los problemas más comunes que tienden a introducirse accidentalmente en los procesos de inicio de sesión de los usuarios. Si se refuerzan estos agujeros, se puede eliminar la gran mayoría de los problemas de autenticación de su organización.

En este episodio, aprenderemos:

• Cómo se explotan algunas vulnerabilidades de autenticación comunes
• Por qué son tan peligrosos
• Qué políticas y técnicas se pueden utilizar para eliminar las vulnerabilidades de autenticación.

¿Cómo aprovechan los atacantes las vulnerabilidades de autenticación?

Hay bastantes vulnerabilidades de autenticación que pueden colarse en un sistema de autenticación, por lo que los hackers explotan cada una de ellas de forma un poco diferente. En primer lugar, vamos a repasar las vulnerabilidades más comunes y, a continuación, daremos ejemplos que demuestran cómo se pueden explotar un par de ellas.

Las vulnerabilidades de autenticación más comunes incluyen:

• Tener políticas de contraseñas débiles o inadecuadas,
• Permitir un número ilimitado de intentos de inicio de sesión,
• Proporcionar información a un atacante sobre los inicios de sesión fallidos,
• Envío de credenciales a través de canales inseguros,
• Contraseñas con hash débil,
• Y tener un proceso de recuperación de contraseñas inseguro.

Tener una política de contraseñas débil es probablemente la vulnerabilidad más común. Si se permite a los usuarios crear contraseñas sin restricciones, demasiados de ellos utilizarán contraseñas fáciles de adivinar. Todos los años, varias organizaciones de noticias informáticas publican una lista de las contraseñas más utilizadas, y "123456" y "password" están siempre entre las cinco primeras. Hay otras. A los administradores les gusta mucho usar "Dios". Es cierto que todas ellas son graciosas o fáciles de recordar, pero también muy fáciles de adivinar. Los piratas informáticos saben cuáles son las contraseñas más comunes y las prueban primero cuando intentan entrar en un sistema. Si se permite ese tipo de contraseñas en su organización, acabará siendo violada.

Una vulnerabilidad menos obvia, pero igualmente peligrosa, es la de devolver información a un usuario sobre un inicio de sesión fallido. Esto es malo porque si devuelve un mensaje cuando un nombre de usuario no existe y otro cuando un nombre de usuario existe pero la contraseña es mala, permite a los atacantes mapear usuarios válidos en un sistema y concentrarse en adivinar contraseñas sólo para esos nombres de usuario. Si esto se combina con la vulnerabilidad de autenticación que permite adivinar contraseñas de forma ilimitada, permitiría a los atacantes ejecutar ataques de diccionario contra cualquier usuario válido que hayan encontrado, lo que podría hacerles entrar en un sistema con bastante rapidez si la contraseña es fácil de adivinar.

¿Por qué son tan peligrosas las vulnerabilidades de autenticación?

Hay una historia clásica del Viejo Oeste americano sobre un campesino paranoico que instaló tres cerraduras en su puerta principal, tapió sus ventanas y durmió con muchas armas al alcance de la mano. Por la mañana lo encontraron muerto. Sus atacantes llegaron hasta él porque se olvidó de cerrar la puerta trasera. Las vulnerabilidades de autenticación son muy parecidas. Realmente no importa qué tipo de herramientas de monitorización o controles proactivos tenga usted o cuántos analistas expertos emplee si un atacante puede utilizar un nombre de usuario y una contraseña válidos para entrar en su red.

Una vez dentro, hay muy pocas restricciones sobre lo que el atacante puede hacer. Siempre y cuando actúen dentro de sus permisos de usuario, que pueden ser bastante amplios si han comprometido una cuenta de administrador, hay muy pocas posibilidades de que sean atrapados a tiempo para evitar problemas graves. Esto hace que la clase de vulnerabilidades de autenticación sea una de las más peligrosas de tener en cualquier sistema.

Eliminación de las vulnerabilidades de autenticación

Una de las mejores formas de eliminar las vulnerabilidades de autenticación de una red es contar con buenas políticas de contraseñas aplicadas globalmente. No sólo se debe restringir a los usuarios, incluso a los administradores, el uso de contraseñas como "contraseña", sino que se les debe obligar a añadir un nivel de complejidad que haga inviable que un atacante aplique un ataque del tipo diccionario o frases comunes. Puedes establecer tus propias reglas para la creación de contraseñas en función de la importancia del sistema que se está protegiendo. Si lo haces, será mucho más difícil para los atacantes adivinar o forzar las contraseñas.

También deberías restringir el número de intentos fallidos de inicio de sesión, de modo que si se introduce una contraseña incorrecta más de, por ejemplo, tres veces, el usuario quede bloqueado. El bloqueo puede ser temporal, ya que incluso unos minutos de retraso impedirán que continúen los ataques automáticos de diccionario. O puede ser permanente, a menos que la cuenta sea desbloqueada por un administrador. En cualquier caso, el personal de seguridad debe ser alertado cada vez que se produzca un bloqueo de este tipo para que pueda controlar la situación.

Otra buena forma de evitar que los atacantes obtengan información es elaborar un mensaje genérico cada vez que se introduzca un nombre de usuario o una contraseña incorrecta. Debe ser el mismo para ambos casos para que los hackers no sepan si han sido rechazados porque un usuario no existe o por tener una contraseña incorrecta.

Las vulnerabilidades de autenticación están entre las más comunes y peligrosas en la mayoría de los sistemas. Pero también son bastante fáciles de encontrar y eliminar.

Más información sobre las vulnerabilidades de autenticación

Para más información, puedes echar un vistazo a la hoja de trucos de autenticación de OWASP. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

Enfréntese a una vulnerabilidad de autenticación en la plataforma Secure Code Warrior : [Comienza aquí]

Imagínese que se dirige a la puerta de un antiguo bar clandestino o de un club clandestino. El pequeño agujero de la puerta se abre y un fornido portero le pide la contraseña. El visitante potencial no conoce la contraseña y la adivina. Es errónea, así que el portero no le deja entrar.

Eso es lo que ocurriría normalmente. Ahora imagina que el visitante que ha adivinado la contraseña equivocada lo intenta de nuevo inmediatamente, se equivoca y se le vuelve a denegar el acceso. Imagina que el visitante potencial abre el diccionario y empieza a leer palabras, comenzando por algo como oso hormiguero y procediendo a probar todas las palabras posibles.

Lo más probable es que el rebote no permita que se produzca ese tipo de actividad, pero los sitios web y las aplicaciones con insuficiente antiautomatización hacen precisamente eso. Permiten a los usuarios seguir probando contraseñas, incluso utilizando técnicas de automatización, hasta que finalmente dan con la frase clave adecuada.

En este episodio, aprenderemos:

• Cómo los atacantes se aprovechan de la insuficiencia de la antiautomatización
• Por qué son peligrosas las aplicaciones con insuficiente antiautomatización
• Técnicas que pueden solucionar esta vulnerabilidad.

¿Cómo aprovechan los atacantes la insuficiencia de la antiautomatización?

El empleo de ataques de automatización o de tipo diccionario, como hizo nuestro visitante imaginario del bar clandestino, no es algo nuevo en ciberseguridad. De hecho, esos ataques de fuerza bruta fueron algunas de las primeras técnicas de los hackers. Y a medida que los ordenadores se hicieron más rápidos, se volvieron más y más eficientes. Un ordenador rápido puede recorrer todo un diccionario de palabras en pocos minutos, dependiendo de la velocidad de la conexión entre el ordenador atacante y el sistema objetivo.

Ese tipo de ataques automatizados fue la razón por la que se crearon programas y técnicas antiautomatización. Proporciona a las aplicaciones la capacidad de determinar si las acciones que realiza un usuario se salen de las normas del comportamiento humano típico.

Si una aplicación no cuenta con suficientes controles antiautomatización, los atacantes pueden simplemente seguir adivinando las contraseñas hasta encontrar una coincidencia. O bien, pueden utilizar el software de automatización para hacer otras cosas, como los comentarios de spam en los foros del sitio web.

¿Por qué es peligrosa una antiautonomía insuficiente?

Permitir que los usuarios malintencionados empleen la automatización para intentar burlar la seguridad puede ser peligroso. La razón por la que los ataques de tipo automatizado han persistido desde los primeros días de la informática hasta ahora es que pueden ser muy eficaces. Si se le da a un programa de automatización una cantidad ilimitada de tiempo para enviar contraseñas sin consecuencias por una adivinación incorrecta, eventualmente encontrará la correcta.

Cuando se utiliza en algo como un foro, tener oleadas de comentarios obviamente scripted podría frustrar a los usuarios válidos, o incluso actuar como una especie de ataque de denegación de servicio mediante el despilfarro de los recursos del sistema. La publicación automatizada también podría utilizarse como herramienta para un ataque de phishing o de otro tipo para exponer los señuelos al mayor número de personas posible.

Cómo arreglar los problemas de antiautonomía insuficientes

Para solucionar el problema de la insuficiencia de la antiautomatización, todas las aplicaciones deben tener la capacidad de determinar si las acciones que se llevan a cabo son ejecutadas por un humano o por un software de automatización. Una de las técnicas más populares y utilizadas es la prueba de Turing pública completamente automatizada para distinguir a los ordenadores de los humanos, o CAPTCHA.

El CAPTCHA es básicamente una prueba de Turing, propuesta por primera vez por el informático Alan Turing en 1950, mediante la cual se puede separar e identificar el comportamiento humano del informático. Los CAPTCHAs modernos presentan problemas que los humanos pueden resolver fácilmente, pero con los que los ordenadores tienen dificultades o simplemente no pueden resolver. Uno de los más populares presenta una foto separada por una cuadrícula y pide a los usuarios que identifiquen todos los sectores con un elemento específico en ella, como una flor o una cara. El ordenador no puede entender lo que se le pide y, por tanto, ni siquiera puede intentar escanear la imagen. Incluso si pudiera, el reconocimiento de imágenes está fuera del alcance de la mayoría de los programas que no han sido creados específicamente para ello.

Otros ejemplos de CAPTCHAs incluyen mostrar un texto borroso, hacer una pregunta lógica simple o incluso reproducir la pregunta en voz alta. Implementar un desafío CAPTCHA en puntos críticos de una aplicación, como cuando se pide una contraseña, puede detener los programas de automatización en su camino.

También es posible detener los programas de automatización simplemente limitando el número de conjeturas incorrectas de la misma fuente. Si se envían demasiadas conjeturas erróneas, la cuenta puede ser bloqueada temporalmente, retrasando así el programa de automatización más allá del punto de utilidad, o incluso podría requerir un administrador humano para desbloquear. Todo esto debería evitar las vulnerabilidades de la antiautomatización dentro de una aplicación.

Más información sobre la antiautomatización insuficiente

Para más información, puedes echar un vistazo a lo que dice la OWASP sobre la antiautomatización insuficiente. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

¿Preparado para encontrar y arreglar la antiautomatización insuficiente ahora mismo? Pon a prueba tus habilidades en nuestra arena de juego: [Empieza aquí]

A diferencia de la mayoría de las otras vulnerabilidades que hemos cubierto en esta serie de Share & Learn, los problemas de lógica de negocio no están directamente asociados con errores de codificación. Aunque los problemas de codificación pueden ser parte del problema, los errores de lógica de negocio son más frecuentemente el resultado de defectos de diseño o de suposiciones lógicas incorrectas cuando se crea una aplicación por primera vez.

Los problemas de lógica de negocio pueden ocurrir si un usuario realiza una acción imprevista al utilizar una aplicación. Esto puede ser casi cualquier cosa: desde cancelar inesperadamente un pedido, aplicar un código de cupón demasiadas veces o simplemente saltarse un paso esperado y realizar una acción que la aplicación no sabe cómo manejar. Explotar los fallos de la lógica de negocio no requiere ni siquiera formación, sólo un usuario malintencionado con una mente inquisitiva dispuesta a pensar fuera de la caja.

En este episodio, aprenderemos:

• Cómo aprovechan los atacantes los fallos en la lógica empresarial
• Por qué son peligrosas las aplicaciones con fallos en la lógica de negocio
• Técnicas que pueden evitar errores de lógica empresarial.

¿Cómo aprovechan los atacantes los problemas de lógica empresarial?

A diferencia de la mayoría de los exploits, no podemos señalar cadenas de código específicas que puedan causar esta vulnerabilidad. En su lugar, se trata de que los usuarios realicen acciones que no se han previsto y que los programas no saben cómo manejar. Como ejemplo, digamos que una aplicación bancaria permite a los usuarios transferir dinero a otras cuentas. Pero en lugar de enviar dinero, un usuario malicioso intenta enviar una cantidad negativa a otra cuenta. ¿Cómo reaccionará la aplicación bancaria? ¿Se bloqueará? ¿Rechazará la transferencia? ¿O podría devolver el dinero al usuario que inició la transferencia para equilibrar ese número negativo?

Los sitios de comercio electrónico son especialmente susceptibles, aunque no exclusivamente, a los fallos de la lógica empresarial porque están diseñados para que interactúen con ellos muchos usuarios y tienen muchos componentes. Los usuarios que cancelan sus pedidos de forma inesperada, que intentan aplicar cupones únicos varias veces o incluso que sobrecargan sus carritos de la compra pueden presentar a las aplicaciones condiciones que no se han previsto. Realmente no hay forma de saber cómo reaccionará un programa cuando se enfrente a una situación desconocida. En el mejor de los casos, podría generarse un mensaje de error, pero no hay garantía de que una aplicación no vaya a realizar una acción peor, como por ejemplo proporcionar mercancía de forma gratuita.

¿Por qué son peligrosos los problemas de lógica empresarial?

Los problemas de lógica de negocio pueden ser extremadamente peligrosos porque pueden ser explotados por cualquiera, incluso por alguien sin formación en programación o hacking. En realidad, sólo se requiere experimentación y tiempo, haciendo clic y tratando de encontrar fallas en la forma en que una aplicación está diseñada para responder. Y una vez que un usuario malintencionado descubre un fallo en la lógica de negocio de un sitio, puedes apostar que lo explotará al máximo.

El mayor peligro suele ser financiero, que un usuario compre 20 televisores de pantalla grande sin pagarlos, o algo así. Pero los fallos de lógica empresarial también pueden causar otros problemas. Por ejemplo, si la función de contraseña que protege un sitio no sabe qué hacer si un usuario pulsa constantemente la opción de cancelar, puede dejar que se salte el proceso de inicio de sesión.

Realmente no hay forma de anticipar el daño que puede causar un problema de lógica empresarial. A menudo, el primer indicio de un problema llega mucho después de que los usuarios lo hayan explotado.

Solución de problemas de lógica empresarial

Desafortunadamente, el uso de herramientas comunes como los escáneres de vulnerabilidad no ayudará a identificar o arreglar los problemas de lógica de negocio, ya que las pruebas para los problemas de lógica de negocio no se pueden automatizar fácilmente. La mejor manera de evitarlos es implementar una buena planificación, manejo de errores y pruebas para casos de prueba negativos mientras se desarrolla una aplicación. Esto requiere en primer lugar un conjunto claramente definido de reglas de negocio que incluya todas las acciones posibles y deseadas que una aplicación está diseñada para realizar.

Armado con un plan de reglas de negocio, una de las mejores maneras de evitar que se produzcan fallos en la lógica de negocio es crear un diagrama de flujo que muestre todas las formas posibles en que los datos y las transacciones deben fluir dentro de una aplicación. Esto incluye modelar el comportamiento para cada instancia en la que un usuario puede hacer una elección o introducir datos. Compruebe constantemente que las posibles acciones en el diagrama de flujo coinciden con las funciones en el plan de reglas de negocio.

Por último, utilice el modelado de amenazas para ayudar a identificar los fallos en la lógica empresarial durante las fases de diseño, implementación y prueba. Como medida de seguridad, cree una acción que el programa deba realizar si se encuentra con alguna situación no prevista específicamente. Esto podría ser tan simple como negar la acción y alertar a un administrador sobre el problema encontrado.

Más información sobre los problemas de lógica empresarial

Para más información, puedes echar un vistazo a las páginas de OWASP sobre problemas de lógica empresarial. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

¿Preparado para buscar y destruir vulnerabilidades de la lógica empresarial ahora mismo? Dirígete a la plataforma y pon a prueba tus habilidades: [Empieza aquí]

Hoy en día es habitual que los sitios web y las aplicaciones permitan a los usuarios enviar comentarios, recordatorios de citas y otros datos diversos a través de una aplicación mediante el correo electrónico. Normalmente este proceso es bastante benigno, y la mayoría de la gente ni siquiera piensa en ello en términos de un potencial riesgo de seguridad.

Sin embargo, como cualquier otro elemento de diseño que permite la entrada de datos por parte del usuario, si no se configuran adecuadamente, estas características aparentemente intrascendentes pueden ser manipuladas por usuarios maliciosos con fines nefastos. Todo lo que se necesita es dar al usuario la posibilidad de introducir un código en el campo de entrada que luego es procesado por error por el servidor. De repente, una aplicación de correo electrónico puede convertirse en un arma.

En este episodio aprenderemos:

• Cómo los atacantes pueden provocar una inyección de encabezado de correo electrónico
• Por qué son peligrosas las inyecciones de encabezado de correo electrónico
• Técnicas que pueden solucionar esta vulnerabilidad.

¿Cómo se activa una inyección de encabezado de correo electrónico?

Aunque no se suele considerar programable, la mayoría de las aplicaciones de contacto por correo electrónico o las funciones incluidas en sitios web o aplicaciones pueden aceptar entradas que cambien la naturaleza de la consulta. Normalmente, el servidor lo hace automáticamente después de que el usuario haya introducido su información, como su dirección de correo electrónico, en el campo de contratación. A continuación, el programa configura el mensaje, añade los destinatarios adecuados y lo envía utilizando su servidor de correo electrónico predeterminado.

Una solicitud POST de correo electrónico típica puede tener este aspecto:

POST /contacto.php HTTP/1.1
Host: www.example.com

Y generar un código parecido a este después de que un usuario haya introducido su información:

name=RealName&replyTo=RealName@ValidServer.com&message=YourAppointmentReminder

El problema se produce cuando los hackers comienzan a inyectar código en el proceso en lugar de sólo su información de contacto. Esto no es diferente a un ataque de tipo inyección SQL, pero realizado contra la aplicación de correo electrónico. Un ejemplo de una consulta manipulada que, en lugar de ello, enviaría spam desde su aplicación a un usuario objetivo podría tener el siguiente aspecto:

name=FakeName\nbcc: SpammedVictim@TargetAddress.com&replyTo= FakeName@ValidServer.com&message=Spammed mensaje

¿Por qué es peligrosa la inyección de encabezados de correo electrónico?

Dependiendo de la habilidad del usuario malintencionado y de sus intenciones, los ataques de inyección de encabezados de correo electrónico pueden ir desde simplemente molestos hasta altamente peligrosos en términos de gravedad. En el extremo inferior de la escala de gravedad, podrían insertar su información de contacto en el campo CCO de un mensaje saliente enviado a un buzón secreto o no revelado dentro de su empresa, revelándolo así a un hacker.

Lo que es más preocupante, podría permitirles controlar completamente su servidor de correo electrónico para enviar spam, phishing u otros correos de ataque desde su organización. No tendrían que intentar fingir que el correo electrónico procede de sus servidores internos, porque realmente se estaría originando allí. Y si usted no está supervisando esa actividad, pueden incluso automatizar el proceso, enviando cientos o miles de correos electrónicos utilizando los servidores de su organización, y de tal manera que parezca que usted está realmente instigando esa actividad.

Eliminación del problema de la inyección en el encabezado del correo electrónico

Al igual que con la inyección SQL y otros ataques de esta naturaleza, la clave para eliminar la posibilidad de que un usuario malintencionado explote una vulnerabilidad de la cabecera del correo electrónico es no confiar nunca en la entrada del usuario. Si un usuario es capaz de introducir información, aunque parezca un proceso trivial como introducir su dirección de correo electrónico, hay que asumir lo peor. O al menos asumir que lo peor es posible.

La validación de la entrada debe realizarse para todos los parámetros, y esto incluye cuando se añade una capacidad de contacto por correo electrónico a una aplicación o sitio web. Las listas blancas se pueden utilizar para habilitar específicamente los procesos y campos que se consideren válidos, mientras se deniega todo lo demás. De hecho, la mayoría de los frameworks tienen bibliotecas disponibles que pueden ser utilizadas para ayudar a bloquear las funciones sólo las necesarias. Esto evitará que cualquier código o comando introducido por usuarios maliciosos sea reconocido y procesado por sus servidores.

Más información sobre las inyecciones de cabecera de correo electrónico

Para más información, puedes consultar lo que dice la OWASP sobre las inyecciones de encabezados de correo electrónico. También puedes poner a prueba tus nuevos conocimientos defensivos con la demostración gratuita de la plataforma Secure Code Warrior , que forma a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para saber más sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

¿Crees que estás preparado para encontrar y arreglar una inyección de correo electrónico ahora mismo? Dirígete a la plataforma y pon a prueba tus habilidades: [Empieza aquí]

Las URL son esenciales para navegar por todos los sitios y aplicaciones web que conocemos y amamos. Su función básica es identificar dónde están los recursos y cómo recuperarlos. Aunque las URL son necesarias para que la World Wide Web funcione, también pueden suponer un riesgo para la seguridad si no se protegen adecuadamente.

En este post, aprenderemos:

• Qué es IDOR y cómo lo utilizan los atacantes
• Por qué el IDOR es peligroso
• Técnicas que pueden solucionar esta vulnerabilidad

Entender IDOR

Una referencia directa a un objeto es cuando se hace referencia a un registro específico (el "objeto") dentro de una aplicación. Suele adoptar la forma de un identificador único y puede aparecer en una URL.

Por ejemplo, puede observar algo como "?id=12345" al final de una URL. El número, 12345, es una referencia a un registro específico. Las vulnerabilidades de seguridad aparecen cuando el control de acceso no está presente en los registros individuales. Esto permite a los usuarios acceder a registros y datos que no deberían ver. Este es un ataque que requiere un nivel de habilidad relativamente bajo.

En este caso, digamos que un atacante cambia el ID en la URL a 12344. En una aplicación vulnerable a IDOR, el atacante podría ver los datos correspondientes a ese registro.

¿Cuánto daño puede causar realmente este tipo de vulnerabilidad?

Sepa por qué el IDOR es peligroso

Cuando los desarrolladores no tienen cuidado, pueden diseñar un sistema que muestre y filtre registros de la aplicación en varios lugares. Una brecha de esta magnitud puede ser importante, especialmente cuando se trata de datos sensibles o PII.

La Agencia Tributaria australiana creó un sitio web para ayudar a las empresas a recaudar un nuevo impuesto. Desgraciadamente, venía empaquetado con la característica no deseada de una vulnerabilidad de IDOR. Un usuario curioso se dio cuenta de que las URL del sitio contenían su número de empresa australiana, o ABN. Sucede que este es un número fácilmente descubrible para cualquier negocio registrado. Este usuario decidió poner los números de otras empresas en la URL. De este modo, obtuvo la información de sus cuentas bancarias y sus datos personales.

Apple ha sido recientemente víctima de una vulnerabilidad de IDOR. Cuando se lanzó el iPad, se filtraron 114.000 direcciones de correo electrónico de clientes. (Para ser justos, fue más bien un error por parte de AT&T).

Verás, AT&T creó un servicio para soportar la conectividad 3G de los iPad. El iPad enviaba un identificador almacenado en la tarjeta SIM al servicio de AT&T. El servicio entonces devolvía la dirección de correo electrónico del usuario.

Desgraciadamente, estos identificadores eran simples números enteros secuenciales y, por tanto, fácilmente adivinables. Los atacantes iteraban a través de los identificadores y robaban las direcciones de correo electrónico.

Otro error fue que el servicio de AT&T trató de "asegurar" el servicio devolviendo sólo la dirección de correo electrónico si la cabecera del agente de usuario de la solicitud indicaba que procedía de un iPad. El user-agent es solo un valor de cadena que puede ser fácilmente manipulado.

Las vulnerabilidades de IDOR pueden ser sutiles y furtivas. Vamos a discutir cómo derrotarlas.

Derrotar a IDOR

El control de acceso es la clave para resolver el problema del IDOR. Cuando un usuario solicita un registro específico, asegúrate de que está autorizado a ver el registro solicitado.

La mejor manera de hacerlo es utilizar módulos de autorización centralizados. Herramientas como Spring Security proporcionan una autenticación y autorización robustas y personalizables para las aplicaciones.

En resumen: tener un módulo en el que se apoye el resto del código para realizar las comprobaciones de autorización.

Otra mitigación común es el uso de referencias sustitutas. En lugar de utilizar los identificadores reales de los registros de la base de datos en sus URL, puede crear números aleatorios que se correspondan con los registros reales.

El uso de referencias sustitutas garantiza que un atacante no pueda llegar a un registro simplemente adivinando el siguiente identificador válido.

Y, por último, no confíes en nada que el usuario pueda manipular para proporcionar autorización. AT&T intentó utilizar la cabecera user-agent para autorizar su servicio. No confíes en las cabeceras HTTP, las cookies o los parámetros GET y POST.

Con estas medidas de mitigación, el IDOR será cosa del pasado.

Asegure sus referencias

Las referencias directas a objetos inseguras son una de las vulnerabilidades más fáciles de explotar. No dejes que te sorprendan cuando menos lo esperes. Comprueba siempre que los usuarios están autorizados. No utilices identificadores de base de datos reales. No dependa de los datos controlados por el usuario para la autorización.

Construya su dominio consultando nuestros recursos de aprendizaje. Al practicar cómo mitigar las vulnerabilidades de IDOR en el lenguaje de su elección, no tendrá ningún problema para encontrar y solucionar este problema en sus bases de código de producción. También puede poner a prueba sus nuevos conocimientos defensivos con una demostración gratuita de la plataforma Secure Code Warrior , que capacita a los equipos de ciberseguridad para que se conviertan en los mejores ciberguerreros. Para obtener más información sobre cómo derrotar esta vulnerabilidad, y una galería de pícaros de otras amenazas, visite el blogSecure Code Warrior .

¿Listo para defenderte de los ataques de IDOR ahora mismo? Dirígete a la plataforma y desafíate gratis: [Empieza aquí]