Everyone says it's a mistake to use html hidden fields because users can maipulate them. So why not simply encrypt them? Is there a problem in that users can force a particular value into the hidden field and then, knowing both encrypted and clear texts, can crack the code? Is there a code avaliable in php5 that can't be cracked? (I know very little about encryption).
php security on hidden html
All fields in your form can be manipulated (and done so quite easily) by a malicious user, hidden or not. Even if you have JavaScript form validation functions and maxlength values for the fields, such things can be bypassed (and again, quite easily) by a malicious user. It is therefore incumbent upon your form handling script to not trust any form data. You must validate all incoming data, whether it's from $POST, $GET, $REQUEST, or $COOKIE, and reject it if it is not within the size and format limitations that you require.
If you are specifically concerned about a user seeing the values of any hidden fields, rather than messing with encryption, I would recommend using PHP sessions instead for storing that data. Then it never gets sent to the browser in the first place and thus cannot be viewed in any manner by the user. (All they can see is the session cookie value, which is simply a meaningless, pseudo-random string.)
Thanks NogDog, but what's wrong with encrypting the hidden data? I like to keep things simple, and sessions don't seem that simple to me. Encrypting the hidden data seems such a simple solution to malicious manipulation of hidden data that there must be a catch. What is it?
The catch is that it is still possible to manipulate it. It is possible to find out how to decrypt it, then use that information to encrypt your own data. Even if you don't find out how it is encrypted you can easily change the information and send lots of requests, having luck at some time.
To make it simple: If you can't trust the information without encryption you should not trust it with encryption either.
I like to keep things simple, and sessions don't seem that simple to me.
So, despite knowing very little about encryption, you think that encryption is simpler than sessions? 
Encrypting the hidden data seems such a simple solution to malicious manipulation of hidden data that there must be a catch. What is it?
Key management. Suppose you use a symmetric key encryption algorithm. You need a way to hide the key from the user. But if you use say, a session variable, or store the key in a database, then these same methods used to store the key can be used to pass the data without (direct) manipulation by the user, so you might as well use them instead of encryption.
If you are determined to use encryption, see the [man]mcrypt[/man] functions.
As far as the "difficulty" of using sessions, all you need to do is two things in each file that needs to read and/or write session values:
(1) Start the script with a [man]session_start/man; command before anything is done with session values (and before any output is generated by the script).
(2) Save values to the $_SESSION array or read them from the same:
script_1.php
<?php
session_start();
// save a value:
$_SESSION['test'] = 'foobar';
script_2.php:
<?php
session_start();
// read the saved value:
if(isset($_SESSION['test']))
{
echo "The value is: {$_SESSION['test']}.";
}
else
{
echo "The value is not set.";
}
laserlight wrote:So, despite knowing very little about encryption, you think that encryption is simpler than sessions?
I have read turorials on sessions and on encryption. They say sessions are temporary. If this is not true then sessions are not simple; if it is true they are not for me. I need users to come back with their data at any time in the future to take up my application - an educational one - where they left off. I don't want them to be able to manipulate their previous score so as to skip lessons. An SQL database with login and authentication will do it but it would take me some time to learn how to build one and it seems like overkill. My server's php5 has Mcrypt, which as I understand it allows encryption/decryption. I have asked you whether this would protect hidden html data against client-side manipulation, using a single key stored in my php script. The answer I seem to have got from you guys is that it won't work because any encryption can be cracked. OK, thanks I guess that answers my question.
I need users to come back with their data at any time in the future to take up my application - an educational one - where they left off. I don't want them to be able to manipulate their previous score so as to skip lessons. An SQL database with login and authentication will do it but it would take me some time to learn how to build one and it seems like overkill.
In this case a database is indeed the correct solution. Sessions (and cookies) can play a part, but for such persistence, you need a database (e.g., using relational database software like MySQL, Postgresql and SQLite). It is not overkill.
Encryption is not the correct solution since you already have a secure channel (i.e., your web server).
The answer I seem to have got from you guys is that it won't work because any encryption can be cracked.
While that is true, I think it is not the real issue. With strong encryption it is unlikely any users will be able to break it. However, there is no point in using encryption when you can deny the user the possibility of manipulation in the first place.
Perhaps the underlying question that needs to be addressed is: what kind of data is intended to be stored in the hidden fields, and why would it matter if a user could view that data? Personally, if the data is truly sensitive and harm could occur to anyone other than that user if he is able to view that data, then I would prefer to avoid making it available to him in any manner, using either a sessions solution or a database solution to store that data.
If, on the other hand, you are just concerned about a malicious user changing that data in some manner to somehow gain some advantage, then I would not be particularly concerned about using hidden fields to store the data and would instead just make sure that I filter all such incoming data for invalid content (as I would for all incoming form data).
I agree with NogDog. Does it really matter if the user can change it? It isn't stored anywhere, so the only reason not to allow the user to change is that he will see the wrong result. I wouldn't worry about it at all.
Does it really matter if the user can change it?
It does. "I don't want them to be able to manipulate their previous score so as to skip lessons."
Coupled with "I need users to come back with their data at any time in the future to take up my application", I thus reason that a database is most suitable since persistent storage is needed.
gringo wrote:I need users to come back with their data at any time in the future to take up my application - an educational one - where they left off
Irrelevant. Hidden form fields are even more transient than session data: session data by definition persists for the duration of the session, while the form field only survives for the duration of a single request. The only way a hidden form field would be at all useful for persisting data is if the test-taker were to save the HTML file on their computer, and then reopen it later.
In other words, a database would be necessary anyway, and doesn't address the problem originally raised (for which I also weigh in on the side of using sessions).
If you want, you can think of session management as an encryption system where an entire codebook is constructed and updated from one request to the next so that the code word "01zYQn6wJhbKsRWPk5p4YW6hfA7" can be looked up in it and matched to an arbitrary amount of plaintext (or, rather, serialised PHP data).
Weedpacket wrote:...The only way a hidden form field would be at all useful for persisting data is if the test-taker were to save the HTML file on their computer, and then reopen it later.
You got it, Weedpacket. That's exactly what I ask the user to do: save his html page. I found that if you specify the full url of the php script in the POST action, opening the saved file connects the user to the script again. So, I know that sessions and databases are more elegant but is this not the simplest way to do it? Is Mcrypt blowfish or rijndael or whatever not secure enough to encrypt the html hidden data? (N.B. no planes will fall out of the sky if the user cracks it). How come nobody else does it this way?
That's exactly what I ask the user to do: save his html page. I found that if you specify the full url of the php script in the POST action, opening the saved file connects the user to the script again. So, I know that sessions and databases are more elegant but is this not the simplest way to do it?
...
How come nobody else does it this way?
You're thinking from the viewpoint of a programmer. To you, this solution sounds simple because it means (or so you think) less work for you. But this imposes a burden on your users. They have to save the file, and they better do it correctly, or else.
But is this really less work for you? Maybe, in the short run. What happens if you want to change the form? Have you considered replay attacks where a user sells his/her encrypted high score to another user? Suppose a user claims that he/she saved the file, but somehow it is now missing. What are you going to do?
Is Mcrypt blowfish or rijndael or whatever not secure enough to encrypt the html hidden data? (N.B. no planes will fall out of the sky if the user cracks it).
The ones you listed probably are secure enough.
Try to think about it another way.
If you were asked to save a page as html, would you do it? Would your parents do it? Your friends? There is no way I would do it, it is not user friendly enough. I have enough problem keeping track of my bookmarks, files would be to much. To much both to keep track of and to demand from a site.
However, there is a way you can do it without having to save the html page. If you use the GET method instead of POST it is possible to save it as a bookmark. I don't recommend it, I would not do it and I doubt others would do it. But it is a possibility.
To be honest, if you had started with a database it would probably be working now. And that is how it usually is when you find some solution that is not standard, it takes lots of extra time and the result is not as good as the standard solutions. Having said that I think it is good that you want to understand why you should not use it. And without coming with unusual solutions you won't find the solutions that are better than the standard solutions.
gringo wrote:is this not the simplest way to do it?
The short answer is "no".
How come nobody else does it this way?
See above.