更新 CSRF 保护的请求方法和内容类型筛选
跨站点请求伪造 (CSRF) 是一种基于 web 的攻击，代表不知情的受害者提交伪造的请求。如果用户当前通过了对站点的身份验证，并且可能被诱骗提交恶意命令，则攻击者可以使用受害者的凭据来请求状态更改。
有关详细信息，请参阅以下链接：
针对 CSRF 攻击的常见防御措施是使用同步令牌。但是，ThingWorx 使用的是另一种方法，通过一个严格的内容类型筛选器路由所有请求。这种方法同样安全，而且更适合于无状态实现。
更新请求方法
默认情况下，请求参数不能更改请求方法。如果您的应用程序是使用这些实践开发的，则可以：
• 通过请求参数，删除任何将 GET 方法更改为 POST 方法的代码。这是推荐的最佳方法。
 |
这不是建议的最佳方法，如果这样做，表明您确认您可能正在将您的实现/应用程序暴露给 CSRF。
“允许请求方法切换”选项已被弃用，并将在未来 ThingWorx 版本中移除。
|
内容类型筛选
对于所有 POST、PUT 和 DELETE 方法，已经实现 ContentTypeFilter 以验证请求标题中的内容类型是应用程序/json、应用程序/xml 还是文本/xml。如果请求是多部件/表单数据，将检查一个值为 TWX-XSRF-TOKEN-VALUE 的 X-XSRF-TOKEN 标题。这个多部分/表单数据的请求用于文件上载。
• 如果正在执行文件上载，您的浏览器必须实现 FormData 对象。
 |
FormData 在旧版浏览器 (Internet Explorer 9 及以下版本) 中不可用，所以当包含 ContentTypeFilter 时，文件上载在这些浏览器 (包括实体和扩展名导入) 中将不起作用。
|
|
|
Filter Content-Type 选项已被弃用，并将在未来 ThingWorx 版本中移除。
|
CSRF 保护的最佳做法
使用以下指南来维护 CSRF 保护：
• 开发新应用程序时，Composer 中内置的所有混搭均是安全的。如果您正在使用自定义用户界面通过 REST API 访问 ThingWorx，请确保不包含任何需要方法切换的请求。
• 开发新的 Java 扩展时，请确保所有新服务均通过 ThingWorx 服务注释框架公开。此框架负责标识、映射和将所有传入请求路由到服务的实现。所有使用 ThingWorx 服务注释创建和公开的服务均将受到 CSRF 保护。
• 在极少数情况下，新服务必须绕过 ThingWorx 注释框架，请确保该服务仅对 GET、POST、PUT 或 DELETE 方法作出响应。
相关链接