Jump to content

Can I pass SESSIONS from an ssl to regular url?


Recommended Posts

I have a client that came to me because her captcha wasn't working. I looked at the code and it appears to b fine. This is generated in a PHP file for the captcha string/image $_SESSION['image_value'] = md5($rand_str); . That script is validation_image.php  and is called on by a dc_new.js file. That js file is being executed by a php file on the https:/...  url, so after having that  $_SESSION['image_value'] = md5($rand_str);   passed to a non SSL url, the value seems to change? is it possible to pass the session variable from an ssl to a normal url?

You can recover a session if both domains are on the same server. Pass the session ID from one url to another i.e

 

https://www.yourdomain.com/xyz.php?sessId=123456789

 

You can then recover the data using the following:

session_id($_GET['sessId');
session_start();

You can recover a session if both domains are on the same server. Pass the session ID from one url to another i.e

 

https://www.yourdomain.com/xyz.php?sessId=123456789

 

You can then recover the data using the following:

session_id($_GET['sessId');
session_start();

 

Please do not do this, you would be building in a session fixation vulnerability in to your app.

 

http://www.php.net/manual/en/session.security.php - link at top.

 

Sessions are stored on the server, so you're not passing the session variable around, just the session cookie.  Just make sure you're not setting the cookie as secure only, as well as the corresponsding session.cookie_secure ini setting, and you should be good.  Firecookie can tell you if it's not matching for whatever reason.

Just make sure you're not setting the cookie as secure only

 

^^^ Don't do that either. Doing so will allow the same people who are monitoring data packets and were able to get the session id from the end of the URL with the previously suggested method, can now just as easily get the session id when the session id cookie is sent in the  non-HTTPS request.

 

The point of buying a SSL certificate is because you want the information being sent back and forth between the client and the server to be secure. As soon as you send that information over a non-HTTPS connection, you might as well have saved your money on getting the SSL certificate.

That was my thought. This design defeated the entire purpose. I think I understand why it was coded this way by the other programmer- to get rid of her. I think I'm just going to rebuild her a new one .

 

Her current forms are in php 4, I think changing it to php 5 ill make it easier to do the longg list she would also like added.

 

Thanks for the advice and opinions, it's good to hear others on a question

I was merely answering the question on how to recover session data by using the session_id() function http://uk.php.net/session_id. By no means am I suggesting to use this method. As suggested SSL is there to encrypt the data sent back and forth. Requests should be made over SSL.

The short answer: if you have data going back and forth between the browser and the server (including the session id) that is important enough to use SSL/HTTPS for in the first place, then just use HTTPS. Also, since the URL is transmitted in plain text before the Secure connection is established, anything you put into that URL is not secure.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.