Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Encode/obfuscate HTTP parameters

We are currently working on a very simple Webapp, and we would like to "obfuscate" ( what would be the right term? ) or encode somehow the request parameter, so we can reduce the chance an idle user from sending arbitrarily data.

For instance, the url looks like /webapp?user=Oscar&count=3

We would like to have somthing like: /webapp?data=EDZhjgzzkjhGZKJHGZIUYZT and have that value decoded in the server with the real request info.

Before going into implementing something like this ourselves ( and probably doing it wrong ) I would like to know if there is something to do this already?

We have Java on the server and JavaScript on the client.

like image 283
OscarRyz Avatar asked Oct 25 '10 18:10

OscarRyz


People also ask

Can you obfuscate obfuscated code?

Obfuscation means to make something difficult to understand. Programming code is often obfuscated to protect intellectual property or trade secrets, and to prevent an attacker from reverse engineering a proprietary software program. Encrypting some or all of a program's code is one obfuscation method.

Should I obfuscate my code?

It's essential to hide business logic and code to make it harder for attackers to gain access and start debugging and tampering with your app. (They often repackage an application with malicious code.) 3. Code obfuscation can drastically reduce file size, and download times can be reduced drastically as well.

What is API obfuscation?

As malware's APIs provide rich information about malicious behavior, one common anti-analysis strategy is API obfuscation, which removes the metadata of imported APIs from malware's PE header and complicates API name resolution from API callsites.


1 Answers

No, don't do this. If you can build something in your client code to obfuscate the data being transmitted back to the server, then so can a willful hacker. You simply can't trust data being sent to your server, no matter what your official client does. Stick to escaping client data and validating it against a whitelist on the server side. Use SSL, and if you can, put your request parameters in a POST instead of GET.

Expansion edit

Your confusion stems from the goal to block users from tampering with request data, with the need to implementing standard security measures. Standard security measures for web applications involve using a combination of authentication, privilege and session management, audit trails, data validation, and secure communication channels.

Using SSL doesn't prevent the client from tampering with the data, but it does prevent middle-men from seeing or tampering with it. It also instructs well-behaved browsers not to cache sensitive data in the URL history.

It seems you have some sort of simple web application that has no authentication, and passes around request parameters that control it right in the GET, and thus some non-technically savvy people could probably figure out that user=WorkerBee can simply be changed to user=Boss in their browser bar, and thus they can access data they shouldn't see, or do things they shouldn't do. Your desire (or your customer's desire) to obfuscate those parameters is naïve, as it is only going to foil the least-technically savvy person. It is a half-baked measure and the reason you haven't found an existing solution is that it isn't a good approach. You're better off spending time implementing a decent authentication system with an audit trail for good measure (and if this is indeed what you do, mark Gary's answer as correct).

So, to wrap it up:

  1. Security by obfuscation isn't security at all.
  2. You can't trust user data, even if it is obscured. Validate your data.
  3. Using secure communication channels (SSL) helps block other related threats.
  4. You should abandon your approach and do the right thing. The right thing, in your case, probably means adding an authentication mechanism with a privilege system to prevent users from accessing things they aren't privileged enough to see - including things they might try to access by tampering with GET parameters. Gary R's answer, as well as Dave and Will's comment hit this one on the head.
like image 78
Mike Atlas Avatar answered Oct 22 '22 11:10

Mike Atlas