Enumeración de parámetros del método API a través del navegador web

Question

Enumeración de parámetros del método API a través del navegador web

#1 de Neil Smithline (1 votos)
#2 de WaltHouser (0 votos)
#3 de Bryan 'BJ' Hoffpauir Jr. (0 votos)

1

Estoy obligado por contrato a evitar la enumeración de los parámetros de un método API pero no puedo lograrlo.

Cuando envío una solicitud en blanco al servidor de API en un navegador web, el servidor responde con los parámetros exactos que requiere ese método. Esto hace que el trabajo de un atacante sea mucho más sencillo porque saben exactamente qué datos enviar a ese método API.

Por ejemplo, si entro enlace en un navegador web, obtengo una respuesta, similar a la siguiente, que contiene los parámetros exactos utilizados por ese método:

{"initObj": {"Locale":
   {"LocaleLanguage":"","LocaleCountry":"","LocaleDevice":"","LocaleUserState":"PossibleValue1 || PossibleValue2"},
   ”Another Parameter":""”,"AnotherParameter”:”PossibleValue1 || PossibleValue2"},
   "username": "", "password": ""}

Esta información le dice al atacante exactamente qué datos enviar al método API, lo que hace que el ataque sea mucho más fácil.

Lo que debo hacer es evitar que el servidor responda con esta información cuando se envíe una solicitud en blanco.

Por supuesto, estos parámetros siempre se envían a través de POST, no GET como cuando envío la URL en el navegador web. Por lo tanto, una solución es prevenir las solicitudes GET.

¿Cómo puedo evitar estas respuestas desde el servidor sin depender de este trabajo?

appsec attack-prevention rest api enumeration

pregunta user94044 09.12.2015 - 11:52

fuente

3 respuestas

Lea otras preguntas en las etiquetas appsec attack-prevention rest api enumeration

Clave SSH vs Contraseña compleja con Fail2Ban y autenticación de dos factores ¿Cómo puedo ocultar mi clave de acceso y secreto de AWS S3 en C ++? [duplicar]

score 1 · Answer 1

¡Se trata de seguridad por el camino equivocado!

El intento de proteger algo ocultando información sobre él se denomina seguridad por oscuridad . Se considera una mala práctica y no debe utilizarse. La filosofía general es que es difícil mantener las cosas como un secreto API. Un determinado atacante diseñará hacia atrás la aplicación del cliente, observará el tráfico de la red, probará el servidor, etc. para descubrir la firma de una API.

En su lugar, implemente una API que sea segura incluso en el caso de que se la conozca públicamente. Confíe en los secretos (como contraseñas y claves de autenticación ) y otras mecanismos de control de acceso para garantizar la seguridad de su API. OWASP es un buen lugar para comenzar a leer sobre seguridad.

score 0 · Answer 2

Por el CERT Oracle Coding Standard para Java ," la reflexión con los permisos del código de confianza es una de las brechas de seguridad "definitivas" en Java. Nunca permitir que un código que no es de confianza invoque cualquier API que finalmente utilice la reflexión para realizar sus acciones ". MSC53-J. Diseñe cuidadosamente las interfaces antes de lanzarlas

Otro recurso útil para asegurar las API sería Regla 10. API de subprocesos (THI)

score 0 · Answer 3

Fundamentalmente, Neil tiene un gran punto, aunque creo que específicamente el problema en el que debes enfocarte es:

Parece que el punto final de la API está abierto y no implementa ningún sistema de autenticación ni controles de acceso en ninguna capa.

Guía de control de acceso de OWASP & Guía de autenticación cubre esto con gran detalle.

Para abordar el requisito comercial que especificó utilizando un enfoque de defensa en profundidad , debe (al menos) implementar las siguientes capas de seguridad)

[Network Layer] -- Network ACLs (at Firewall / Router) specifying the IP addresses
   or network segments that are allowed to access the systems hosting your API

[Application Layer] -- Authentication Logic - before any request is processed by
   your API, you should require that the submitter present an authentication key
   or token to validate that they have been trusted to interact with your API.  
   Failure of a client to present a valid key should cause your API to return 
   an HTTP Status Code 404.

[Application Layer] -- Business Logic - After completing your authentication
  logic you should inspect the parameters and return an error code 5XX 
  along with a message indicating that parameters are missing.

Nota: de su descripción, parece que está utilizando IIS para alojar sus puntos finales de API. No estoy tan familiarizado con la plataforma, pero lo que me estás describiendo me suena como un comportamiento predeterminado que se está ejecutando porque:

No ha anulado la lógica de respuesta .Net predeterminada con código personalizado que implementa algo como las sugerencias anteriores.
No ha configurado la configuración predeterminada del servidor web de IIS para evitar esta enumeración de parámetros.

Aunque abordar cualquiera de los puntos anteriores debe satisfacer sus requisitos, sugeriría que # 1 le dé más control sobre exactamente el comportamiento que se ejecuta y un sistema de seguridad más sólido. Aquí hay algunos enlaces de referencia adicionales que pueden ayudarlo en cualquiera de los dos enfoques de la plataforma IIS: