Encrypting form POST data

Blulagoon

I need to encrypt some form POST data.

My initial idea was to use mcrypt, using MCRYPT_RIJNDAEL_256 and MCRYPT_MODE_CBC, but this failed because the encrypted string contained single and double quote characters which caused problems with the delimiter of the value part of the hidden form field.

<input type='hidden' name='pid' value='<?php echo $text; ?>'/>

I've added a line to my encrypt function to base64_encode the encrypted string, which I think precludes single and double quotes from the resultant string, but I'm not certain about this. Its worked fine with all the large chunks of text I've tested it with so far.

This seems a very roundabout way of doing things, is there an alternative cypher mode or cypher which offers security and is designed with POST data in mind, i.e. excludes quotes within the string. I can't use hashing as I want to decrypt the form data later.

Blu

bradgrafelman

Blulagoon wrote:
I need to encrypt some form POST data.

For what purpose? Is this sensitive data that you don't want the rest of the world to see? If so, you need to look into SSL.

If you're simply trying to encrypt it so that it is POSTed to your script yet the end-user has no clue what the actual (unencrypted) data is (so they therefore can't tamper with it, perhaps?), then I would recommend using sessions so that the user never comes in contact with the data in the first place.

Blulagoon

Thanks for the input Brad.

1) Yes, we are using SSL, so few worries about the outside world.

2) Imagine a scenario where you have two applications, one a document server with lots of reports on it in pdf format worth 1,000$ each, and a second app that provides print on demand, fulfilment and billing services.

The document server has to provide the url of the pdf file so the print app can retrieve it and print it, so the pdf file has to be within the doc root. Now if the punter can see this url they can save themselves 1,000$ :mad:

How do session variables pass between pages ? Suppose you had a packet sniffer, such as ethereal on your system could you see the url being passed in a session variable ? Thats why encryption seemed the route to go, with a password agreed between the owners of the two applications.

If I tried to use mcrypt on the session variable information would I have the same problem with quotes when I came to try and decode $_SESSION['myurl'] ?

What I think I really need is an mcrypt cypher that excludes the use of quote symbols in its encryption process.

Blu

bradgrafelman

This "second app", that needs the URL, is it a client-side application, or is it a server-side application and you are using this hidden element to transfer data from one app to another?

If it's server-side, then a session would be your best bet; session data is kept on the server and on the server only - the client only stores/sends the session ID.

If it's client-side, then I would use an mcrypt as you are. You say that quotes break the HTML? Sounds like you need to use something like [man]htmlentities/man with the ENT_QUOTES constant.

laserlight

This seems a very roundabout way of doing things, is there an alternative cypher mode or cypher which offers security and is designed with POST data in mind, i.e. excludes quotes within the string. I can't use hashing as I want to decrypt the form data later.

This is not so much a mode problem, but just the fact that the ciphertext is in binary. If you really want to do it this way, then base64_encode is one way to go.

Weedpacket

Blulagoon wrote:
The document server has to provide the url of the pdf file so the print app can retrieve it and print it, so the pdf file has to be within the doc root. Now if the punter can see this url they can save themselves 1,000$

No, it doesn't. URLs are not file paths. Just because you have a URL "http://www.example.com/print-server/category/document.pdf" doesn't mean there has to be a "/document-server/category/document.pdf" in your file system.

All that has to be in the document root is a script that can locate the PDF file wherever it happens to be on the filesystem. The script receives the request and does whatever is necessary to verify the legitimacy of the request (including holding a conversation with the client machine), record it somewhere as having been made, and finally retrieves the file and outputs it as the body of the response.

To make it transparent to the user, configure the server to process URLs that end with ".pdf" by sending the PDF's file name to the retrieval script. It might be a matter of having the server take a URL ending with "/document-server/document.pdf", turning that into "/document-server.php?doc=document" and then seeing if you have a script called "document-server.php".

Blulagoon

Thanks everyone for your responses. Unfortunately I'm only involved in building the bridge between apps 1 and 2 and have no say in how they have been set up.

The owner of app 1 is hell bent on encryption, and has some security adviser reinforcing this view and saying Sessions are unsafe. Brad, thanks for your input about how Sessions are passed between 2 server apps, I will be looking into this.

Laserlight, you say if I want to go down this road, and it looks like I'll probably have to but not through choice, you say "then base64_encode is one way to go" can you suggest any others ? I'd like to examine several encryption options if they exist.

Thanks everyone - Blu

Weedpacket

[man]htmlspecialchars[/man] or [man]htmlentities[/man], perhaps; but since the encrypted string is arbitrary binary (it's not just quotes you have to worry about, but ampersands, left and right angle brackets, character set encodings, NUL characters...), base64 is probably the simplest and most robust solution. (Another alternative would be to use hex - NUL=>00, A=>41 Z=>5A and so on - but all you'll gain from that over base64 is a bigger string: base64-encoded data is 33% bigger than the data itself, but hex-encoded is 100% bigger).

(Quick namecheck: base64 is not encryption but encoding; there's no attempt being made to make the data unreadable - quite the opposite, in fact.)