当前位置 : 主页 > 大数据 > 区块链 >

在GWT RPC调用中编码请求有效负载

来源:互联网 收集:自由互联 发布时间:2021-06-22
我正在使用GWT来创建我的网络应用程序. 从客户端(浏览器)进行RPC调用时,在inspect元素中,我的Request Payload如下: 7|0|8|https://xxxx.xxxx.in/TestProject/in.TestProject.Main/|87545F2996A876761A0C13CD750EA654|i
我正在使用GWT来创建我的网络应用程序.

从客户端(浏览器)进行RPC调用时,在inspect元素中,我的Request Payload如下:

7|0|8|https://xxxx.xxxx.in/TestProject/in.TestProject.Main/|87545F2996A876761A0C13CD750EA654|in.TestProject.client.CustomerClassService|check_User_Login|java.lang.String/2004016611|in.TestProject.Beans.CustomerBean/3980370781|UserId|Password|1|2|3|4|3|5|5|6|7|8|6|0|0|0|0|0|CustId|0|0|0|0|0|0|0|0|0|

在此请求中,所有详细信息,如用户名,密码和& custid显示在请求有效负载中.

我的问题是,是否可以编码或隐藏请求有效负载中的那些细节?

你正在寻找错误的抽象层次.在有效载荷中编码/“隐藏”这些值有什么意义?无论如何,您在服务器和客户端之间交换的所有内容都可以被截获…除非您使用HTTPS.它确保服务器和客户端之间的安全/加密通信.不要试图“聪明”,只加密部分通信/有效负载,只需使用HTTPS.

But my concern is client itself should not be able to seen which method call we are making, parameter type in the request, parameter values etc. It should be hidden from client.

但是这些参数值是由用户自己输入的,或者是在应用程序中的某个地方硬编码的(用户总是能够看到/解密,因为他的浏览器必须这样做).所以你想要达到的目标是security through obscurity并且永远不是一个好主意.我将注意力集中在保护端点(GWT-RPC服务),验证发送的输入等方面.

您必须记住一件事 – 用户可以访问应用程序客户端部分的源代码(已编译和缩小,但仍然).所以:

>他总是能够弄清楚如何与您的服务器通信,因为您的应用程序必须这样做.
>他可以修改应用程序以发送恶意请求 – 即使您创建了一些编码参数/地址的假设方法.只需在编码完成之前找到一个地方就可以了. Firebug和其他开发人员工具将为您提供极大的帮助.

所以以这种方式“保护”客户端是没有意义的(当然,CSRF,XSS等应该是你的关注点),恶意用户总是会绕过它,因为你必须给他所有的工具来做 – 否则, “普通”用户(或者说他的浏览器)将无法使用您的应用程序.

网友评论