Securing Data Sent Via GET Requests

laserlight

Has anyone read the most recent PHP Builder article, Securing Data Sent Via GET Requests? It appears to contain a typographical error on the second page. A '<' was not converted to '<', leading to code for a for loop getting cut off. Besides that, the code generated by the "single-use script that generates the include file" uses short tags, and in both ob() and deob(), $newIn is not initialised before use in the loop.

However, I think the real problem is that the suggested scheme is snake oil encryption claiming to be secure enough such that it can be used "to take full advantage of the convenience of GET requests, without ever needing to display insecure data in the client browser". From what I see, the basic idea is to generate a PHP script with an array of ten possible random mappings of the ASCII table. One of these mappings is choen based on the return value of microtime(). The key is thus the index of the mapping in the array, and is passed along with the rest of the obfuscated text.

This is then a simple one-one mapping. If mappings are never reused with the same key, it is equivalent to a one time pad. However, with just 10 possible mappings, I daresay an attacker can quite easily have all the possible mappings very easily, after which the security just disappears. A possible solution is to generate a new mapping file, but then one has to be certain that none are in use. Increasing the number of mappings will help, but to really be secure the size of the generated file may be rather large.

Weedpacket

So the server does both encryption and decryption, and passes out encrypted data to the client to be resubmitted as part of a GET request?

....Err ... why?

If you're going to be doing all that (and the only remotely plausible reason I can think of as to why you'd want to is because the GET is to a different domain), why not encrypt it properly?

Note the comments to that article. First:

How is this technique specific GET-requests? I think this technique would fit in a wider variety of applications. To name one: POST data 😉

And the author's reply:

You would need to run the encryption by sending the form data via Ajax to a PHP page -- which in itself would be an insecure, although hidden, GET request. You would only be replacing one insecure transmission method with another. [Emphasis mine]

But the whole point of this method is that normal GET requests "usually requires displaying data directly in the address bar of the client browser."

Sounds like a case of DIY security by someone who isn't clear on what they're trying to secure.

laserlight

If you're going to be doing all that (and the only remotely plausible reason I can think of as to why you'd want to is because the GET is to a different domain), why not encrypt it properly?

If the query string is passed to a different domain, the whole scheme does not work, since the receiving end would have no access to the mappings.

Reading more into the comments, the author stated:

That's why I wrote this solely as a method for eliminating the need to display GET data to the client when writing URL query strings from PHP code, rather than presenting it as an encryption method that's viable for POST submissions.

If this is so, then a known plaintext attack might be difficult, depending on how the developer implements this scheme. On the other hand, the use of say, sessions would completely eliminate this possible loophole.

Sxooter

There are a couple of bad assumptions that this article seems to be making. They're very common. The first one is:

POST is secure
GET is not.

From a security perspective, there's no difference. I can crank up tcpmon or ethereal and view anything travelling to / from my web browser.

From the hacker perspective, POST and GET are the same, security wise.

If it's not safe to send it in a GET url, it's not safe to send it in a POST url. If you want to keep someone from snooping your communications, use ssl. If you want to keep the user from seeing it, don't send it.

Weedpacket

laserlight wrote:
If the query string is passed to a different domain, the whole scheme does not work, since the receiving end would have no access to the mappings.

Er yeah; I misspoke. You're right, as long as you assume the two domains are on different hosts (which is not what I was thinking of at the time). Session IDs wouldn't migrate automatically in that case. Of course, this encryption has to be done manually, and if you can do that you can propagate a session ID manually.

I'm still in the dark as to an adequate usage scenario. Then again, I'm also the person who got bored one day and engaged in this conversation.

Shrike

Has this guy never heard of SSL? You know, that industry standard, commonly used, well defined client-server encryption? Or perhaps this is for people who don't want to shell out for certificates.

I shudder to think of credit card numbers being 'encrypted' this way.

GET requests are the method of choice in cases where the data to be transmitted is relatively short

And here's me thinking that GET is for getting and POST is for posting.

Shrike

Weedpacket wrote:
You would need to run the encryption by sending the form data via Ajax to a PHP page -- which in itself would be an insecure, although hidden, GET request. You would only be replacing one insecure transmission method with another. [Emphasis mine]

If I shut my eyes, you can't see me.

Sxooter

(fingers in ears) lalalalalalalala I can't hear you..... lalalalala

Ahhhhhhhh. Now everything is safe and secure.