URL Encryption vs. Encoding

Question

At the moment non/semi sensitive information is sent from one page to another via GET on our web application. Such as user ID or page number requested etc. Sometimes slightly more sensitive information is passed such as account type, user privileges etc.

[EDIT: I may have worded this wrong, I'm not passing sessionID or actual user privileges, just simple NON-sensitive data - I just don't want the user to see the words easily, does not matter if a more technical user can read it as they cannot do any damage and cause security concerns. read the chat with @delnan]

We currently use base64_encode() and base64_decode() just to de-humanise the information so the end user is not concerned.

Is it good practice or common place for a URL GET to be encrypted rather than simply PHP base64_encoded?

Perhaps using something like, this:

$encrypted = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $string, MCRYPT_MODE_CBC, md5(md5($key))));

$decrypted = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($encrypted), MCRYPT_MODE_CBC, md5(md5($key))), "\0");

Is this too much or too power hungry for something as common as the URL GET.

Why would you have to base64-encode user IDs and page numbers? — , Mar 31 '12 at 12:44
Sometimes slightly more sensitive information is passed such as account type, user privileges etc. — hozza, Mar 31 '12 at 12:47
That's an entirely different matter. Encoding user IDs and page numbers if pointless, passing user privileges like this is a security issue. — , Mar 31 '12 at 13:07
Only minor privileges are passed, such as whether or not they can see a calendar at the current time. Anything that would cause a strong security issue is not dept with over GET for obvious reasons. — hozza, Mar 31 '12 at 13:17
Good for you. I still don't see why you'd have to encode anything. If you don't want the user to see it, pass it as POST or put it in a session. If you want to put it in GET and it's not sensitive, don't encode it pointlessly. — , Mar 31 '12 at 13:22
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/2959/discussion-between-hozza-and-delnan) — hozza, Mar 31 '12 at 13:23
@delnan: Passing as POST will hide it from the average user, but that's about it. If it's sensitive, don't pass it to the client, period. :) — netcoder, Mar 31 '12 at 15:39
@netcoder I know. I raised the security issue myself - and it turned out this is not used for security, only to make it nonobvious to the average user. — , Mar 31 '12 at 15:49

score 4 · Answer 1 · answered Mar 31 '12 at 15:52

4

Why are you using GET in the first place? Just POST the sensitive data over HTTPS, and add suitable CSRF protection.

This is assuming that the information is sensitive in the sense that the authorized user and the server may see it, but others (other users and attackers) must not.

If the user isn't allowed to see the information either, then just don't send it in the first place. Keep it on the server; if you need to link it to the user, pass a session ID back and forth (with the usualy precautions and safeguards in place), and store the sensitive information in the session (that is, server-side).

Sending sensitive information to an unauthorized client is sloppy, because it gives the attacker an opportunity for off-line cracking methods.

answered Mar 31 '12 at 15:52

tdammers

52,406
14
106
154

1

The user is allowed to see the information, read the comments/chat on the question and perhaps this will better explain my situation. I however do value parts of your answer. – hozza Mar 31 '12 at 22:11
1

@hozza: in that case, the first paragraph is pretty much your answer. Just POST over HTTPS, and the data will be encrypted at the transport layer (GET over HTTPS will do the same, but the unencrypted data shows up in the browser history and such). – tdammers Apr 01 '12 at 12:26
To my knowledge, I can't use POST with a '' and I cannot use HTTPS at the moment. – hozza Apr 02 '12 at 18:55
@hozza then don't use an anchor, use a form. – Explosion Pills Apr 20 '12 at 06:01

score 0 · Answer 2 · answered Mar 31 '12 at 12:45

0

If you pass just UserID something like Page Number then just URL GET is fine. If you do not need any explicit security on them, it would be a overhead for you.

answered Mar 31 '12 at 12:45

Muneer

260
1
13

score 0 · Answer 3 · answered Apr 01 '12 at 01:14

0

Passing information this way is a hazard waiting to be exploited. You need to think about what someone who understood the traffic could do to the site that is accepting the GET.

You should use POST
If any sensitive data is being passed, it should be encrypted.
You should checksum and sign the package of data so it can't be altered and similar packages can't be constructed.

answered Apr 01 '12 at 01:14

ddyer

4,060
15
18

Thank you, but how can I use POST with standard HTML ''? – hozza Apr 02 '12 at 18:56

URL Encryption vs. Encoding

3 Answers3