Una exploración reciente de una aplicación web .net detectó una vulnerabilidad de inyección ldap para un campo que se usó para un nombre de usuario asignado a una instancia de una clase personalizada llamada Usuario.
Después de revisar el código, encontré que a la instancia de Usuario se le dio la instancia System.Security.Principal.WindowsPrincipal y, de hecho, envié una solicitud de autenticación para el nombre de usuario suministrado al servidor IIS de la computadora host, que aparece como un evento de inicio de sesión en Seguridad registros
Todavía no he podido obtener una respuesta consistente para la inyección de resultados de consulta de ldap positivos y negativos, pero parece muy posible, y estoy trabajando para obtener otra exploración con los mismos resultados, teniendo algunos problemas , pero aún no han llegado a una pared.
La validación contra una lista blanca evitará que se inyecte la cadena classObject , pero creo que el uso de la cadena User en .net no debería hacerse por esta razón, sin embargo, también me estoy preguntando sobre el espacio de nombres System.Security.Principal.WindowsPrincipal siendo una vulnerabilidad de inyección ldap en sí misma.
Hay formas de evitar esto además de la validación de la lista blanca, pero todavía permiten que el espacio de nombres del sistema exista en un archivo .cs. ¿O deberían las clases de usuario que pretenden ser personalizadas, cambiarse a otra cadena?