Validación de tipo de contenido en las API REST

Question

Validación de tipo de contenido en las API REST

#1 de CBHacking (4 votos)

5

Estoy tratando de envolver mi cabeza, por eso se recomienda validar el content-type , enviado por un cliente a una API REST.

OWASP declara en su hoja de trucos de seguridad REST : p>

Al enviar o enviar nuevos datos, el cliente especificará el tipo de contenido (por ejemplo, application / xml o application / json) de los datos entrantes. El servidor nunca debe asumir el tipo de contenido; siempre debe verificar que el encabezado Content-Type y el contenido sean del mismo tipo. La falta de un encabezado de tipo de contenido o un encabezado de tipo de contenido inesperado debería hacer que el servidor rechace el contenido con una respuesta 406 No aceptable.

Realmente nunca establecen cómo se puede explotar una validación faltante. Por supuesto, es mejor validar la entrada, por el bien del analizador de datos, pero el encabezado puede ser falsificado por un atacante, ¿no?

¿Por qué se sugiere la validación content-type y cómo podría explotarse una validación faltante?

http rest api header

pregunta SaAtomic 22.03.2017 - 14:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas http rest api header

¿Es un riesgo de seguridad para los usuarios no cerrar sesión en un sitio web? ¿Cómo puedo verificar si una aplicación Mac tiene NX o ASLR habilitado?

score 4 · Accepted Answer

Primero, el atacante no siempre puede falsificar el tipo de contenido. Por ejemplo, si su API REST admite una aplicación web que utiliza cookies para guardar tokens de sesión, un atacante puede intentar usar CORS (XHR de origen cruzado) o enviar formularios HTML para atacar a los usuarios de su servicio cuando la víctima visita la página del atacante . Si realiza una solicitud entre sitios desde el sitio del atacante (que no tiene permiso de CORS para Access-Control-Allow-Header: Content-Type), el atacante no puede establecer el encabezado Content-Type. Sin embargo, si la aplicación simplemente supone que el tipo de contenido es algo que CORS no permite de forma predeterminada (como JSON) y no verifica el encabezado, entonces un atacante puede enviar una solicitud usar uno de los tipos de contenido no preflighted / allowed-default-default-allowed-in-form para que sea aceptado por un analizador JSON (o lo que sea). Por supuesto, lo ideal sería que también tuvieras protecciones anti-CSRF, pero a veces la gente piensa "solo permito JSON y no permito que los sitios de terceros me envíen JSON, así que estoy seguro" cuando en la práctica también permiten otros. tipos de contenido siempre que el cuerpo de la solicitud también sea JSON válido.

Otras veces es importante cuando se hacen cosas como dejar que un usuario cargue archivos (siempre hay algo que hacer con cautela); Si limita los tipos de archivos permitidos, pero no verifica que el tipo de archivo cargado es lo que se supone que debe ser, podría experimentar una variedad de tipos de problemas (dependiendo de lo que haga con los archivos cargados). Si hace cosas diferentes con diferentes tipos de archivos, es posible que deba verificar que el usuario especificó un archivo de uno de los tipos permitidos y que el archivo cargado es válido para ese tipo.