API web de ASP.NET y potencial XSS

4

Me pregunto si mi API web ASP.NET tenía una vulnerabilidad XSS ya que mi controlador no tenía un método para manejar la llamada GET predeterminada.

Sin el método GET manejado en el código, una llamada a
/api/mycontroller/?<script>alert('hi');</script> resultaría en:

{"Message":"No HTTP resource was found that matches the request URI
 'http://localhost:8888/api/mycontroller/?'.",
 "MessageDetail":"No action was found on the controller 'MyController' that 
  matches the request."}

Tenga en cuenta que las etiquetas de script están en la fuente JSON, simplemente no se muestran en la página.

Elimine el signo de interrogación, /api/mycontroller/<script>alert('hi');</script> , y obtendrá
"A potentially dangerous Request.Path value was detected from the client (<)." , por lo que ahora una HttpException está protegiendo a los usuarios.

El enrutamiento de la API es simplemente el predeterminado:

.Routes.MapHttpRoute(
    "DefaultApi", 
    "api/{controller}/{id}", 
    new { id = RouteParameter.Optional });

y ahora lo he agregado en un método de acción predeterminado:

[HttpGet]
public HttpResponseMessage Get()
{ 
    // do something. 
}

Sin embargo, se podría pasar por alto poner este método de acción cuando un desarrollador está creando una API, creo.

Me preguntaba, ¿es este un problema XSS explotable?

    
pregunta Boggin 20.12.2013 - 14:00
fuente

1 respuesta

6

Esta condición probablemente no fue una vulnerabilidad de XSS explotable para la mayoría de las aplicaciones. Esto es más probable que sea un filtro de "defensa en profundidad" para evitar que los programadores causen problemas involuntariamente.

XSS se resuelve en una API configurando el tipo de contenido en application/xml o application/json dependiendo del tipo de datos de retorno (y text/plain también se usa comúnmente para evitar XSS). El XSS reflectivo y persistente solo puede ser un problema si la página tiene un tipo de contenido HTML. DOM basado en XSS sigue siendo una preocupación para los servicios web. La Política de seguridad de contenido se puede utilizar para restringir aún más la capacidad de ejecutar JavaScript utilizando Inyección de HTML, y es útil para prevenir XSS basados en DOM.

Cuando se utiliza un navegador moderno, una carga útil XSS no debería ejecutarse en un tipo de contenido no ejecutable. Sin embargo, es una buena idea deshabilitar explícitamente el rastreo de contenido para los navegadores antiguos o no estándar:

X-Content-Type-Options: nosniff
    
respondido por el rook 20.12.2013 - 17:34
fuente

Lea otras preguntas en las etiquetas