Encode request payload in RPC GWT call
I am using GWT to build my web application.
When calling RPC from client (browser) side in validation element, my Request Payload looks like this:
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|
In this request, all data such as username, password and custid are displayed in the request payload.
My question is, is it possible to encode OR hide this data from the request payload?
source to share
You are looking at the wrong level of abstraction. What is the encoding / "cut-off" point of these values โโin the payload? Anything you exchange between server and client can be intercepted anyway ... if you are not using HTTPS . It provides secure / encrypted communication between server and client. Don't try to be smart and only encrypt part of the message / payload, just use HTTPS .
But my concern is that the client itself shouldn't see which method we are calling, the type of the parameter in the request, the parameter values, etc. It must be hidden from the client.
But these parameter values โโwere either entered by the user himself or hard-coded somewhere in the application (which the user can always see / decrypt because his browser has to). So what you are trying to achieve is security through obscurity and is never a good idea. I would focus my attention and efforts on securing endpoints (GWT-RPC services), validating input sent there, etc.
One thing you have to remember is that the user has access to the source code (compiled and minified, but still) on the client side of your application. So:
- He can always figure out how to contact your server, because your application needs to.
- It can modify the application to send malicious requests - even if you've created some hypothetical way to encode parameters / addresses. Just find a spot before the encoding and voila. Firebug and other developer tools will help you with this.
So it doesn't make sense to "protect" the client side in this way (CSRF, XSS, etc. of course), an attacker will always bypass it because you have to give him all the tools to do this - otherwise a "normal" user (or rather, his browser) won't be able to use your application.
source to share