【问题标题】:GWT RPC XSRF protectionGWT RPC XSRF 保护
【发布时间】:2014-01-04 12:00:29
【问题描述】:

添加 GWT RPC XSRF 保护后,RPC 调用应该有什么不同?

我遵循了这篇文章中提到的更改(GWT (2.4.0) + XSRF 和 https://developers.google.com/web-toolkit/doc/latest/DevGuideSecurityRpcXsrf)并让 GWT RPC XSRF 工作,我看到我的 RPC 调用包含在“com.google.gwt.user.client.rpc.XsrfToken”中",但是我仍然可以在 Fiddler 中拦截请求并更改请求以获取其他内容,我认为经过此保护后,我将无法做到这一点?

我可以在 Fidder 的原始请求中更改 getFirstURL 以获取另一个有效参数,例如“getSecondURL”

http://127.0.0.1:8888/myapp/|AC7025AD520A4366B89A555020174220|com.google.gwt.user.client.rpc.XsrfToken/4254043109|EC4AE16148312F61EB4C4DA365F2F4B2|com.myapp.service.MyService|getFirstURL

【问题讨论】:

    标签: gwt rpc csrf protection


    【解决方案1】:

    您描述的不是 XSRF,而是 MITM。为了防止 MITM,必须使用 HTTPS(或签署请求,但在浏览器中这是不切实际的,如果可能的话)。

    为了简化,XSRF 是关于攻击者站点向受害者站点伪造一个跨站点请求(因此得名),并利用现有的 cookie(或其他)来验证用户,从而获得对其的访问权限个人数据和/或代表他进行更改。为了缓解这种情况,服务器验证每个请求都使用用户会话和与会话关联的令牌,但这是请求有效负载的一部分(cookies由浏览器自动添加所以你不需要知道它,发出请求的一方必须知道令牌,而攻击者可能不知道有效的令牌)。

    【讨论】:

    • 谢谢汤姆,这有帮助!但是,如何在原始 RPC 请求中模拟 XSRF 攻击,以及如何测试 GWT RPC XSRF 修复是否有效,需要一种模拟的方法,有什么想法吗?
    猜你喜欢
    • 2011-09-09
    • 2013-07-09
    • 1970-01-01
    • 1970-01-01
    • 2023-03-11
    • 1970-01-01
    • 2020-12-23
    • 2018-02-18
    • 2014-04-23
    相关资源
    最近更新 更多