Joven hacker sonriendo

Hackeamos su software

cero falsos positivos

Inteligencia experta + Tecnología especializada
DXST - SAST - IAST - SCA - DevSecOps
Caja blanca - Caja gris - Caja negra
Atacando Aplicaciones Web, APIs, Apps Móviles,
Cliente Servidor, Servidores, Redes, Dispositivos IoT
IoT SCI: Sistemas de Control Industrial

Ejecutar aplicaciones con el mínimo privilegio

Nuestros ethical hackers explican cómo evitar vulnerabilidades de seguridad mediante la programación segura en C Sharp al aplicar el principio de mínimo privilegio. Los privilegios en las aplicaciones deben otorgarse la menor cantidad de tiempo a la menor cantidad de código.

Necesidad

Ejecutar las aplicaciones con el principio de mínimo privilegio C#.

Contexto

A continuación se describen las circunstancias bajo las cuales la siguiente solución tiene sentido:

  1. Se está desarrollando una aplicación en C#.

  2. La organización debe generar un modelo de amenazas para el sistema, donde se identifiquen las posibles amenazas.[1]

  3. Se desean aplicar los principios de mínimo privilegio.[2]

Solución

  1. Cuando se diseña, construye o despliega una aplicación, se debe asumir que la aplicación va a ser atacada. Con frecuencia, los ataques a las aplicaciones son lanzados usando código fuente que utilizan los privilegios del usuario que ejecuta el la aplicación. Para controlar esta situación, se usa el principio de mínimo privilegio, en otras palabras, los privilegios se deben otorgar la menor cantidad de tiempo para la menor cantidad de código que sea requerido[3].

  2. La mejor práctica para crear aplicaciones seguras es: comenzar sin permisos y luego agregar los mínimos privilegios que requiera una tarea para poder ejecutarse. El contraste, que es iniciar con todos los privilegios y luego negar los permisos que no se requieren puede llevar a aplicaciones inseguras que son difíciles de probar y mantener.

  3. En el espacio de nombres System.security existen diferentes llamadas para manipular los privilegios con los que cuenta una aplicación a nivel de código.[4] Entre ellos, podemos destacar PermitOnly[5],[6] y Deny. Con Deny podemos restringir el acceso a algún privilegio para las llamadas que se realicen de manera posterior al llamado. PermitOnly es similar a Deny, en cuanto a que permite restringir a nivel de código los llamados que pueden realizarse. La diferencia está en que Deny especifica los permisos que originan un error en el recorrido por la pila, mientras que PermitOnly especifica únicamente los que no lo originan.

  4. Llame a este método para garantizar que el código puede utilizarse para obtener sólo acceso a los recursos especificados. La llamada a PermitOnly es eficaz hasta que el código de llamada vuelve al llamador. Sólo puede haber un método PermitOnly activo en cada marco. Un intento de llamar a PermitOnly cuando hay otro método PermitOnly activo en el marco da como resultado SecurityException. El método PermitOnly de un permiso no concedido se pasará por alto, Dado que ninguna demanda para ese permiso podrá tener éxito. No obstante, si hay código situado en la parte inferior de la pila de llamadas que llame a Demand para ese permiso, se produce una excepción SecurityException cuando el recorrido por la pila alcanza el código que intentó llamar a PermitOnly. Esto es debido a que el código que llamó a PermitOnly no dispone del permiso, aunque haya llamado a PermitOnly para dicho permiso. La pila de llamadas suele representarse de forma decreciente, por lo que los métodos que se encuentran en las posiciones superiores de la pila de llamadas, llaman a métodos de las posiciones inferiores. A continuación ofrecemos un ejemplo de uso:

    ejemplo.cs
    1
    2
    3
    4
    5
    6
    7
    8
    // Dar acceso al clipboard
    Console.WriteLine("Dando acceso a clipboard.");
    clipboardPermission.PermitOnly();
    DemandAllClipboardAccess();
    // Revertir el privilegio
    Console.WriteLine("Revertir el permiso sobre el clipboard.");
    CodeAccessPermission.RevertPermitOnly();
    DemandAllClipboardAccess();
    
  5. El método PermitOnly solo debe usarse para proteger los recursos frente a un acceso accidental por parte del código de plena confianza. No debe usarse para proteger los recursos frente a un uso incorrecto intencionado por parte de código que no es de confianza. Por ejemplo, si el método A emite PermitOnly para un permiso y a continuación se llama al método B, el método B puede invalidar abiertamente PermitOnly emitiendo Assert. El método al que se llama siempre está situado en la parte superior de la pila. Por lo tanto, si el método B intenta obtener acceso a un recurso protegido, el sistema de seguridad iniciará una comprobación de permisos con el puesto del método B que es el llamador inmediato y, a continuación, se desplazará hacia abajo en la pila para confirmar que no haya ningún Deny o PermitOnly situado por debajo en la pila. El método B, que está intentando obtener acceso al recurso, puede detener inmediatamente el recorrido de pila utilizando el método Assert. En ese caso, el PermitOnly que el método A (el método de llamada) colocó en la pila no se detectará nunca.




Haz un comentario

Estado de los servicios - Términos de Uso