Metodologías de prueba de seguridad API

4

He estado encontrando cada vez más clientes que necesitan sus puntos finales de API (generalmente REST) analizados para detectar vulnerabilidades y quería llegar para ver si alguien tiene algunas recomendaciones más allá de lo que he estado haciendo.

Estoy muy familiarizado con la hoja de trucos de seguridad REST de OWASP y he creado una serie de API por lo que sé que debo buscar métodos HTTP, CSRF, divulgación de datos confidenciales, validación de entradas, configuraciones SSL, etc., pero me falta. ¿cualquier cosa? ¿Qué técnicas están haciendo todos para ir más allá y encontrar una vulnerabilidad / explotación de API? ¿Alguna herramienta recomendada que haga el trabajo mejor que un buen proxy y rizo de intercepción?

    
pregunta jmbmxer 05.02.2014 - 23:34
fuente

2 respuestas

2

Mi cliente RESTful favorito es httpie (de fuentes de Python). Obténgalo fácilmente a través de easy_install httpie o pip install httpie . Hay algunos clientes / depuradores REST como complementos de Firefox (busque en addons.mozilla.org).

Mientras estoy en una determinada empresa, recuerdo haber usado una función de WebInspect llamada "parámetros personalizados" en los servicios web RESTful, como la demostración REST-WS en Maven Security Web Security Dojo de la máquina virtual o el uso de JAX-RS por parte del Proyecto OWASP GoatDroid. Si también tiene acceso al producto Fortify SecurityScope, puede usarlo para crear automáticamente un WADL que a su vez puede ser consumido por WebInspect RT. Cuando se prueban aplicaciones grandes (por ejemplo, más de dos millones de líneas de código), esto puede ser especialmente útil: la experiencia de voz aquí.

Cuando mira el informe SecToolMarket , la mayoría de las herramientas que tienen menos de 9 vectores de entrada no pueden manejar muy bien los Servicios web RESTful, e incluso la los mejores (Burp Suite Professional, NTOSpider, IBM Appscan, etc.) no tienen una ruta clara para probar estas interfaces / API. A menudo, esta es la razón por la que querría usar una herramienta como httpie (o curl) a través de ellos como un proxy de intercepción, junto con la documentación de API adecuada (probablemente de preferencia en formato WADL).

    
respondido por el atdre 20.02.2014 - 13:53
fuente
1

Te estás perdiendo una cosa importante:

capacitar a los usuarios finales / información sobre seguridad de datos

Phishing y amp; La ingeniería social es su mayor factor de riesgo en cualquier implementación

    
respondido por el dprogramz 05.02.2014 - 23:44
fuente

Lea otras preguntas en las etiquetas