¿Ejemplos de “Autoprotección de aplicaciones en tiempo de ejecución” (RASP) en acción?

5

Me está costando entender qué es realmente la "Autoprotección de aplicaciones en tiempo de ejecución" (RASP), aunque lo veo mencionado en la prensa. La mejor descripción que he visto de los posibles beneficios, junto con algunas limitaciones, se encuentra en este artículo ¿Es la autoprotección de la aplicación en tiempo de ejecución un acceso directo para proteger el software?

Pero eso todavía no da ejemplos prácticos.

¿Hay algún software de código abierto que haga esto? ¿Cualquier framework que lo proporcione? ¿Sería un ejemplo, como protección de falsificación de solicitudes cruzadas en Django

    
pregunta nealmcb 11.04.2015 - 17:06
fuente

3 respuestas

3

RASP toma una aplicación ingenua y le permite identificar ataques y bloquearlos. Hay una serie de enfoques diferentes, incluidos los filtros, las cajas de arena y la instrumentación completa. Aquí hay un buen artículo independiente sobre RASP que describe los casos de uso y los enfoques: enlace .

Veamos un ejemplo simple de inyección SQL. Una aplicación ingenua simplemente no tiene defensa y es explotada. Una aplicación que utiliza PreparedStatements es segura contra la inyección, pero no tiene idea de si está siendo atacada o no. Vamos a ver cómo funciona esto con RASP. Estoy describiendo el enfoque de instrumentación de Contrast aquí.

Primero, el RASP se instala en la aplicación. En este caso, basta con agregar el agente RASP al entorno. Cuando se carga el código, el RASP utiliza una instrumentación binaria dinámica para agregar nuevos sensores de seguridad y capacidad de análisis a la aplicación. Este proceso es muy similar al funcionamiento de NewRelic o AppDynamics para instrumentar una aplicación para el rendimiento.

Cuando el ataque llega a la aplicación, RASP usa datos de la solicitud, el usuario, la sesión y cualquier otra información contextual. Los datos de solicitud del atacante se rastrean a través de la aplicación. Si parece un ataque, pero nunca llega a una consulta SQL, se informa como una sonda. Esta es una gran diferencia de lo que puede hacer un WAF, ya que los WAF no pueden ver lo que sucede dentro de la aplicación y deben realizar un bloqueo excesivo.

Si el ataque realmente llega a una consulta SQL y modifica el significado de esa consulta, solo entonces RASP bloquea el ataque. Básicamente, esto se aplica a la definición de Inyección de SQL, ya que solo se bloquean los ataques que modifican con éxito el significado de las consultas de SQL. Esta es la razón por la que la implementación de RASP se puede implementar sin mucha configuración o capacitación.

En última instancia, el usuario obtiene visibilidad de quién está atacando sus aplicaciones, de dónde provienen los ataques, las técnicas que se utilizan, la línea exacta de código a la que se dirige y la consulta SQL completa que contiene el ataque. La cantidad de ataques viables es solo una pequeña fracción de las sondas generales que nunca alcanzan una vulnerabilidad coincidente. Por lo tanto, los resultados son bastante diferentes de lo que puede proporcionar un WAF.

El proceso es aproximadamente el mismo para otras vulnerabilidades. Aunque, RASP puede agregar protecciones específicas para las vulnerabilidades conocidas en bibliotecas y componentes. RASP también puede agregar el registro de seguridad u otras características de seguridad a las aplicaciones.

    
respondido por el planetlevel 05.04.2017 - 18:42
fuente
3

permítame darle una breve respuesta para comenzar una discusión, potencialmente con un sesgo, de alguien que trabaja y que trabaja para una empresa que vende RASP. He visto que nadie ha respondido por un tiempo.

Entendemos a RASP como algo que se convierte en parte del binario de la aplicación. Al usar el escaneo de códigos, desarrolla una aplicación segura, pero para mantenerla segura debe endurecer la aplicación contra ataques estáticos y dinámicos como ingeniería inversa, parches, descompilación, depuración, swizzling, enganches API, levantamiento de claves criptográficas, etc. Vea las contramedidas de los diez principales riesgos móviles de OWASP, por ejemplo.

Algunas de las contramedidas detectan parches a través de la suma de comprobación, p. ej. y luego podría conocer ciertas técnicas para ofuscar el flujo de control, evitar cadenas literales en la aplicación, detectar swizzling, depuración o enganches API, etc. Pero podría haber más técnicas desconocidas en la implementación de productos RASP como la reparación de códigos (para el código que se ha revisado) y acciones personalizadas. Una vez que la aplicación entienda que ha sido manipulada con RASP, debería darle maneras de comportarse de manera inteligente, una acción personalizada. Con inteligencia me refiero a no solo salir o bloquear una aplicación o mostrar un diálogo de que algo no es como se esperaba, sino limitar la funcionalidad, destruir las claves criptográficas o lo que sea una acción personalizada inteligente para una aplicación específica.

Estas contramedidas contra ciertos ataques son parte de la aplicación y la seguridad va a donde sea que vaya la aplicación y no se basa en nada instalado en un dispositivo. Un secreto importante de ciertos productos RASP es cómo la seguridad misma se defiende contra todos estos ataques.

¿Tiene sentido?

    
respondido por el Mirko Brandner 11.05.2015 - 10:24
fuente
1

Hay algo que se llama OWASP AppSensor. Han escrito que su concepto es muy similar al RASP de Gartner, con la diferencia de que Gartner se centra en las "ofertas de los proveedores" y OWASP ha creado un marco que puede permitir la "integración de código profundo".

Parece que el primero puede implementar un comportamiento más específico, pero el concepto es bastante similar.

Otro ejemplo similar en el que puedo pensar es HDIV en Java , aunque no estoy seguro de sus capacidades de tiempo de ejecución.

    
respondido por el wtrmeln 02.09.2015 - 12:38
fuente

Lea otras preguntas en las etiquetas