[ACCEPTED]-Encode/obfuscate HTTP parameters-http-request-parameters

Accepted answer
Score: 32

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

Expansion edit

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

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

It seems 13 you have some sort of simple web application 12 that has no authentication, and passes around 11 request parameters that control it right 10 in the GET, and thus some non-technically 9 savvy people could probably figure out that 8 user=WorkerBee can simply be changed to user=Boss in their browser 7 bar, and thus they can access data they 6 shouldn't see, or do things they shouldn't 5 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 4 a decent authentication system with an audit 3 trail for good measure (and if this is indeed 2 what you do, mark Gary's answer as correct).

So, to wrap 1 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.
Score: 13

If your goal is to "reduce the chance an 13 idle user from sending arbitrarily data," there's 12 another simpler approach I would try. Make 11 a private encryption key and store it in 10 your application server side. Whenever your 9 application generates a url, create a hash 8 of the url using your private encryption 7 key and put that hash in the query string. Whenever 6 a user requests a page with parameters in 5 the url, recompute the hash and see if it 4 matches. This will give you some certainty 3 that your application computed the url. It 2 will leave your query string parameters 1 readable though. In pseudo-code,

SALT = "so9dnfi3i21nwpsodjf";

function computeUrl(url) {
  return url + "&hash=" + md5(url + SALT );
}

function checkUrl(url) {
  hash = /&hash=(.+)/.match(url);
  oldUrl = url.strip(/&hash=.+/);
  return md5(oldUrl + SALT ) == hash;
}
Score: 7

If you're trying to restrict access to data 17 then use some kind of login mechanism with 16 a cookie providing a Single Sign On authentication 15 key. If the client sends the cookie with 14 the key then they can manipulate the data 13 in accordance with the authorities associated 12 with their account (admin, public user etc). Just 11 look at Spring Security, CAS etc for easy 10 to use implementations of this in Java. The 9 tokens provided in the cookie are usually 8 encrypted with the private key of the issuing 7 server and are typically tamper proof.

Alternatively, if 6 you want your public user (unauthenticated) to 5 be able to post some data to your site, then 4 all bets are off. You must validate on the 3 server side. This means restricting access 2 to certain URIs and making sure that all 1 input is cleaned.

The golden rule here is disallow everything, except stuff you know is safe.

Score: 3

If the goal it to prevent "static" URLs 60 from being manipulated, then you can simply 59 encrypt the parameters, or sign them. It's 58 likely "safe enough" to tack on an MD5 of 57 the URL parameters, along with some salt. The 56 salt can be a random string stored in the 55 session, say.

Then you can just:

http://example.com/service?x=123&y=Bob&sig=ABCD1324

This technique 54 exposes the data (i.e. they can "see" that 53 xyz=123), but they can not change the data.

There's 52 is an advantage of "encryption" (and I use 51 that term loosely). This is where you encrypt 50 the entire parameter section of the URL.

Here 49 you can do something like:

http://example.com/service?data=ABC1235ABC

The nice thing 48 about using encryption is two fold.

One it 47 protects the data (they user can never see 46 that xyz=123, for example).

The other feature 45 tho is that it's extensible:

http://example.com/service?data=ABC1235ABC&newparm=123&otherparm=abc

Here, you can 44 decode the original payload, and do a (safe) merge 43 with the new data.

So, requests can ADD data 42 to the request, just not change EXISTING 41 data.

You can do the same via the signing 40 technique, you would just need consolidate 39 the entire request in to a single "blob", and 38 that blob is implicitly signed. That's "effectively" encrypted, just 37 a weak encryption.

Obviously you don't want 36 to do ANY of this on the client. There's 35 no point. If you can do it, "they" can do 34 it and you can't tell the difference, so 33 you may as well not do it at all -- unless 32 you want to "encrypt" data over a normal 31 HTTP port (vs TLS, but then folks will wisely 30 wonder "why bother").

For Java, all this 29 work goes in a Filter, that's the way I 28 did it. The back end is isolated from this.

If 27 you wish, you can make the back end completely 26 isolated from this with an outbound filter 25 that handles the URL encryption/signing 24 on the way out.

That's also what I did.

The 23 down side is that it's very involved to 22 get it right and performant. You need a 21 light weight HTML parser to pull out the 20 URLs (I wrote a streaming parser to do it 19 on the fly so it didn't copy the entire 18 page in to RAM).

The bright side is all of 17 the content side "just works", as they don't 16 know anything about it.

There's also some 15 special handling when dealing with Javascript 14 (as your filter won't easily "know" where 13 there's a URL to encrypt). I resolved this 12 by requiring urls to be signed to be specific 11 "var signedURL='....'", so I can find those 10 easily in the output. Not as crushing a 9 burden on designers as you might think.

The 8 other bright side of the filter is that 7 you can disable it. If you have some "odd 6 behavior" happening, simply turn it off. If 5 the behavior continues, you've found a bug 4 related to encryption. It also let developers 3 work in plain text and leave the encryption 2 for integration testing.

Pain to do, but 1 it's nice overall in the end.

Score: 1

You can encode data using base64 or something 2 similar. I would encode the arguments inself 1 in JSON to serialize them.

Score: 1

Something like jCryption ?

http://www.jcryption.org/examples/

0

More Related questions