Identificar y prevenir la ejecución de la función "cualquiera" mediante los comandos de última hora

2

El patrón de comando se usa ampliamente para crear aplicaciones robustas y vendibles. Sin embargo, veo una guía en este artículo de MSDN que podría permitirle a la persona que llama invocar un comando de enlace tardío ... permitiendo al llamante llamar a cualquier conjunto, clase y método disponible para el proceso en ejecución:

Figura 7

[Serializable()]
public class LateBoundCommand : ICommand
{
    protected string AssemblyName;
    protected string ClassName;
    protected string MethodName;
    protected object[] Parameters;

    protected LateBoundCommand()
    {
    }

    public LateBoundCommand(string assemblyName, string className, 
                            string methodName)
    {    
        AssemblyName = assemblyName;
        ClassName = className;
        MethodName = methodName;
    }

    // sets all parameter values
    public void SetParameters(params object[] myParameters)
    {
        Parameters = myParameters;
    }

    public virtual void Execute()
    {
        Console.WriteLine("LateBoundCommand.Execute starting");
        Assembly a = Assembly.LoadWithPartialName(AssemblyName);
        Type TargetType = a.GetType(ClassName);
        MethodInfo TargetMethod = TargetType.GetMethod(MethodName);
        TargetMethod.Invoke(null, Parameters);
        Console.WriteLine("LateBoundCommand.Execute complete");
    }

}

Desde que se publicó este artículo en 2004, y el patrón subyacente fue desarrollado en 1995 , debe haber un Mucho software desarrollado de esta manera. Fuera de SDLC, ¿cuál es la forma correcta de proteger la infraestructura de TI del software desarrollado de esta manera?

¿Se puede realizar alguna auditoría específica de .NET o Java para identificar la ejecución tardía del enlace ... atípica del servicio en ejecución?

¿Puedo escanear la MSIL (o equivalente en Java) para este tipo de invocación?

    
pregunta random65537 17.11.2011 - 00:58
fuente

3 respuestas

1

La pregunta parece suponer que la invocación tardía de los métodos es un problema de seguridad. Sin embargo, no creo que sea obvio que este es, de hecho, el caso. En términos generales, la mayoría del uso de la invocación de enlace tardío (también conocida como reflexión) es rutinaria y benigna.

La pregunta no define el modelo de amenaza contra el que intenta defenderse. Si está preocupado por los ataques de inyección de código malintencionado, entonces no veo por qué es relevante la invocación tardía. Una vez que el atacante puede inyectar y provocar la ejecución del código malicioso de su elección, el juego termina, y esto es cierto independientemente de que la plataforma admita la invocación de métodos de última hora o no.

En consecuencia, no me queda claro si hay mucho valor en escanear el código que usa invocación de enlace tardío (también conocida como reflexión).

Ahora, dicho esto, hay, de hecho, algunos tipos de errores de seguridad que pueden surgir del uso incauto de la invocación de métodos / reflexión de última hora. Vea, por ejemplo, la explicación de Fortify sobre reflexión insegura y el artículo de OWASP en inyección de reflexión . Si su compañía está desarrollando un código crítico para la seguridad y hace un uso no trivial de la reflexión, es posible que desee asegurarse de que sus desarrolladores estén conscientes de estas vulnerabilidades para que puedan evitarlas. Estas vulnerabilidades son fáciles de evitar, y me imagino que deberían ser raras si los desarrolladores siguen buenas prácticas de seguridad. Sin embargo, si le preocupa, una buena herramienta de análisis estático de seguridad debería poder detectar muchos de estos tipos de vulnerabilidades relacionadas con la reflexión.

Al menos para Java, otro peligro de reflexión es que la reflexión de Java puede omitir los modificadores de control de acceso de Java. Por ejemplo, puede permitirle leer y escribir private campos en otras clases , algo que normalmente no podrías hacer. Si confiaba en que estos campos fueran realmente privados, entonces esto podría plantear algunos riesgos para su sistema. Consulte, por ejemplo, ¿Cuál es el riesgo de seguridad de la reflexión de objetos? . Estos comentarios se relacionan con la reflexión de Java, sin embargo, tengo la impresión de que preocupaciones similares pueden aplicarse también a .NET . Esto no es un problema de seguridad directo para la mayoría de los sistemas, pero hace que sea más difícil razonar sobre su código (porque viola la encapsulación), lo que puede no ser conveniente si el código es crítico para la seguridad.

    
respondido por el D.W. 18.11.2011 - 05:29
fuente
3

Claro, puede escanear la MSIL para buscar un código que llame a los bits de reflexión, pero realmente no hay mucho que se pueda hacer en tiempo de ejecución a menos que esté monitoreando la pila de llamadas en cada solicitud.

    
respondido por el Steve 17.11.2011 - 01:31
fuente
1

En realidad, esta es solo una de las muchas formas de abrir la puerta a la invocación de un código "inesperado". Las herramientas de análisis estático como FxCop o NDepend pueden ayudar a encontrar algunos problemas potenciales, al igual que las herramientas de prueba de penetración, pero definitivamente no todas. La restricción de los permisos de tiempo de ejecución del código puede ayudar, pero, a menos que esté ejecutando un programa como SDL, probablemente terminará en una batalla con los desarrolladores con la concesión de permisos de tiempo de ejecución. E incluso esto no es suficiente a menos que la seguridad dentro de una aplicación sea razonablemente sólida, lo que presumiblemente no estaría en una aplicación que contenga código como su muestra.

En última instancia, si le preocupa la seguridad, debe esforzarse seriamente en implementarla en todas las etapas de desarrollo y despliegue. Cualquier cosa menos será equivalente a los controles al azar que dejan la puerta abierta a problemas que de otro modo podrían haberse evitado.

    
respondido por el Nicole Calinoiu 17.11.2011 - 15:35
fuente

Lea otras preguntas en las etiquetas