我们有一个巨大的GWT应用程序,它从未经过安全性测试,现在我们想用我们在GWT网站上找到的一些“最佳实践”来修补它。
其中一个补丁与RPC令牌相关,所以我们应用了代码,以便应用程序中的任何调用都会对令牌进行起诉,所有“看起来”都很好,但现在我希望至少针对基本攻击进行测试,以确保“某种东西在某种程度上正常工作”。
问题是请求有效负载似乎是以某种自定义方式序列化的,并且没有rpc令牌的证据。
有一个简单的方法来测试这个漏洞吗?我正在考虑用postman伪造一个请求,或者在另一个服务器中创建一个表单来进行调用,但是解决这些解决方案的基本方法似乎行不通。
一旦调用了setToken
,我就设法用一种非常肮脏的方法来测试该功能。我已经添加了一个新的令牌字符串(直接在代码中),异常被成功抛出,所以这件事在某种程度上起作用了。
有一种方法在野外测试它应该是值得赞赏的。
发布于 2019-09-26 01:48:29
我已经和邮递员试过了。需要注意的是,需要注意的是setting所有头,特别是必须设置为:text/x-gwt-rpc; charset=UTF-8
的Content-Type
。我从最近的一个请求中获取了一个有效负载,然后我对postman进行了同样的请求,这个服务器应答带有合法的peyload。然后,我在有效负载请求中更改了rpc令牌(在加载应用程序时,我从XSRF请求中获取了它)。该服务使用XSRF令牌错误进行应答。
因此,如果没有适当的令牌,就无法在应用程序上执行任何请求。
值得注意的是,xsrf令牌只是md5 of jsessionId,因此另一种测试方法是更改铬控制台中的jsessionID或其md5。
https://security.stackexchange.com/questions/218700
复制相似问题