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 <ramsey@xxxxxxx> 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
