I run a website which can be reached through different domains: domainname.de, domainname.ch, domainname.at, domainname.es etc. ...
When my customer wants to pay we gets to a payment page which is of course https secured. Due to server limitations I am only allowed to have one SSL Certificate which I only put on one domain: domainname-secure.com.
Because I charge different prices I need to know which domain the user belongs to, so when redirecting to domainname-secure.com I save the domain (e.g. domainname.de) in the session variable $_SESSION['domain_default'] and pass the sessionID by adding session_id=[session_id] as a get parameter.
Then I check I take $_GET['session_id'] and run the follow command to have the session available on the domainname-secure.com:
session_id($_GET['session_id']);
session_start();
When I test it myself, it works perfectly fine but I make a log entry when somebody gets to domainname-secure.com and has not have set $_SESSION['domain_default'].
This occurs several times a day but I really have no clue why this does not work! I am testing it again and again from many different links but for me it works perfectly fine.
Can some of you imagine why it sometimes does not work?
Is it not "good" or insecure to pass the session ID to another domain and is it not always readable after redirecting?
I know it is hard for you to determain a mistake but I am searching for some know issues with session or maybe a tip how to do it in a better way?
Session are administered by PHP on a per domain basis meaning they don't mix domains intentionally.
If you would be using another session storage mechanism such as writing into the database or using memcached sessions you'd be able to overcome this limitation.
There are two approaches if you want to be able to access the session info when changing domains either:
Don't use PHP's $_SESSION, setup your own session management with memcached/redis/sql;
Or:
Use PHP's $_SESSION, but when transferring from one domain to another serialize the data in $_SESSION and put it somewhere accessible from both domains like sql;
Related
I'm working on a project that keeps some user information (non-sensitive) in a php session. As it is my first time working with sessions, I never bothered to pass any Session ID, but it still works - is that right ? I couldn't find any information about that.
I'm using some parts of the information in the $_SESSION variable to navigate and influence some of the sites' behaviour, and it sometimes is crucial for the page to interact with the user. Meaning without the correct informatin of the current session the navigation will be broken.
So, can I rely on the existence of Sessions ?
And can I rely on the server to automatically pick the right session without passing the SID ?
I'm working only on one server and I don't need the session to be restorable (meaning that when a user leaves the application the session can be destroyed).
If you couldn't find information about that, you probably skipped the most obvious reference: the official PHP manual. It's right there in the Introduction of the Sessions chapter:
Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.
A visitor accessing your web site is assigned a unique id, the
so-called session id. This is either stored in a cookie on the user
side or is propagated in the URL.
If your question is whether cookies are reliable for this purpose, in fact it's the de-facto standard nowadays. You'll hardly find PHP-powered sites that still transmit the session ID in the URL. The reason is that it's a problematic technique: it's too easy to give away your session ID. If you copy the URL and send a link to a friend or post it in a forum it's very easy that any stranger is able to access your private data, even inadvertently (you don't need a malicious guy here) if they visit the site before the session has expired and the site does not implement further verifications (which is the usual situation).
Yes you can rely to having the server to pick the correct sessions for you. I have in my 10 years of php coding not experienced a faulty session yet.
However, if you choose to pass the sessionid to the next page, be ware of the risks. Session hijacking is a very serious business if you have any sort of private data.
So I have 2 domains: http://domain1.com and http://domain2.com
domain1.com has a bunch of cookies for the user stored on it.
I want to access all of those cookies but from domain2.com (to keep them synchronized).
Is this possible in JQuery? I was thinking of making a Cookie php file and somehow connect to that file from domain2.php to pull all of the data in.
Thanks for any help
NOTE: These are NOT sub-domains but 2 completely different domains I Control
In a strict sense? No. It isn't. In a more loose sense, yes it is.
If you're storing all of your data in cookies, you're actually storing the data in the browser, which means that jQuery, Prototype, Mootools... can't help you because of browser security (unless you can turn their browser into a server (might work with a Firefox extension (I swear, FF could be an OS if needs be...), but that would be gratuitous)).
I said that in a loose sense it is possible because PHP lets you do two very important things. First, it lets you store your session in a database, and second it lets you assign the session ID directly. It is possible, then, to have two servers point to the same DB and then share SESSION data by switching the user's session ID.
no. this would violate the security model on which browser cookies operate.
to work around this you can implement an iframe (perhaps invisible to the user) on domain1.com which is served from domain2.com and pass data between the two sites with JS.
I would look at a server-side solution, creating a common database that all sites can access. When the user logs in, generate a time-sensitive, IP-keyed token that can be passed from site to site either in GET or POST. Then, validate each request on token, IP, and time. The combination of the three will resolve most security concerns.
or you can look at this SO question for ideas its in .Net though Store cookie for other site
There's a bug, which we can not replicate, which involves users in one specific region of our enterprise customers swapping. For example, a user logs in as themselves on the login page, and when arriving at the home, they are another user.
It seems like accidental session hijacking, here are the clues:
cakephp security is set to low (this only means the cookie doesn't
rewrite every page load, and the the cookie does not do a user agent
check )
our cookie is set to not care about subdomains (.example.com instead of example.com)
enterprises users areredirected using a 302 if they login to the wrong area (should we use 303?)
there was a 301 accidentally sent out, but users are able to replicate
all the affected users are behind a single router, sharing internet via Sprint MPLS
all the affected users may be using computers issued by the customer
their IT claim there is no proxy cache, and no remote VPN access, yet they claim to be able to replicate the issue from home computers and off the network.
Since we can not replicate the issue in any way, we can only assume that the issue is specific to their network.
How can we prove that their network/computers are causing the session swapping? Or, what configuration on our end could be causing this, when no other users experience this issue?
[edits/updates]
Responding to some direction provided by comment - our traffic is not large enough to send duplicate IDs. (the statistically probability is too low to see what we've seen the customer replicate ).
see also:
Zend Framework Session swapping issue
why is php generating the same session ids everytime in test environment (WAMP)?
Update:
We use FCGI, and apparrently mod_php is required to understand x_forwarded_for
What's wrong with this function call?
This may be a problem with improper session invalidation in the log out. please ensure that all the variables in the session are properly terminated or explicitly null terminate every object in the session and then invalidate the session.
The second reason may be the use of variables check for static variables in your code. improper use of static variables may also cause this intermittent issue.
Use logger to log session id mapped to the user ids that can narrow down your problem and help you understand what exactly happening.
Invalidating the existing session in login action and creating a new session and copying content to the new session will help a lot.
First, do not assume the customer is at fault. It may an issue on their side or yours. Do not make an assumption as to which before testing.
Regardless of who's fault it is, the burden is on you to fix or help fix it.
First, having one user become another is often the result of a Session ID problem. The security level you have set in Cake does not regenerate the Session ID for every request.
I would start by logging the $session->id() as a user both inside and outside your local network. Then compare to see if the session id is ever the same or ever an empty string. One fix for this is to generate a unique id for each user.
If the Session ID is unique for each instance, you may want to test it under load.
The point is to test first and make conclusions based upon findings, not speculation.
I have a site I'm deploying and I've hit a problem. I was testing my code in a sub-directory of my clients hosting package and everything seemed fine. However I've moved the folders/files to the site root and now I'm intermittently losing all session data.
I've taken a look with LiveHeaders in Firefox and these cookies are being set:
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2;
__utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.188.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
and
Cookie: __utma=196298984.443251570.1275554915.1275554915.1275557276.2; _utmz=196298984.1275554915.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
__utmb=196298984.189.10.1275557276; PHPSESSID=3f5a363de3b7ec6084c7fdf90bec78a8;
__utmc=196298984
I'm by no means an expert on headers so if you need other information, I should be able to get it.
For a session to work, two elements have to both be working:
First, the browser must send the same PHPSESSID cookie with every request. The session ID will change from one session to another, so if you login tomorrow (or later today, or in a different browser, et cetera) you'll get a different ID than you have now, but during a single session the ID should not be changing.
Second, the server must be able to access the same files associated with that ID during every request. By default, PHP stores that information in the /tmp/ directory. If you have access, you could even poke around there and see what's getting stored.
The first issue is easiest to test for. Take a look at what cookies are being sent while the session is working, and then check again after the session stops working and see if the PHPSESSID has changed. The most likely cause for behavior like this would be a poorly set local computer clock, poor timeout settings on the session, et cetera.
The second issue is a bit trickier. If your browser is sending the right cookie with every request, but PHP can't access the file with information about that session, the problem is with the server. You might consider storing your sessions in a database (if you're using one anyway), which is easily done with code in the PHP manual.
A couple of things that come to my mind:
1 : Make sure that if your session is being created on www.abc.com, then all browsing happens on exactly that domain, if some pages are being sent to abc.com instead of www.abc.com, this is likely to cause session/cookie problems.
2 : also make sure that session_start instruction is available on top of ALL pages.
The problem is that I have a PHP script (A) that does signup, authorize Twitter, then the twitter calls back to a return PHP script (B).
In script (A), I set some $_SESSION variables, and in script (B) I will get it. Very straight foward.
I have tested it on my computersss, and it all works. I can see the session variables in script (B) set by script(A). so as my friends.
However, the most important thing is, my boss' computer cannot see it! that's the worst. he also tried on his computersss, still didn't work at his end.
I even reboot and restart the server, but still, situation remains the same.
So, my question is, is there any kind of restriction that the server cannot set the session on a computer? or,.. in which situation, the server will fail to set the session?
Server: Apache 2.2.3. Using Plesk
PHP: 5.2.5
Maybe a stupid question, but anyway... does your boss block cookies on his computer?
If that were the case and for some reason PHP was set up to not 'fall back' to passing the session ID via the query string (or the redirect stripped it somehow), that may be a problem.
The session id is different on different computers because that's the idea behind sessions. You assign a number to each visitor (the session id) and by that number you can identify users and store information in each users $_SESSION array. This array is available only to that single session/user.
If you want something to store data for all visitors of your site, you might want to use a database or a serverside cache.
Since it’s the session that fails, check that the client uses the same session on every request and not a new one. Check if the session ID is carried along properly. If you’re using a session cookie, check its validity settings and see if the session cookie is accepted by the client. See PHP Session/Cookie problems with Windows XP, Vista, IE and certain users.