Actualización del método de solicitud y el filtrado de tipo de contenido para la protección contra CSRF
La falsificación de solicitud entre sitios (CSRF) es un ataque basado en la Web que envía solicitudes falsificadas en nombre de una víctima involuntaria. Si un usuario está autenticado actualmente en un sitio y se le puede engañar para que envíe un comando malintencionado, el atacante puede solicitar una solicitud de cambio de estado con las credenciales de la víctima.
Para obtener más información, consulte los siguientes vínculos:
Una defensa común contra los ataques CSRF es utilizar tokens sincronizados. Sin embargo, ThingWorx utiliza un método alternativo y, en su lugar, direcciona todas las solicitudes a través de un filtro de tipo de contenido estricto. Este método es igual de seguro, pero es más adecuado para una implementación sin estado.
Actualización del método de solicitud
Por defecto, el método de solicitud no se puede cambiar mediante los parámetros de solicitud. Si la aplicación se ha desarrollado con estas prácticas, se puede realizar lo siguiente:
• Quite cualquier código que cambie un método GET a un método POST mediante los parámetros de solicitud. Este es el método recomendado de las prácticas recomendadas.
• Defina el valor de Permitir cambio de método de solicitud en la configuración del subsistema de plataforma en verdadero.
 |
Esta no es la práctica recomendada y, si se lleva a cabo, el usuario reconoce que se está exponiendo la implementación/aplicación a la posibilidad de CSRF.
La opción Permitir cambio de método de solicitud está desfasada y se quitará de las versiones futuras de ThingWorx.
|
Filtrado del tipo de contenido
ContentTypeFilter se ha implementado para verificar que el tipo de contenido en la cabecera de la solicitud es application/json, application/xml o text/xml para todos los métodos POST, PUT y DELETE. Si la solicitud es de datos de varias partes/formulario, verificará si hay una cabecera X-XSRF-TOKEN con el valor TWX-XSRF-TOKEN-VALUE. Las solicitudes de estos datos de varias partes/formulario son para la carga del fichero.
• Si se realizan cargas de fichero, el explorador debe implementar el objeto FormData.
 |
FormData no está disponible en los exploradores más antiguos (Internet Explorer 9 y versiones anteriores), de modo que la carga de fichero no funcionará en estos exploradores (incluidas las importaciones de entidad y extensión) cuando se incluya ContentTypeFilter.
|
|
|
La opción Filter Content-Type se puede desactivar en el subsistema de plataforma, pero al hacerlo, el usuario reconoce que se está exponiendo la implementación/aplicación a la posibilidad de CSRF.
La opción Filter Content-Type está desfasada y se quitará de las versiones futuras de ThingWorx. Una vez quitada, un administrador ya no podrá desactivar Filter Content-Type.
|
Prácticas recomendadas para la protección contra CSRF
Utilice las siguientes instrucciones para conservar la protección contra CSRF:
• Al desarrollar nuevas aplicaciones, todos los mashups integrados en Composer son seguros. Si se utiliza una interfaz de usuario personalizada que tiene acceso a ThingWorx a través de la API de REST, asegúrese de no incluir ninguna solicitud que requiera un cambio de método.
• Al desarrollar nuevas extensiones Java, asegúrese de que todos los servicios nuevos se expongan a través del marco de anotación de servicios de ThingWorx. Este marco es responsable de identificar, asignar y distribuir todas las solicitudes entrantes a una implementación de un servicio. Todos los servicios que se crean y exponen mediante anotaciones de servicio de ThingWorx estarán protegidos contra CSRF.
• En el caso raro de que un nuevo servicio deba omitir el marco de anotación de ThingWorx, asegúrese de que el servicio solo reaccione a los métodos GET, POST, PUT o DELETE.
Vínculos relacionados