Coders Conquer Security: Share & Learn Series - Inyecciones LDAP
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 .


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.
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de 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 .

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 .

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónJaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de 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 .
Índice
Jaap Karan Singh es un evangelista de la codificación segura, jefe Singh y cofundador de Secure Code Warrior.

Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
Recursos para empezar
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.