views:

219

answers:

4

I have a 4 step form process.

form.php, validation.php, review.php and complete.php

Form.php posts to validate.php which depending on the validation redirects either back to form.php or to review.php. The final step is complete.php

Each page is called with HTTPS except validate.php which is where the SESSION variables are created and then redirects back to form.php or review.php calling https.

The lock on the browser never disappears but I was told if you post to a relative path (not calling https explicitly) the form is not secure.

Is this true? Am I secure? Is there a way to check and or prove that the form process is secured or not?

thx
ps 1.someone is telling me it is secure but I just want to be sure so I am not liable.

2.I am using a relative path on the form post because the SESSION variables arent created when the page is called explicitly with HTTPS. IF anyone has a potential solution for that that would be great as well.

+1  A: 

It is OK to use relative paths. To be sure you can use network packet viewer application to see if the contents are encrypted. However one thing concerns me about your code, do you store validated data in session variables? If so, are you sure no one can access session values other than root user and php. I would recommend storing validated values within database just in case, you can always remove outdated records using a crontab.

Cem Kalyoncu
I am storing sensitive information in SESSION variables until complete.php where I store then in the db. How can I sure only root and php have access to the variables?
chris
You can check access rights, but, allowing PHP (actually user Apache) into that directory will virtually allow some script to access those files; unless PHP has some very tight security measures. I use database just to be sure and block access to any directory other than /var/www/html using seLinux. This is a guaranteed way of doing it since seLinux is very zealous about access rights from remote (separate from file system access rights).
Cem Kalyoncu
+6  A: 

Even though are not explicitly posting to, for example, https://your-server.com/validate.php, the fact you are using a relative link (e.g. action="validate.php") means it is still using HTTPS every step of the way.

Short answer - the protocol doesn't change on relative links. So if form.php is not HTTPS, the form variables will not be submitted securely with a relative link.

meanstreakuk
+2  A: 

The lock on the browser never disappears but I was told if you post to a relative path (not calling https explicitly) the form is not secure.

That is rubbish. A relative URI is a relative URI and doesn't cause a change in protocol.

If the page was requested via HTTPS and the URI is relative, then the next request will also use HTTPS.

I am using a relative path on the form post because the SESSION variables arent created when the page is called explicitly with HTTPS

You must be misdiagnosing the problem. Browsers resolve relative URIs into absolute URIs internally. There is no difference in the data sent.

David Dorward
what I mean is, I was originally trying to post the form was action="https://site.com/validate.php" and nothing was happening. Changing it to action="validate.php" fixed it but i wasnt sure if I was remaining secure.
chris
Stack cuts the http part but yea. Any idea why using the absolute path in a form action would cause problems?
chris
+1  A: 

If you have data posting to or are sending back information to the browser that is being used to complete the transaction from validate.php and are not using HTTPS for the data, then you have a potential hole in your application. If validate.php is called with a relative path, from a page loaded via HTTPS, then it will be using HTTPS by default -- relative paths inherit the protocol, hostname, and port if they aren't explicitly specified.

None of this means that your page, however, is secure. It means that the data that is being sent is being encrypted. You could still have several issues (weak passwords, SQL injection, cross-site scripting, etc.) that you need to deal with even when using HTTPS to transfer data. If you are using HTTPS, at least, your data transfers will be much more difficult to intercept or spoof.

tvanfosson