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í]

Los datos son la savia de las empresas. Es la información fundamental que necesitan para sobrevivir, para ganar dinero y para ofrecer servicios a sus clientes. En esta sociedad cada vez más centrada en lo digital, los desarrolladores tienen una inmensa responsabilidad como administradores de esta preciosa información. Cuando los desarrolladores no protegen los datos confidenciales, la empresa es presa de un almacenamiento criptográfico inseguro.

Veamos cómo almacenar los datos de forma segura y lo que puede ocurrir si no se hace.

Comprender el almacenamiento criptográfico inseguro

Cuando los atacantes acceden a un sistema, suelen ir a la caza de datos de valor. Ya sabes, el tipo de datos que pueden utilizarse para hacerse con la cuenta de alguien o para ejecutar otro ataque. A veces, este tipo de datos simplemente se vende en el mercado negro para obtener dinero rápido.

El almacenamiento criptográfico inseguro no es una vulnerabilidad única como la inyección SQL o el XSS. Es una consecuencia de no proteger los datos que deberías proteger, de la manera que necesitas protegerlos.

La información sensible debe estar protegida. Cuando almacena contraseñas e información de tarjetas de crédito en texto plano, está jugando a la ruleta rusa con su negocio.

Si un pirata informático entra en tu base de datos y roba datos mediante inyección SQL, inyección XML o cualquier otro ataque, lo tendrá todo. Sin embargo, si encriptas tus datos, les será mucho más difícil hacer un uso real de ellos.

Es importante tener en cuenta que las brechas no siempre son el resultado de un extraño malicioso. Una persona ajena a la empresa también puede robar datos con facilidad si no están encriptados. Los empleados de su empresa no tienen por qué ver todo lo que hay en la base de datos, y los controles de acceso inadecuados o los datos sensibles expuestos pueden dar lugar a un auténtico robo.

Recuerda también que no todo el cifrado es igual. Utilizar los algoritmos criptográficos equivocados es tan peligroso como no utilizarlos. Los algoritmos débiles conocidos ofrecerán poca resistencia a los atacantes astutos.

Por qué es peligroso el almacenamiento criptográfico inseguro

Muchas empresas se ven comprometidas por otra vulnerabilidad (como la inyección SQL) y acaban siendo incapaces de ocultar los datos robados. Esto hace que una situación terrible sea aún peor.

• Adult Friend Finder fue vulnerado, filtrando 412 millones de cuentas. Las contraseñas de las cuentas estaban protegidas con el débil algoritmo hash SHA-1. Los atacantes las descifraron fácilmente en un mes.
• Uber fue violado, filtrando 57 millones de registros de usuarios y 600.000 registros de conductores. Se perdió información personal. Sucedió porque la cuenta de GitHub de Uber tenía un repositorio que contenía el nombre de usuario y la contraseña de la cuenta de AWS de Uber a la vista... no es una buena idea. La valoración de Uber cayó en 20.000 millones de dólares, en gran parte debido a esta brecha.
• La red PlayStation Network de Sony fue vulnerada, filtrando 77 millones de cuentas. 12 millones de las cuentas contenían información de tarjetas de crédito sin cifrar. Más tarde, Sony llegó a un acuerdo en una demanda colectiva de 15 millones de dólares por la filtración.

Está claro que hay consecuencias graves por no almacenar adecuadamente los datos sensibles.

Sony fue demandada, lo que supone una sanción importante. Sin embargo, incluso si no te demandan, el daño a la reputación y a la normativa puede ser catastrófico para una empresa.

Derrotar el almacenamiento criptográfico inseguro

¿Cómo pueden los desarrolladores evitar que se produzcan violaciones de datos como las anteriores?

El primer paso es identificar qué datos requieren encriptación en primer lugar. Después de todo, no todos los datos son iguales. Clasifique sus datos y, a continuación, utilice el cifrado cuando proceda.

En general, hay que proteger la información personal, como los números de la seguridad social, las contraseñas y los datos de las tarjetas de crédito. Dependiendo de la naturaleza de su negocio, es posible que tenga que proteger los registros de salud u otra información que se considere privada.

Una vez que sepas qué datos hay que proteger, el siguiente paso es utilizar las herramientas adecuadas para garantizar su seguridad. En general, es bueno ceñirse a los algoritmos criptográficos que han superado la prueba del tiempo y se consideran fuertes.

Pase lo que pase, no escribas tus propias funciones criptográficas. Es probable que contengan fallos que los atacantes puedan utilizar para romper el cifrado.

Para encriptar datos como los números de la seguridad social o los datos de las tarjetas de crédito, utilice AES. Hay diferentes modos de funcionamiento para AES, un modo muy recomendado en el momento de escribir este artículo es el modo Galois/Contador (GCM). Otro consejo es asegurarse de que no se utiliza ningún tipo de relleno en las bibliotecas que le piden que elija un tipo de relleno.

En el caso de las contraseñas, utilice un algoritmo de hash para las contraseñas porque los hashes no pueden ser revertidos. Dado un valor fuertemente hash, un atacante no puede recuperar el texto original que creó el valor. Argon2 y Bcryptse consideran opciones sólidas para el hash de contraseñas. Recuerda siempre "poner sal" a la contraseña con un valor aleatorio antes de hacer el hash para que no haya dos hashes iguales para la misma contraseña.

Estas funciones tendrán implementaciones para todos los principales lenguajes/marcos de programación. Consulta la documentación de tu lenguaje o framework específico para obtener información sobre cómo utilizarlas de forma eficaz.

La generación, el almacenamiento y la gestión de claves son componentes importantes de la criptografía. Las claves mal gestionadas pueden ser expuestas y utilizadas para descifrar sus datos. Algunos marcos de trabajo ayudan a la gestión de claves, como la API de protección de datos de ASP.NET. Para conocer las mejores prácticas generales de gestión de claves, consulte la hoja de trucos de OWASP.

El almacenamiento seguro de sus datos es la forma de evitar costosas y embarazosas violaciones de datos. En el peor de los casos, si un atacante es capaz de robar tus datos, le será mucho más difícil verlos o utilizarlos para cualquier propósito nefasto.

Oculte sus datos a la vista

Repasemos rápidamente cómo proteger sus datos:

• Clasifique sus datos para saber qué requiere protección
• Utilizar algoritmos fuertes y probados por la industria para encriptar datos sensibles
• Almacena tus contraseñas utilizando hashes unidireccionales fuertes

Para profundizar en el tema, consulte nuestros recursos de aprendizaje. Cuando esté listo para profundizar y practicar, pruebe nuestra plataforma en su idioma preferido. Cubrimos mucho!

Con estas herramientas, puede evitar que le roben sus datos y evitar que su empresa pierda dinero y dañe su reputación.

¿Listo para encontrar y arreglar el almacenamiento criptográfico inseguro ahora mismo? Dirígete a la arena y pon a prueba tus habilidades [empieza aquí]

Los ataques de inyección XQuery se consideran a veces como el hermano pequeño de los ataques de inyección SQL más frecuentes. Tienen causas similares, y los comandos que los atacantes explotan para desencadenarlos son también muy parecidos. Sólo que los ataques de inyección XQuery sólo pueden ocurrir durante una consulta XPath para datos XML. Debido a esto, a veces se llaman Inyección XPath o simplemente ataques XPath, ya que ese es el método de entrega utilizado.

La gran mayoría de los sitios web utilizan bases de datos XML para realizar funciones críticas, como mantener las credenciales de acceso de los usuarios, la información de los clientes, la información de identidad personal y los datos confidenciales o sensibles, lo que hace que los ataques XQuery tengan una huella de ataque bastante grande.

En este episodio, aprenderemos:

• Cómo utilizan los atacantes las inyecciones XQuery
• Por qué son peligrosas las inyecciones de XQuery
• Técnicas que pueden solucionar esta vulnerabilidad.

¿Cómo se desencadena una inyección de XQuery por parte de los atacantes?

Al igual que la mayoría de los lenguajes informáticos, el código de XPath fue diseñado para la simplicidad. De hecho, XPath es un lenguaje estándar, y todas las notaciones y declaraciones sintácticas no cambian, independientemente de la aplicación que las utilice. Esto significa que los comandos utilizados para manipular una consulta XPath son bien conocidos, e incluso pueden ser automatizados.

En esencia, una consulta XPath es una simple sentencia que indica a la base de datos XML qué información debe buscar. En uno de los ejemplos más simplistas, se utiliza para comprobar si existe un registro de usuario y, a continuación, para recuperar sus credenciales de acceso. El problema es que como las consultas XPath incluyen la entrada del usuario, los hackers pueden manipular la consulta para devolver información que debería estar protegida.

Por ejemplo, al tratar de eludir la seguridad del inicio de sesión, un atacante puede añadir variables al final de su consulta XPath que eluden todo el proceso. Un ejemplo podría ser el siguiente:

//Employee[UserName/text()=anyone or 1=1 or a=a And Password/text()=doesnotmatter]

Aquí, el campo Nombre de usuario se hace coincidir con cualquier usuario debido a la declaración 1=1 o a=a. El campo de la contraseña ni siquiera importa, ya que sólo la primera parte de la consulta debe ser verdadera.

¿Por qué es peligrosa la inyección de XQuery?

Una de las principales razones por las que los ataques de inyección de XQuery son tan peligrosos es porque permiten a los atacantes eludir la seguridad del inicio de sesión y de la cuenta. Y permiten hacerlo de forma automatizada utilizando un lenguaje estándar que no varía según la aplicación. Los atacantes pueden escanear automáticamente los sitios web y las aplicaciones en busca de esta vulnerabilidad y actuar en cuanto la descubren. Si tu aplicación es vulnerable, los atacantes la comprometerán. Además de comprometer la seguridad de las cuentas, los ataques XQuery también pueden utilizarse para la exfiltración de datos. Por ejemplo, un atacante podría transferir todos los registros fuera de la base de datos XML.

Eliminación de los ataques de inyección de XQuery

Al igual que con vulnerabilidades similares, una defensa clave es simplemente no confiar en la entrada del usuario. Cada vez que un usuario puede introducir información, ya sea que esté haciendo una consulta a la base de datos o no, el proceso debe ser escudriñado. No es muy diferente a asegurar las ventanas y puertas de un edificio físico, ya que esas son las principales vías de acceso.

Para la protección de la inyección de XQuery, esto se hace mediante el saneamiento de la entrada del usuario a través del filtrado, o mediante el uso de la validación de entrada de la lista blanca de la entrada del usuario. También puede utilizar una interfaz XPath parametrizada, similar a las sentencias preparadas para las consultas SQL.

Por último, asegúrese de aplicar el mínimo privilegio a todas las aplicaciones. Eso podría significar crear un usuario con privilegios de sólo lectura para realizar todas las consultas de la aplicación.

Utilizando estas técnicas, es posible detener todos los intentos de inyección de XQuery realizados contra su sitio web o aplicación.

Más información sobre las inyecciones XQuery

Para más información, puedes echar un vistazo a lo que dice OWASP sobre las inyecciones XQuery. También puedes poner a prueba tus nuevos conocimientos defensivos con una 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 blog Secure Code Warrior.

El término desconfiguración de la seguridad es un poco un cajón de sastre que incluye vulnerabilidades comunes introducidas debido a los ajustes de configuración de la aplicación, en lugar de un mal código. Las más comunes normalmente implican errores simples que pueden tener grandes consecuencias para las organizaciones que despliegan aplicaciones con esas malas configuraciones.

Algunos de los errores de seguridad más comunes son no desactivar los procesos de depuración en las aplicaciones antes de desplegarlas en el entorno de producción, no dejar que las aplicaciones se actualicen automáticamente con los últimos parches, olvidarse de desactivar las funciones por defecto, así como una serie de otras pequeñas cosas que pueden suponer un gran problema en el futuro.

La mejor manera de combatir las vulnerabilidades de desconfiguración de seguridad es eliminarlas de su red antes de que se desplieguen en el entorno de producción.

En este episodio, aprenderemos:

• Cómo los hackers encuentran y explotan los errores de seguridad más comunes
• Por qué pueden ser peligrosas las desconfiguraciones de seguridad
• Políticas y técnicas que se pueden emplear para encontrar y arreglar los fallos de seguridad.

¿Cómo aprovechan los atacantes los errores de seguridad más comunes?

Hay muchos errores de seguridad comunes. Las más populares son bien conocidas en las comunidades de hackers y casi siempre se buscan cuando se buscan vulnerabilidades. Algunas de las configuraciones erróneas más comunes incluyen, pero no se limitan a:

• No desactivar las cuentas por defecto con contraseñas conocidas.
• Dejar activadas las funciones de depuración en producción que revelan las trazas de pila u otros mensajes de error a los usuarios.
• Funciones innecesarias o por defecto que se dejan activadas, como puertos, servicios, páginas, cuentas o privilegios innecesarios.
• No utilizar cabeceras de seguridad, o utilizar valores inseguros para ellas.

Algunas configuraciones erróneas son bien conocidas y triviales de explotar. Por ejemplo, si se habilita una contraseña por defecto, un atacante sólo tendría que introducirla junto con el nombre de usuario por defecto para obtener acceso de alto nivel a un sistema.

Otras configuraciones erróneas requieren un poco más de trabajo, como cuando se dejan activadas las funciones de depuración después de desplegar una aplicación. En ese caso, un atacante intenta provocar un error y registra la información devuelta. Armado con esos datos, puede lanzar ataques muy específicos que pueden exponer información sobre el sistema o la ubicación de los datos que están tratando de robar.

¿Por qué son tan peligrosas las desconfiguraciones de seguridad?

Dependiendo de la desconfiguración de seguridad exacta que se explote, el daño puede ir desde la exposición de la información hasta el compromiso completo de la aplicación o el servidor. Cualquier desconfiguración de seguridad proporciona un agujero en las defensas que los atacantes hábiles pueden aprovechar. En el caso de algunas vulnerabilidades, como tener activadas las contraseñas por defecto, incluso un hacker sin experiencia puede explotarlas. Después de todo, ¡no hace falta ser un genio para buscar contraseñas por defecto e introducirlas!

Eliminación de la amenaza que suponen los fallos de seguridad

La mejor manera de evitar errores de seguridad es definir una configuración segura para todas las aplicaciones y programas que se despliegan en una organización. Esto debería incluir cosas como la desactivación de puertos innecesarios, la eliminación de programas y funciones por defecto que no utilice la aplicación, y la desactivación o el cambio de todos los usuarios y contraseñas por defecto. También debe incluir la comprobación y el tratamiento de errores de configuración comunes, como desactivar siempre el modo de depuración en el software antes de que llegue al entorno de producción.

Una vez definidos, debe establecerse un proceso por el que pasen todas las aplicaciones antes de ser desplegadas. Lo ideal sería que alguien estuviera a cargo de este proceso, con el poder suficiente para hacerlo cumplir, y también con la responsabilidad en caso de que se produzca un error de configuración de seguridad común.

Más información sobre los fallos de seguridad

Para más información, puedes consultar la lista OWASP de los errores de seguridad más comunes. También puedes poner a prueba tus nuevos conocimientos defensivos con una 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 desbaratar un fallo de seguridad ahora mismo? Dirígete a nuestra plataforma y desafíate a ti mismo [Empieza aquí]

Susie abre su correo electrónico para escapar de un desagradable informe que debe entregar en dos días. Ve que aparece en su bandeja de entrada un enlace para conseguir un iPad gratis. Después de hacer clic en él, va a un sitio web con un gran banner en el que se lee: "¡Haga clic aquí para obtener su iPad gratis!". Hace clic en el botón, pero parece que no pasa nada. El problema es que sí pasó algo.

Después de navegar de nuevo a su bandeja de entrada, se da cuenta de que todos sus correos electrónicos han sido borrados. Ni siquiera ha pulsado "borrar" en ninguno de ellos. ¿Qué está pasando?

El sitio de correo electrónico fue objeto de clickjacking. El clickjacking engaña a los usuarios para que realicen acciones que no tenían intención de llevar a cabo, y puede dar lugar a graves problemas.

Veamos ahora cómo funciona el clickjacking, por qué es peligroso y qué pueden hacer los desarrolladores como usted para evitarlo:

Entender el clickjacking

El clickjacking, también llamado "ataque de redireccionamiento de la interfaz de usuario", se produce cuando un atacante utiliza varias capas transparentes en una página web para engañar al usuario para que haga clic en un botón o enlace en el que no tiene intención de hacer clic.

¿Alguna vez has tenido un bicho atrapado en tu coche? Vuelan contra la ventanilla tratando furiosamente de salir al exterior. La intención del bicho es volar hacia lo que parecen árboles y aire libre, sin tener en cuenta el cristal que bloquea su camino.

El clickjacking tiene un diseño similar, salvo que el usuario es el bicho y su sitio web es el cristal que bloquea el camino. El usuario ve algo que quiere, como un iPhone gratis. El atacante coloca su sitio web dentro de un marco transparente encima del anuncio del iPhone gratis. Cuando el usuario hace clic en el botón para coger el supuesto premio "gratis", en realidad está haciendo clic en un botón de su sitio, realizando una acción que no tenía prevista.

Por qué el clickjacking es peligroso

¿Qué puede hacer un atacante con el clickjacking? Depende en gran medida de la funcionalidad del sitio web en cuestión.

El atacante podría conseguir que un usuario le diera un "me gusta" o compartiera el sitio del atacante en las redes sociales. Esto puede ser fácil de conseguir, ya que muchas personas permanecen conectadas a sus cuentas de redes sociales por razones de comodidad.

Si su sitio puede colocarse en un marco, una operación sensible puede completarse haciendo clic en un botón, y esto puede actuar como un vector de ataque. Por ejemplo, un usuario hace clic para obtener un iPad gratuito, pero en su lugar cambia la configuración de la cuenta en su sitio para hacerla menos segura. Un ataque de este tipo se produjo contra la página de configuración del plugin de Adobe Flash. Los ajustes podían colocarse en un marco transparente, engañando al usuario para que permitiera el acceso de cualquier animación Flash al micrófono y la cámara. Los atacantes podían entonces grabar a la víctima; una importante invasión de la privacidad.

Un cliente de correo electrónico podría ser enmarcado en un sitio, haciendo que el usuario borre todos los correos electrónicos de su buzón o reenvíe los correos a una dirección de correo electrónico controlada por el atacante.

La conclusión es que el usuario no puede ver lo que hace clic, por lo que se le puede convencer de que haga clic en cualquier cosa. Ya sea una acción social o la descarga de un malware, las posibilidades son enormes.

Cómo vencer el clickjacking

El clickjacking se puede prevenir. La forma recomendada para evitar el clickjacking es definir una política de seguridad de contenidos, o CSP, para su sitio. Utilizando la cabecera de respuesta HTTP "frame ancestors", puede controlar cómo se puede enmarcar su sitio.

• "frame-ancestors none" - Ningún otro sitio puede enmarcar el suyo. Esta es la configuración recomendada.
• "frame-ancestors self'- Las páginas de su sitio sólo pueden ser enmarcadas por otras páginas dentro de su sitio.
• "frame-ancestors self <uri list=""> - Your site can be framed by the sites in the URI lists and no others.</uri>

Actualmente, los principales navegadores no admiten los anclajes de marco CSP. Utilice la cabecera HTTP "X-Frame-Options" como opción alternativa para dichos navegadores.

• DENEGAR - Nadie puede enmarcar su sitio. Esta es la configuración recomendada
• SAMEORIGIN - Lo mismo que "self'for CSP". Puedes enmarcar tu propio contenido, pero nadie más puede hacerlo.
• ALLOW-FROM <uri> - Allow the specified URI to frame your content.</uri>

No se deje secuestrar por los clics

El clickjacking es un ataque inteligente y engañoso que puede provocar daños a la reputación y pérdidas de ingresos si su producto puede ser manipulado por los atacantes. Consulta nuestros recursos de aprendizaje gratuitos para saber más sobre el clickjacking.

Utilice una política de seguridad de contenidos y la cabecera "X-Frame-Options" para evitar que otros utilicen su sitio de forma maliciosa. No permita que los atacantes manipulen a sus usuarios. No se deje secuestrar por los clics.

Un ataque de inyección de comandos al sistema operativo puede ocurrir siempre que una aplicación permita a los usuarios hacer entradas en un shell, pero no toma ninguna acción para verificar que las cadenas de entrada son válidas. Esto permite a un atacante soltar comandos directamente en el sistema operativo que aloja la aplicación, y en cualquier nivel de permiso que se establezca para la aplicación comprometida.  

Los ataques de inyección de comandos en el sistema operativo pueden ser realizados por hackers de nivel básico y menos cualificados, lo que los convierte en una de las debilidades más comunes que experimentan los equipos de seguridad. Afortunadamente, hay algunas formas muy eficaces de evitar que tengan éxito. En este episodio, aprenderemos:

       Cómo funcionan

       Por qué son tan peligrosos

       Cómo puede poner defensas para detenerlos.

¿Cómo utilizan los atacantes la inyección de comandos en el sistema operativo?

Lo primero que debe hacer un atacante para iniciar un ataque de inyección de comandos al sistema operativo es localizar las entradas del usuario dentro de una aplicación. Los formularios que los usuarios rellenan son potencialmente buenos puntos de partida. Los atacantes más astutos también pueden utilizar cosas como las cookies o incluso las cabeceras HTTP como punto de partida, algo utilizado por casi todas las aplicaciones o sitios web.

Lo segundo que tienen que hacer es averiguar qué sistema operativo alberga la aplicación. Dado que sólo hay un puñado de opciones, la prueba y el error pueden funcionar bien para esta fase. La mayoría de los servidores de aplicaciones van a estar basados en Windows (el tipo de Windows no suele importar), en algún tipo de caja Linux, o en la posibilidad de Unix.

En ese momento, el hacker modifica la entrada para inyectar un comando del sistema operativo en una entrada aparentemente inocua. Esto puede engañar al sistema operativo anfitrión para que ejecute comandos no deseados en cualquier nivel de permiso que tenga la aplicación.

Por ejemplo, el siguiente comando puede ser utilizado por usuarios válidos dentro de una aplicación para ver el contenido de un archivo, en este caso las notas de una reunión mensual de la junta directiva.

exec("cat " + nombre de archivo)

En nuestro ejemplo, esto ejecutaría el siguiente comando y devolvería las notas de la reunión al usuario.

$ ./cat MeetingNotes.txt

En la reunión de julio estuvieron presentes tres miembros del comité ejecutivo. Se debatió el nuevo proyecto de presupuesto, pero no se tomaron medidas ni se votó.

Esto es lo que ocurre cuando un atacante añade comandos adicionales al final de la entrada, como el que se utiliza para listar el contenido de un directorio en Linux. En este caso, el comando original, que muestra las notas de la reunión, sigue ocurriendo. Pero al usuario malicioso también se le muestra todo lo que hay en el directorio, y qué otros comandos pueden utilizar en los ataques de inyección de comandos del sistema operativo. Ellos ingresan:

$ ./cat MeetingNotes.txt && ls

Y en vez de eso, consigue esto:

En la reunión de julio estuvieron presentes tres miembros del comité ejecutivo. Se debatió el nuevo proyecto de presupuesto, pero no se tomaron medidas ni se votó.

MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c

Como puedes ver, en este caso, no sólo se le mostró al hacker el contenido del directorio, sino que también se le dio un menú de otros comandos que podía utilizar " comandos que ahora saben que pueden ejecutar en el sistema operativo anfitrión.

¿Por qué son tan peligrosos los ataques de inyección de comandos al sistema operativo?

Permitir a los usuarios eludir el propósito de la aplicación objetivo y utilizarla para ejecutar comandos del sistema operativo es extremadamente arriesgado. Un atacante puede realizar fácilmente acciones devastadoras como robar datos confidenciales o formatear una unidad de disco entera del servidor, por ejemplo. Las opciones disponibles para un atacante sólo están limitadas por los comandos permitidos dentro del sistema operativo y su creatividad al utilizarlos.

Los comandos del sistema operativo se ejecutan al mismo nivel de permiso que la aplicación. Las aplicaciones que se ejecutan con privilegios administrativos significan que los hackers que las comprometen pueden ejecutar todos los comandos del sistema operativo.

Los patrones de ataque para la inyección de comandos en el sistema operativo son bien conocidos y documentados. Una aplicación vulnerable es tan susceptible a los script kiddies como a los hackers profesionales. Los atacantes con muy poca habilidad pueden intentar cortar y pegar comandos del SO en las aplicaciones para ver qué pasa.

Obtención de un OK de seguridad contra las inyecciones de comandos del sistema operativo

Hay varias técnicas buenas que pueden detener las inyecciones de comandos del sistema operativo. El primer paso es ejecutar las aplicaciones con la menor cantidad de privilegios necesarios para cumplir su función. Esto no evita un ataque, pero si se produce una brecha, el daño se minimiza.

La mayoría de los lenguajes de programación y frameworks proporcionan llamadas a la API para métodos comunes del SO como listar el contenido de los directorios, crear o leer archivos en el disco duro. Una forma perfecta de eliminar las inyecciones de comandos del SO de su entorno es hacer que todas las aplicaciones utilicen estas llamadas a la API en lugar de los comandos del SO directamente.

Cuando esto no sea posible, valide las entradas del usuario antes de utilizarlas en los comandos del sistema operativo. Las listas blancas se pueden utilizar para garantizar que sólo se puede utilizar un pequeño conjunto de valores de confianza. Es técnicamente posible hacer esto usando una lista negra también, pero probablemente hay muchos menos comandos permitidos, así que las listas blancas son casi siempre más fáciles. No te olvides de incluir parámetros POST y GET válidos en tu lista blanca, así como vectores de entrada del usuario que a menudo se pasan por alto, como las cookies.

Por último, si no hay una API de programación disponible y no se puede utilizar una lista blanca, utilice una biblioteca de sanitización para escapar de cualquier carácter especial en las entradas del usuario antes de utilizarlos en los comandos del sistema operativo.

Más información sobre los ataques de inyección de comandos al sistema operativo

Para más información, puedes echar un vistazo al artículo de OWASP sobre los ataques de inyección de comandos al sistema operativo. 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 .

Usted navega por un sitio web y se conecta. Como es normal, llena su cesta de productos que desea comprar. Entonces, ¡vaya!, su mano se resbala y cierra la pestaña del navegador. Después de un pequeño ataque de pánico, vuelve a introducir la URL del sitio en el navegador y pulsa la tecla "Enter". Vuelves a entrar en el sitio, te conectas y todos tus artículos siguen en el carrito. Uf.

¿Cómo sabía el sitio quién era usted sin reautenticarse? Te identificaba porque utilizaba sesiones. Las sesiones son la clave para una buena experiencia de usuario cuando se utiliza la web. Sin embargo, una gestión incorrecta de las sesiones puede dar lugar a agujeros de seguridad que los atacantes pueden explotar.

Repasemos ahora lo que significa la gestión de sesiones, cómo puede perjudicarle una gestión de sesiones deficiente y qué puede hacer para gestionar las sesiones correctamente.

Comprender los puntos débiles de la gestión de sesiones

Una sesión se refiere a un valor almacenado en el servidor, específico para un solo usuario de la aplicación. Esto es necesario por dos razones: En primer lugar, HTTP es un protocolo sin estado. Cada solicitud es independiente y no tiene conocimiento de las solicitudes que han llegado antes o después de ella. Una sesión ayuda al servidor a saber quién ha enviado la petición. De lo contrario, habría que iniciar una sesión cada vez que se pulsara un botón o un enlace.

La segunda razón de las sesiones es la autorización del usuario. El identificador de sesión puede utilizarse para reconocer a un usuario específico con derechos específicos dentro del sistema. La aplicación sabrá quién es la persona y qué puede hacer.

Hay dos componentes en una sesión. Un almacén de datos en el lado del servidor almacena un identificador de sesión y lo asigna a información sobre el usuario, como su identificación de usuario o la información del carrito. El mismo identificador de sesión se envía al navegador en una cookie. Las cookies son almacenadas por el navegador en el sistema del usuario. El cliente pasa la cookie con cada solicitud, haciendo saber al servidor que esa solicitud proviene del mismo usuario. La mayoría de las aplicaciones utilizan las sesiones para hacer un seguimiento de los usuarios tanto antes como después de la autenticación.

La gestión adecuada de la sesión es esencial para la seguridad de una aplicación. Un ID de sesión válido tiene el mismo nivel de confianza que un nombre de usuario/contraseña, o incluso un token de autenticación de segundo factor.

Por qué una mala gestión de la sesión es peligrosa

Una mala gestión de la sesión puede llevar a una toma de posesión completa de la cuenta. Esto significa que los datos de los clientes pueden ser robados, o los productos podrían ser comprados de forma fraudulenta. Hay varias formas de que los atacantes obtengan un ID de sesión válido.

Un ataque de fijación de sesión se produce cuando las sesiones no se cambian en momentos clave, como cuando un usuario se conecta al sistema, y si los identificadores de sesión pueden establecerse utilizando la URL. Fijar los identificadores de sesión de esta manera puede ser utilizado para mantener a los usuarios conectados a través de diferentes aplicaciones que utilizan la misma fuente de autenticación. En este caso, un atacante puede navegar a un sitio web y obtener un identificador de sesión. A continuación, el atacante envía una URL a una víctima desprevenida por correo electrónico con el identificador de sesión en la URL. La víctima hace clic en la URL del correo electrónico y se conecta al sitio web. Si el ID de sesión no se rota al iniciar la sesión, el atacante tiene ahora un ID de sesión válido y autentificado. Esto permite la toma de posesión completa de la cuenta.

Otro ataque a la mala gestión de sesiones es un ataque de fuerza bruta de adivinación. Cuando los desarrolladores intentan crear sus propios sistemas de gestión de sesiones, a menudo utilizan identificadores de sesión que son bastante sencillos de adivinar. Estos pueden ser una secuencia (1, 2, 3) o un patrón predecible de algún tipo. El atacante simplemente sigue adivinando los ID de sesión hasta que descubre uno válido. Esto también conduce a una toma de posesión de la cuenta.

Las sesiones que no se invalidan automáticamente después de un cierto tiempo pueden ser explotadas para atacar a los usuarios. Un ataque exitoso de falsificación de solicitudes entre sitios depende de que las sesiones sigan siendo válidas después de que el usuario abandone el sitio. Digamos que un atacante coloca un iframe o una imagen en un sitio visitado por el usuario. El atributo "src" (fuente) se establece en la URL del sitio vulnerable y realiza una acción en nombre del usuario. Por ejemplo, se puede hacer que una aplicación bancaria vulnerable transfiera dinero a la cuenta de un atacante sin el permiso del usuario.

La gestión de la sesión puede ser complicada, y los puntos débiles pueden ser devastadores. Sin embargo, es un problema bien conocido y puede resolverse.

Derrotar a la gestión de sesiones inseguras

La gestión de sesiones es una pieza fundamental de cualquier aplicación web. Por ello, muchos marcos de desarrollo web tienen incorporada la funcionalidad de gestión de sesiones. Estos sistemas han sido examinados por expertos para encontrar y eliminar los problemas. Utilízalos.

Algunas de las propiedades más comunes de una buena gestión de sesiones son

     Se generan identificadores de sesión aleatorios que los atacantes no pueden adivinar

     Las sesiones se invalidan cuando un usuario se desconecta

     Las sesiones se invalidan automáticamente una vez transcurrido un tiempo determinado

     Los identificadores de sesión se cambian después de que el usuario se conecte

     Identificadores de sesión de al menos 128 bits para evitar ataques de fuerza bruta

Los frameworks web como Spring, ASP.NET Core, Rails y Django tienen estas propiedades y deberían utilizarse por sus mayores estándares de seguridad en este caso.

En resumen: No cree su propio sistema de gestión de sesiones desde cero.

Una vez creados los ID de sesión, es necesario protegerlos. Establezca los indicadores Secure y HttpOnly en "true" en las cookies de sesión. Esto asegura que su valor no puede ser recuperado con JavaScript y el navegador sólo enviará la cookie a través de HTTPS, evitando que los atacantes roben la sesión de alguien en tránsito.

Asegure sus sesiones

Consulte nuestros recursos de aprendizaje gratuitos para obtener más información sobre la gestión de sesiones seguras. Aprender a proteger sus sesiones le ayudará a evitar la toma de posesión de cuentas de usuario, el daño a la reputación y la pérdida de ingresos debido a las brechas de seguridad. Proteja sus sesiones y mantenga a sus usuarios seguros.

Aunque "Padding Oracle" suena como un nombre realmente malo para un grupo de rock alternativo, en realidad es una vulnerabilidad que puede ser utilizada por los atacantes para descifrar información sin conocer la clave de cifrado.

En términos de dificultad general para un atacante, ésta está cerca de la cima de la escala. No estamos hablando de un botón mágico de descifrado, sino de un laborioso proceso en el que los hackers pueden examinar los mensajes de error que se les envían en relación con el relleno de las celdas, y utilizarlo para determinar dónde terminan los datos cifrados y dónde empieza el relleno. A continuación, pueden averiguar varios bits dentro del cifrado y, posiblemente, descifrarlo si disponen de tiempo y datos suficientes para examinarlo.

Afortunadamente, hay varios pasos relativamente sencillos que pueden eliminar la capacidad de un atacante de utilizar el oráculo de relleno para descifrar los datos cifrados. En este episodio, aprenderemos:

• Cómo funciona
• Por qué esta vulnerabilidad es tan peligrosa
• Cómo puede poner defensas para evitarlo.

¿Cómo funciona Padding Oracle?

El encadenamiento de bloques de cifrado (CBC) es una forma de crear un cifrado de bloques en el que toda una secuencia de bits de información, como las celdas almacenadas en una base de datos, se cifran utilizando una clave de cifrado que se aplica a toda la cadena de información. Cuando se utiliza el CBC, el cifrado de un solo bloque de texto cifrado dependerá de todos los bloques anteriores. En teoría, esto hace que el cifrado sea extremadamente fuerte, ya que cualquier cosa, incluso la reordenación de los bloques, corromperá los datos.

El problema de los cifrados CBC (y de cualquier cifrado en bloque, en realidad) es que sólo pueden cifrarse utilizando bloques de tamaños exactos. Normalmente, esto se hace en tamaños de 8 o 16 bytes. Entonces, ¿qué ocurre cuando CBC necesita meter 2 bytes de datos en una unidad de texto cifrado de 16 bytes? Utilizará relleno, básicamente caracteres sin sentido, para rellenar los huecos y hacer que la unidad tenga un tamaño adecuado.

La mayoría de los esquemas de relleno son bien conocidos, siendo PKCS#7 uno de los más populares, por lo que los atacantes podrían saber qué tipo de relleno se está utilizando. Por ejemplo, si el CBC necesita rellenar cinco caracteres en un bloque, el PKCS#7 utilizaría el valor del byte 0x05 repetido cinco veces después del texto plano.

Los atacantes utilizan su conocimiento de los esquemas CBC y de relleno para enviar consultas a un servidor anfitrión, también conocido como oráculo. Si tienen acceso a las herramientas adecuadas, pueden forzar al servidor a decirles si el relleno en su consulta es incorrecto. Para ello, pueden hacer un ciclo de cero a 255 para cada byte del cifrado hasta que el servidor les diga que el relleno es correcto. Entonces, pasan a la siguiente unidad y repiten el proceso, registrando dónde empieza el relleno en cada caso.

Esto no les permite descifrar el mensaje o incluso la celda, pero podría permitirles mapear cada eslabón de la cadena en términos de dónde termina el texto plano y dónde comienza el relleno. También pueden utilizar potencialmente los cálculos XOR para averiguar el valor del último byte del texto plano original.

¿Por qué es tan peligroso el "Padding Oracle"?

La razón por la que un pirata informático se esfuerza tanto en romper la encriptación es por el potencial pago. Pocas personas cifran cosas que no son valiosas. El peligro para la organización anfitriona depende de los datos comprometidos. Eso podría incluir cosas como contraseñas, cuentas de usuario, información financiera, números de tarjetas de crédito, registros de pacientes, comunicaciones sensibles, o cualquier número de piezas de información altamente codiciadas y valiosas.

El uso del oráculo de relleno también podría ser la puerta de entrada a ataques posteriores. Si un atacante puede utilizar el oráculo de relleno para robar contraseñas, por ejemplo, entonces elevar sus privilegios y penetrar más profundamente en una red es una tarea secundaria fácil.

Todo el mundo piensa en la encriptación como la última defensa contra el espionaje o el compromiso. Sin embargo, las idas y venidas entre la ciencia del cifrado y los que quieren descifrarlo se suceden desde hace siglos. El oráculo de relleno es sólo un método que da ventaja a los atacantes.

Dando un duro golpe a los ataques de Oracle Padding

Afortunadamente, hay bastantes maneras de evitar el oráculo de relleno. Una de las mejores es utilizar un modo de operaciones de cifrado más potente, como el modo Galois/Contador (GCM) o el modo Offset Codebook (OCB). Se diferencia del CBC en que utiliza un tamaño de bloque de cifrado de 128 bits. También utiliza un contador para cada bloque de datos, y luego utiliza ese número para crear el texto cifrado. En otras palabras, no es susceptible de ataques de oráculo de relleno.

Implementar buenos controles de gestión de errores también puede perjudicar gravemente las posibilidades de éxito de un atacante. Dado que los ataques de oráculo de relleno se basan en la fuga de información, devuelva mensajes de error genéricos en lugar de errores de relleno específicos en caso de fallo de cifrado/descifrado.

También se puede implementar el Código de Autenticación de Mensajes (MAC). Los valores MAC protegen la integridad de los datos así como su autenticidad, permitiendo a los verificadores detectar cualquier cambio en el contenido del mensaje utilizando una clave secreta.

Por último, todos los ataques de oráculo de relleno requieren consultas repetidas. Puede haber más de 200 peticiones para averiguar el esquema de relleno en una sola celda, multiplicado por el número de unidades de información que se protegen en la cadena. Si se restringe el número de solicitudes que llegan desde la misma fuente, se puede acabar con los ataques de oráculo de relleno negando al atacante el acceso antes de que pueda comenzar realmente su intento.

Estudio adicional sobre el oráculo de relleno

Cualquier método por el que un atacante pueda descifrar información sensible puede convertirse en una auténtica pesadilla. Pero, esperamos que hayas aprendido bastantes buenos métodos para evitar que eso ocurra en primer lugar.

Para más información, puede consultar la definición y la lista de comprobación de la OWASP en padding oracle. 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 a la altura de la tarea de frustrar los ataques de oráculo de relleno ahora mismo? Pruébalo en la plataforma Secure Code Warrior :

La gran mayoría de los sistemas informáticos utilizan el Protocolo Ligero de Acceso a Directorios (LDAP). Se utiliza para mantener servicios de información de directorio distribuidos a través de cualquier red de Protocolo de Internet (IP). Así que, básicamente, funciona como una forma de mantener un seguimiento de los usuarios.

Las aplicaciones suelen utilizar LDAP como fuente de autenticación para ver si un usuario tiene permiso para realizar diversas acciones, especialmente en lo que respecta a su función definida dentro de una organización. Por ejemplo, es posible que sólo los empleados de contabilidad puedan utilizar el software de contabilidad de la empresa. Las aplicaciones suelen estar programadas para comprobar una tabla LDAP para asegurarse de que los usuarios están actuando dentro de sus permisos establecidos.

Pueden surgir problemas cuando usuarios maliciosos pueden manipular una consulta LDAP. Hacer esto puede engañar al servidor receptor para que ejecute consultas no válidas que normalmente no estarían permitidas, o incluso conceder acceso de alto nivel o de administrador a usuarios no válidos o de baja seguridad sin contraseña.  

Las inyecciones LDAP pueden ser complicadas, pero en este episodio aprenderemos:

• Cómo funcionan
• Por qué son tan peligrosos
• Cómo puede poner defensas para detenerlos.

¿Cómo utilizan los atacantes la inyección LDAP?

Una de las razones por las que los ataques basados en LDAP han seguido siendo populares durante años es el hecho de que casi todos los sistemas informáticos lo utilizan. LDAP es de código abierto y funciona extremadamente bien, por lo que no se han creado muchas alternativas.

En esencia, LDAP es una base de datos que rastrea a los usuarios válidos dentro de un sistema informático o una red basada en IP. Puede permitir a los usuarios compartir información sobre sistemas, redes, servidores, aplicaciones e incluso otros usuarios de la misma red.

La información es almacenada por LDAP en el equivalente a una línea o registro de la base de datos que se llama nombre distinguido, que a menudo se abrevia como DN. Cada DN es único. A modo de ejemplo, este es el aspecto de un DN para un usuario que trabaja en la oficina de contabilidad de Chicago de una gran empresa.

cn=James Smith, ou=Cuentas Corporativas, dc=Chicago, do=Parkview  

Para garantizar que cada DN es único, se pueden añadir varios códigos al registro, como "+", "/", "=" y algunos otros. También se pueden insertar espacios antes o después de un registro para garantizar que, aunque haya dos James Smith que trabajen en Cuentas Corporativas en la oficina de Chicago Parkview, cada uno de ellos tenga un DN individual.

Las aplicaciones generalmente utilizan LDAP para permitir a los usuarios enviar consultas sobre DNs específicos, como, por ejemplo, cuando se intenta localizar al contacto correcto en el departamento de nóminas para hablar sobre un error en su cheque. Las inyecciones LDAP pueden ocurrir cuando no hay validación de los parámetros proporcionados por el usuario en las consultas de búsqueda. En ese caso, los hackers pueden manipular las búsquedas benignas para saltarse los mecanismos de autenticación o ejecutar consultas arbitrarias adicionales. Esto puede engañar al servidor para que muestre resultados que no deberían estar permitidos, como contraseñas de usuarios, o incluso hacer que una aplicación conceda acceso a áreas de alta seguridad dentro de la red, con o sin una contraseña válida.

¿Por qué son tan peligrosas las inyecciones LDAP?

El mayor peligro de las inyecciones LDAP es probablemente la proliferación del protocolo en la mayoría de las redes informáticas IP de todo el mundo. Es un trampolín fácil para los hackers que buscan robar información o elevar sus privilegios en una red. Ningún hacker entrenado dejará de comprobar si las inyecciones LDAP son posibles, por lo que los equipos de seguridad deben asegurarse de que esos agujeros estén siempre cerrados.

En concreto, bastantes aplicaciones están programadas para ayudar a los usuarios válidos a encontrar información limitada sobre usuarios y grupos dentro de una organización, o cualquier otra información contenida en los DNs. Por ejemplo, una aplicación podría permitir a alguien utilizar LDAP para buscar la información de contacto de los contables de la empresa que trabajan en Chicago, lo que devolvería a nuestro amigo James Smith del ejemplo anterior. Dependiendo de los permisos, este es probablemente un uso perfectamente válido de una consulta LDAP.

El peligro viene cuando un usuario malintencionado puede añadir parámetros sin filtrar la consulta, cambiando la naturaleza de la búsqueda y engañando al servidor para que proporcione información que normalmente no debería darse. Por ejemplo, añadiendo una cadena user=*, los atacantes podrían obtener información sobre cada uno de los usuarios de toda una organización, algo que probablemente nunca debería permitirse.

En el caso de las aplicaciones que utilizan LDAP para la autenticación, el problema puede ser aún peor. Los atacantes pueden utilizar, por ejemplo, la cadena (&) al final de una consulta LDAP para engañar al servidor haciéndole creer que el argumento es verdadero. Si una aplicación utiliza LDAP para validar una contraseña, forzar un argumento True a través de una inyección LDAP podría permitir a un usuario no autorizado iniciar sesión en la red como administrador, incluso sin una contraseña.

Cómo hacer que la inyección de LDAP sea un L-DON'T en su red

Una de las mejores formas de evitar las inyecciones LDAP es implementar algo como LINQtoAD u otros marcos diseñados específicamente para resistirlas. Esto puede no ser posible si una red ya tiene aplicaciones que aprovechan las consultas LDAP. Sin embargo, incluso en ese caso, sigue siendo una buena idea que cada nueva aplicación utilice marcos resistentes a las inyecciones en adelante.

Las aplicaciones existentes que utilizan LDAP también pueden ser reforzadas contra las inyecciones mediante el uso de la validación de la lista blanca y el saneamiento de la entrada. Siempre que sea posible, restrinja la entrada del usuario a un conjunto limitado de valores de confianza. De lo contrario, la entrada del usuario que forma parte de una consulta LDAP debe ser saneada primero, y no olvides incluir los parámetros GET y POST, las cookies y las cabeceras HTTP, ya que también pueden actuar como vectores de ataque. No escribas tus propias funciones para llevar a cabo la sanitización de la entrada; utiliza en su lugar una biblioteca de terceros de confianza centrada en la seguridad o las APIs integradas en el marco de trabajo.

Más allá de las correcciones específicas, también pueden ayudar las buenas prácticas informáticas, como asignar a las aplicaciones de consulta LDAP el menor privilegio necesario en una red. De esta manera, si lo peor ocurriera y una inyección LDAP lograra pasar, el daño sería mitigado.

Más información sobre las inyecciones LDAP

Para más información, puedes echar un vistazo al artículo de OWASP sobre inyecciones LDAP, o a la hoja de trucos para la prevención de inyecciones. 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 .