Better security for forms?

[malakiahs]

I have a form that after is filled out and submitted the user is redirected to another page where the form is displayed.

The way I'm doing this is by inserting the values to the database first and then pulling them out from the database to display the array in the redirected page.

So that no one else sees other user's information, I am using a unique and encrypted token and storing it in both a SESSION value and in the database; I create this token and assign it to the session variable only if there are no errors in the form. In addition, I'm picking up the insert ID and also storing it as a session value as well.

Before displaying anything the page. where the user is redirected to, it checks for the SESSION token, else the user is redirected to the previous page.

On the next page, when I need to select the values from the database I include in my select query something such as "SELECT * FROM table WHERE (token='SESSION['token'] TOKEN AND form_id='$SESSION['form_id']) LIMIT 1" (Please note that this might not be the right syntax for the query it is just the gist of it).

Now, my questions!

Is this secure enough to prevent anyone from trying to see someone else's information? I'm afraid that with the current method it might be vulnerable to an SQL injection, even though i'm using a prepared mysql statement, which sanitizes all the input.

Or should I use method 2,

Which is to store all the information of the user from the form into the SESSION array and display the values of the session, instead of fetching the values from the database.

Thank you in advance for your time and help.

[bradgrafelman]

Is there any reason why you didn't start with option 2 in the first place? Is there any benefit you get when using the database, or are you really only using it as a place to dump some data between page requests?

[malakiahs]

Thank you for you prompt response, I forgot to mention the reason why I went with other other option.

The reason why I did not start with option 2 was because the sessions can get hijacked. And I'm thinking that (though I could be wrong) if the sessions get hijacked, whats stored in them is only be the encrypted token and the ID, not all the information.

[bradgrafelman]

malakiahs;10998039 wrote:

The reason why I did not start with option 2 was because the sessions can get hijacked.

How is that any different from option 1? It doesn't matter where the data is coming from, a hijacked session is a hijacked session.

malakiahs;10998039 wrote:

And I'm thinking that (though I could be wrong) if the sessions get hijacked, whats stored in them is only be the encrypted token and the ID, not all the information.

Again, it doesn't matter where you store the information... if I hijack someone else's session, the end result is going to be the same.

[malakiahs]

I see, then a better way to do this is to store all the information in the $_SESSION array and display it later?

[bradgrafelman]

If you're not using the database for any other purpose other than to dump the data received during one request just so that you can retrieve it during another request, then the answer is most likely yes.

[Bonesnap]

Why not just have the results of the form print out on the same page, and have the information stored in the $POST array? You could even stick to your two-page method and still use the $POST array.

[malakiahs]

In the same database I have tables with information that is displayed as as drop-downs menus in the form. But I can easily change these tables to their own database, with a different mysql user that can only select for this purspose, if this adds security.

I am also creating an administrative side, where authenticated users log in to view these records that have been submitted. Does having different users with different privileges in the mysql, say a public user that can only insert, and a private user who can only select, add better security?

[malakiahs]

Bonesnap;10998052 wrote:

Why not just have the results of the form print out on the same page, and have the information stored in the $POST array? You could even stick to your two-page method and still use the $POST array.

Hey Bonesnap,

Thank you for your response.

The reason why I'm not doing this is because if the user, who submits the page, refreshes it, then the information will be submitted as many times as they hi the refresh button. The only way that I could think of to prevent this was to redirect them to a different page. Have you encountered this problem? What do you do to prevent it?

Thank you.

[Bonesnap]

If the user tries to refresh the page, the browser displays an alert asking if they're sure they want to resend the form. It does it on Firefox, at least.

[malakiahs]

I did notice that. I tested it and most popular browsers do prompt you if you want to resubmit the form. However, I'm trying to follow the PRG method, since these prevents most basic re submissions.

[bradgrafelman]

One way is to use sessions/cookies. When the user first visits the form page, generate some random string of characters, store that value somewhere (e.g. session or cookie), and also include that value in the form itself (e.g. has a hidden <input> element).

Next, when you process form submissions, check to see if the values match. If they do, alter the stored value (either erase it or re-generate another random string of characters) and then process the form results. Subsequent resubmissions can then be filtered since they would still contain the old hidden value (which no longer matches what you've stored separately in the cookie/session).

[malakiahs]

bradgrafelman;10998083 wrote:

One way is to use sessions/cookies. When the user first visits the form page, generate some random string of characters, store that value somewhere (e.g. session or cookie), and also include that value in the form itself (e.g. has a hidden <input> element).

Next, when you process form submissions, check to see if the values match. If they do, alter the stored value (either erase it or re-generate another random string of characters) and then process the form results. Subsequent resubmissions can then be filtered since they would still contain the old hidden value (which no longer matches what you've stored separately in the cookie/session).

This sounds promising and i think it might work. I'm gonna give it a try and post the results that I get. Is this more secured than storing the information in the $_SESSION array and showing it in another page?

[bradgrafelman]

It's neither more nor less 'secure' since the technique I described above doesn't address security at all - that's not its purpose.

[malakiahs]

bradgrafelman;10998085 wrote:

It's neither more nor less 'secure' since the technique I described above doesn't address security at all - that's not its purpose.

Then the right question to ask is. Which method do you think is the best one?

[malakiahs]

malakiahs;10998086 wrote:

Then the right question to ask is. Which method do you think is the best one?

Or if you were in my position? What would you do?

[bradgrafelman]

I still don't understand your question(s).. What methods are we comparing, and what are we basing the comparison on?

[malakiahs]

bradgrafelman;10998091 wrote:

I still don't understand your question(s).. What methods are we comparing, and what are we basing the comparison on?

Well, I have to display the input/data of the form (after it is submitted); whether it is on a separate page or on the same page. I would like to do this using a secure method, I know nothing is bulletproof, so if you could recommend me of an appropriate method to do this I will appreciate it. I could only think of the 2 methods mentioned earlier, plus the one bonesnap discussed, which was to display the form in the same page and not redirect the users. I want to be sure that I used a good method to prevent others from seeing another user's information when the form is displayed.

Please note that since security is my main concern, I will also be using an SSL connection.

[malakiahs]

bradgrafelman;10998091 wrote:

I still don't understand your question(s).. What methods are we comparing, and what are we basing the comparison on?

What I'm most worried about is data being crossed from person to person if two or more forms were submitted at the same time and displaying information that does not correspond to that person. Or someone hacking the page where I'm displaying back the input that the user submitted, and seeing other user's information.

[Derokorian]

malakiahs wrote:

What I'm most worried about is data being crossed from person to person if two or more forms were submitted at the same time.

Every person submitting the form is sending their own unique HTTP request. The server will handle each and every HTTP request SEPARATELY so their will be no chance of requests getting "crossed". Furthermore, as long as the hardware can handle it you could have literally millions of forms submitted at the same exact time without problems. Don't believe me? Check the stats of how many Facebook status updates there are per second (answer roughly 5,000).

malakiahs wrote:

Or someone hacking the page where I'm displaying back the input that the user submitted, and seeing other user's information.

See my previous comment.