Re: [PHP] Re: Session's across Domains...
On 11/9/05 11:05 AM, Tony Di Croce wrote: If the shopping cart on site A submits to the secure CC processing page on site B, then the contextual data that describes the order (price, order number) was actually communicated from A to B via a hop at the users browser (likely via a hidden form field on site A). Thus it would need to be encrypted and urlencoded (otherwise anyone could hit "View Source" and see it all in plain text). Is the price and order number sensitive enough to encrypt? Like we've already discussed, the order number will be considered invalid once it's been processed, so any subsequent attempts to use the order number will result in a failed transaction. If the order number includes sensitive information, however (such as the full credit card number or something), then you should rethink how you create your order numbers. You also don't need to urlencode anything in a form field. When you submit the form, the browser handles the urlencoding for you. (If you were POSTing from a script, then, yes, you might need to urlencode it.) As for the other question about POSTing on a redirect, it is possible through several different means, and if this is a route you want to take, I would suggest looking at PEAR::HTTP_Request, since it provides an easy to use API for this. I, however, don't think you'll need to do this (at least it doesn't sound like something that's necessary given what I know about your form). -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
Ben Ramsey wrote: B is a secure page, with a CC info form that when submitted will process their card, charging the amount of money passed in the encrypted packet, and if the charge succeeds, redirecting back to A. A would probably need to send an order number to B, and B could pass that back to A upon success or failure. All of this is to get around the Apache limitation of allowing only one virtual host to use SSL. apache does not have this limit. this is limit of https protocol, because encryption takes place before any request is made, so the only way to know what SSL certificate to use is the IP address. You can get apache to listen on more than one IP and use as many certificates as you like. Anyhow, B could keep track of all of the order numbers it was sent by A, and if it was re-sent a duplicate could simply deny the whole transaction. Thus, if someone sniffed my encrypted "data burrito", and attempted to re-use it to gain access to B, they would fail, since B will only allow that burrito ONCE. Perhaps these order numbers could be GUID's. You can look at how payment gateways do this. There are basicly 2 ways: 1. postback - when user is redirected from B to A with the result status and order id, A asks B (rpc, simple get method, anything...) if the result is really what it got from the user. Check every important information - order id, amount 2. signing - site B computes a sign from important information of the transaction (at least order id and amount) and a secret key, and adds this sign to the redirect url that leads to site A. Site A can then compute the sign from the same values and check it against sign received from the server. In both cases you should also incorporate site id, so site A is not the only one that can use the interface of site B. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
Hmm.. Almost. If the shopping cart on site A submits to the secure CC processing page on site B, then the contextual data that describes the order (price, order number) was actually communicated from A to B via a hop at the users browser (likely via a hidden form field on site A). Thus it would need to be encrypted and urlencoded (otherwise anyone could hit "View Source" and see it all in plain text). Now, I suppose the shopping cart on site A could submit to itself, and then in that case, build up this encrypted data packet and then re-direct to the secure CC processing page (passing the encrypted data as a GET parameter. Is their any way to POST with a re-direct?). Ok. I think I have this all in my head now. On 11/9/05, Ben Ramsey <[EMAIL PROTECTED]> wrote: > > I'm posting this back to the list to keep the conversation there. I hope > you don't mind. My comments are at the bottom . . . > > > On 11/9/05 10:10 AM, Tony Di Croce wrote: > > The reason I even wanted to do this had more to do with sharing some > > data between two sites, and less with really maintaining a login. > > > > It occured to me that I need not "share sessions" at all. Instead, all > > of the data B needs could simply be encrypted by A and sent in a post > field. > > > > Now, this does bring up the problem that someone could sniff this > > packet, capture this encrypted packet, and use it to authenticate > > themselves on B. They never had to decrypt it, just capture from A, and > > send to B at their leisure... > > > > Let me give some background here on exactly what I'm doing, as it may > > clear things up a bit. > > > > B is a secure page, with a CC info form that when submitted will process > > their card, charging the amount of money passed in the encrypted packet, > > and if the charge succeeds, redirecting back to A. A would probably need > > to send an order number to B, and B could pass that back to A upon > > success or failure. > > > > All of this is to get around the Apache limitation of allowing only one > > virtual host to use SSL. > > > > Anyhow, B could keep track of all of the order numbers it was sent by A, > > and if it was re-sent a duplicate could simply deny the whole > > transaction. Thus, if someone sniffed my encrypted "data burrito", and > > attempted to re-use it to gain access to B, they would fail, since B > > will only allow that burrito ONCE. Perhaps these order numbers could be > > GUID's. > > > > How does this sound? > > I think someone else here could probably offer some better advice, but > here's what I would do. > > I would definitely use SSL when dealing with CC data, but I don't think > there's an Apache limitation that restricts the use of SSL to one host. > There is a limitation that restricts the use of an SSL certificate to > one host, so, if you had two certificates, both hosts could use SSL > sockets, but I don't think that's what you need here. (You could still > use the same certificate across multiple hosts, but then the user is > going to be prompted in the browser whether or no to allow the > certificate to be used, and this is generally not a good idea.) > > What you need to do is ensure that your FORM action on domain A (the > unsecured domain) is POSTing to https://domain-b.org. Note the usage of > HTTPS. This will ensure that the data is sent along the secure channel > and not in clear text. You don't need to perform any encryption, since > SSL takes care of that for you. > > Then, B could simply redirect back to A after processing the order and > pass the order number through the query string (since it's probably not > very sensitive). > > Does this answer your question? > > And, yeah, denying used order numbers would be a good idea. > > -- > Ben Ramsey > http://benramsey.com/ > -- for only the most hard core geekstas... http://geekstasparadise.blogspot.com
Re: [PHP] Re: Session's across Domains...
I'm posting this back to the list to keep the conversation there. I hope you don't mind. My comments are at the bottom . . . On 11/9/05 10:10 AM, Tony Di Croce wrote: The reason I even wanted to do this had more to do with sharing some data between two sites, and less with really maintaining a login. It occured to me that I need not "share sessions" at all. Instead, all of the data B needs could simply be encrypted by A and sent in a post field. Now, this does bring up the problem that someone could sniff this packet, capture this encrypted packet, and use it to authenticate themselves on B. They never had to decrypt it, just capture from A, and send to B at their leisure... Let me give some background here on exactly what I'm doing, as it may clear things up a bit. B is a secure page, with a CC info form that when submitted will process their card, charging the amount of money passed in the encrypted packet, and if the charge succeeds, redirecting back to A. A would probably need to send an order number to B, and B could pass that back to A upon success or failure. All of this is to get around the Apache limitation of allowing only one virtual host to use SSL. Anyhow, B could keep track of all of the order numbers it was sent by A, and if it was re-sent a duplicate could simply deny the whole transaction. Thus, if someone sniffed my encrypted "data burrito", and attempted to re-use it to gain access to B, they would fail, since B will only allow that burrito ONCE. Perhaps these order numbers could be GUID's. How does this sound? I think someone else here could probably offer some better advice, but here's what I would do. I would definitely use SSL when dealing with CC data, but I don't think there's an Apache limitation that restricts the use of SSL to one host. There is a limitation that restricts the use of an SSL certificate to one host, so, if you had two certificates, both hosts could use SSL sockets, but I don't think that's what you need here. (You could still use the same certificate across multiple hosts, but then the user is going to be prompted in the browser whether or no to allow the certificate to be used, and this is generally not a good idea.) What you need to do is ensure that your FORM action on domain A (the unsecured domain) is POSTing to https://domain-b.org. Note the usage of HTTPS. This will ensure that the data is sent along the secure channel and not in clear text. You don't need to perform any encryption, since SSL takes care of that for you. Then, B could simply redirect back to A after processing the order and pass the order number through the query string (since it's probably not very sensitive). Does this answer your question? And, yeah, denying used order numbers would be a good idea. -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
On 11/8/05 11:52 PM, Chris Shiflett wrote: When I've provided this feature in the past, I've always taken advantage of launch and landing pages - e.g., users could only get to the other domain and still be logged in if they clicked a link from my application, and those links all go through a launch page. This page takes care of generating whatever data I plan to send to the remote domain (including the URL that the user wants to visit) and redirecting the user to the landing page at that domain. With servers synchronized with ntpd, this lets you close the window of opportunity down to just a few seconds, strengthening the technique. I spoke to Chris a little further about this last night (so I'm crediting him with this), and I've noticed he hasn't responded, so I'm doing so. He said that, since the domains are on the same machine, it's relatively easy for them to share the same session id (something I wasn't disputing), and he offered a solution to mitigate exposure of the session id: a temporary token. Instead of passing the session id, create a randomly generated session token that is only valid for, say, 2 to 5 minutes. On the server, you can specify to which session the token corresponds, but you never reveal this to the client. You only reveal the token. Since it's only valid for a very small window of time, then, even if it is sniffed or appended to a URL (like in the linking examples I was giving), it won't allow others to use it to log in because it will have already expired. This alleviates the exposure issues I was discussing. Hope this helps. -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
Ben Ramsey wrote:
To me, it's not a question of whether the sites are physically
located on the same machine, and it's not a question of
encrypting the session id. Anyone who even knows the encrypted
session id could then POST it to the form in a replay attack,
authenticating themselves as the intended user.
You used a key word there - authenticate.
Sessions don't naturally exist across domains, so this problem is best
treated as an authentication problem - you want the user to have a
consistent experience, so you need to automatically authenticate the
user in order to do so. Techniques used to provide persistent logins
("remember me") can help here, except that you'll pass data in the URL
rather than in a cookie.
When I've provided this feature in the past, I've always taken advantage
of launch and landing pages - e.g., users could only get to the other
domain and still be logged in if they clicked a link from my
application, and those links all go through a launch page. This page
takes care of generating whatever data I plan to send to the remote
domain (including the URL that the user wants to visit) and redirecting
the user to the landing page at that domain. With servers synchronized
with ntpd, this lets you close the window of opportunity down to just a
few seconds, strengthening the technique.
I might try to write a more detailed spec for this at some point, but
hopefully that provides some good ideas. :-)
Chris
--
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
On Tue, Nov 08, 2005 at 11:32:33PM -0500, Ben Ramsey wrote: > On 11/8/05 10:27 PM, Tony Di Croce wrote: > > > >The sites are both physically located on the same machine. > > > >What if I encrypt the session_id, and put it in a "hidden" text input > >box in a form, that is delivered via POST to the other site. This way, > >the session id is passed, but it is encrypted? > > To me, it's not a question of whether the sites are physically located > on the same machine, and it's not a question of encrypting the session > id. Anyone who even knows the encrypted session id could then POST it to > the form in a replay attack, authenticating themselves as the intended > user. Also, hidden form fields aren't really "hidden." > > For me, it's a question of practice. I would not attempt to share a > session across to different domains. Even large sites (such as Yahoo) > don't seem to do this. > > Yahoo appears to maintain sessions across its subdomains, and, for this > reason, all Yahoo images are served from a completely separate domain > (yimg.com). None of the images served from yimg.com contain the cookie > headers associated with yahoo.com (and, thus, they are not associated > with any user sessions). There are two reasons (I know of) for doing > this: 1) bandwidth (less data passing across the HTTP headers), and 2) > it prevents CSRF attacks on Yahoo user accounts that could occur by > attackers serving images from a yahoo.com domain on other sites. 3) less headaches for the programmers for yimg.com Curt. -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
On 11/8/05 10:27 PM, Tony Di Croce wrote: The sites are both physically located on the same machine. What if I encrypt the session_id, and put it in a "hidden" text input box in a form, that is delivered via POST to the other site. This way, the session id is passed, but it is encrypted? To me, it's not a question of whether the sites are physically located on the same machine, and it's not a question of encrypting the session id. Anyone who even knows the encrypted session id could then POST it to the form in a replay attack, authenticating themselves as the intended user. Also, hidden form fields aren't really "hidden." For me, it's a question of practice. I would not attempt to share a session across to different domains. Even large sites (such as Yahoo) don't seem to do this. Yahoo appears to maintain sessions across its subdomains, and, for this reason, all Yahoo images are served from a completely separate domain (yimg.com). None of the images served from yimg.com contain the cookie headers associated with yahoo.com (and, thus, they are not associated with any user sessions). There are two reasons (I know of) for doing this: 1) bandwidth (less data passing across the HTTP headers), and 2) it prevents CSRF attacks on Yahoo user accounts that could occur by attackers serving images from a yahoo.com domain on other sites. I do know that Yahoo owns Flickr now, and I know that you are able to log into Flickr with your Yahoo account, but you cannot log into Yahoo! Mail and then go to Flickr and expect to be logged in. You must also authenticate yourself with Flickr. Now, you may notice and be tempted to point out that, when you authenticate yourself on Flickr with your Yahoo id, you are doing so from login.yahoo.com. This may be so, but Yahoo then passes some long "obfuscated" hash back to Flickr, where, I believe, Flickr is actually setting the session rather than sharing a session from Yahoo (someone else may correct me on this). This hash, however, is none other than a base64 encoded string that can be decoded like so: echo urldecode(base64_decode($var)); This does not, however, include your password information, or, if it does, it's even more securely encrypted in the values that you see when you decode it (as shown above). Neverthess, I could potentially (if I were stupid) paste the full Flickr URL to which Yahoo redirects me here and everyone of you would have immediate access to my Flickr account. Thankfully, it all happens in the background, so the normal user would never see this URL in their browser--it's all part of the HTTP Location headers redirecting them around. (Still not wholly secure, as I was able to see it and grab it, but it's more secure than exposing the URL to the user in the browser.) Still, I don't think Flickr is sharing the Yahoo session; it is, however, sharing the database information, I imagine. So, I say all that to say this: I just don't think it's a good practice to share sessions across two different domains. If you must share profile information, then (in my opinion) require authentication and a separate session on the second domain. Otherwise, use a subdomain to share sessions. -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session's across Domains...
Take a look at the PEAR sessionServer class http://pear.php.net/package/HTTP_SessionServer Tony Di Croce wrote: I have a server with a few virtual hosts. All of my scripts use "session_start()", and $_SESSION[] to share data between invocations of different scripts. The problem I'm having is that if a form on site A submits to a script on site B the values stashed in $_SESSION[] appear to be lost... Should this work? If not, then what alternatives exist? I suppose I could pass the session id as a POST argument to the site B script (and theirs probably a method in PHP that given a session_id() makes available all of that sessions $_SESSION[] variables) but is that the best way? td -- for only the most hard core geekstas... http://geekstasparadise.blogspot.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
On 11/8/05 9:32 PM, Richard Lynch wrote: Call me crazy, but the session_id is already going in/out through Cookie headers. So, really, it's not THAT much less secure for it to go in POST, and only nominally less secure to go in GET, is it?... Okay, you're crazy. ;-) j/k [Hey, Richard!] Yeah, it's going out through the Cookie headers, so a POST (in this case would be no less secure than sending it through the Cookie). A sniffer is a sniffer is a sniffer, as they say--or something like that. I was thinking more of a GET request to the other domain, which would require passing the session id through the querystring. Like you said, it's probably nominally less secure, but there's more chance for exposure. With Cookie and POST, the attacker would basically need to sniff for the person's session id in order to hijack it, but when you pass the session id through the querystring, users are prone to bookmark the page, send the link to friends, post the link to a Web site, etc., all the while exposing their session, and, in essence, forcing every user to use their session. This actually performs two kinds of attacks: session fixation and session hijacking. It's fixation because the user is forcing everyone to use the same session ID (even though they don't know they're doing this) and it can lead to session hijacking by people who know what's going on. There are ways to prevent this, such as always requiring authentication (by logging in) before performing a sensitive action and always generating a new session ID when a user logs in, but I think it's just as important to mitigate these types of attacks by reducing the exposure of the session ID as much as possible. Now, even on the other domain (domain B), it becomes difficult to know for sure that the user using the session is the proper user (from domain A). Sure, you can check the IP and an assortment of the headers the browser sends to get an idea about whether the user is the same one from the session on domain A, but I think it just makes sense to force the user to authenticate themselves again (assuming that we're talking about authenticated users). This ensures that the user using that session is the proper user, but, at this point, we can just create another session for domain B and not even worry about sharing the session. I guess some kind of cross-site scripting hack might read HTML but not Cookies, though, really, you'd think most XSS hacks would focus on cookies at least as much as HTML source... There is some argument in favor of not sending/getting the session_id back and forth AS MUCH just to give it a more fleeting existence on the wire for snoopers, but the difference between COOKIE/POST/GET data integrity/security from snooping seems negligible to this naive user. Maybe this is just a knee-jerk reaction to all the mis-information about POST being "more secure" than GET that floats all over the 'net. :-) Indeed, neither are secure, but GET increases the risk of exposure. [Hi Ben!] -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Session's across Domains...
On Tue, November 8, 2005 7:32 pm, Ben Ramsey wrote: > I think the approach here will need to err on the site of caution. You > don't want to pass the session identifier through the URL (or POST) > too > much because it risks exposure and the possibility for session > hijacking, though it should be possible to do this and grab the > session > information for the session id from the directory where sessions are > stored (often times this is in /tmp). I would advise against this for > reasons I've already mentioned. Call me crazy, but the session_id is already going in/out through Cookie headers. So, really, it's not THAT much less secure for it to go in POST, and only nominally less secure to go in GET, is it?... I guess some kind of cross-site scripting hack might read HTML but not Cookies, though, really, you'd think most XSS hacks would focus on cookies at least as much as HTML source... There is some argument in favor of not sending/getting the session_id back and forth AS MUCH just to give it a more fleeting existence on the wire for snoopers, but the difference between COOKIE/POST/GET data integrity/security from snooping seems negligible to this naive user. Maybe this is just a knee-jerk reaction to all the mis-information about POST being "more secure" than GET that floats all over the 'net. :-) [Hi Ben!] -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Session's across Domains...
On 11/8/05 7:50 PM, Tony Di Croce wrote: I have a server with a few virtual hosts. All of my scripts use "session_start()", and $_SESSION[] to share data between invocations of different scripts. The problem I'm having is that if a form on site A submits to a script on site B the values stashed in $_SESSION[] appear to be lost... Should this work? If not, then what alternatives exist? I suppose I could pass the session id as a POST argument to the site B script (and theirs probably a method in PHP that given a session_id() makes available all of that sessions $_SESSION[] variables) but is that the best way? This won't work due to obvious security reasons. A session cannot be shared across two domains, nor can cookies (though cookies can be shared across subdomains of the same domain). I think the approach here will need to err on the site of caution. You don't want to pass the session identifier through the URL (or POST) too much because it risks exposure and the possibility for session hijacking, though it should be possible to do this and grab the session information for the session id from the directory where sessions are stored (often times this is in /tmp). I would advise against this for reasons I've already mentioned. Instead, as I said, err on the side of caution here by annoying your users just a little bit. Here's what I mean: the multiple virtual hosts can share the same authentication/user profile database. Thus, users can log into each individual host and access the same profile. So, you'll need to authenticate the user when they visit a new host. This may be a decrease in usability, but it's an increase in security. For more information about sessions, read the manual: http://www.php.net/session -- Ben Ramsey http://benramsey.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
