On Mon, Jul 13, 2009 at 9:15 AM, Bob McConnell<r...@cbord.com> wrote:
> From: Daniel Kolbo
>> Daniel Brown wrote:
>>> On Sun, Jul 12, 2009 at 12:37, Daniel Kolbo<kolb0...@umn.edu> wrote:
>>>> Hello,
>>>> How does one continue a php session on a different domain (domain B)
>>>> than the domain (domain A) that started the session?
>>>     Simple answer: you don't.
>> Thanks for the responses.
>> Re: Simple answer
>> I thought of another example.  My bank's website.  I sign-in and
>> authenticate with "bank.com".  Then, i click credit card from bank.com
>> and i'm redirected to "creditcard.com" without me having to reinput
>> user/pass.  They clearly do it (granted they have a lot more resources
>> then I do, but i'd still like to know how they are doing it).
> My bank also does this, but it only works if Javascript is enabled when
> I first log in. Otherwise the initial login fails and I do it again on
> the second site. I haven't actually looked at the page sources to see
> what they do. But I have NoScript configured to block all JS by default
> so the initial login attempt always fails. It also reports blocked XSS
> attempts on both pages. So whatever they are doing does not appear to be
> very safe.
> Bob McConnell

I have seen cases where site A to renders a form whose action points
to site B with credentials for site B in hidden form elements. Since
there are no visible UI elements, it requires Javascript to trigger
the form to submit itself. If the credentials are simply the username
and password, this seems pretty insecure to me.

I'm not sure how much more secure you can make it if you use a
one-time token (possibly one that encodes the client's IP address with
some other server-side information into a hash?). For this to work,
the two systems would have to be able to communicate either through
shared data storage or some sort of behind-the-scenes web service.

It can also fail in cases where the form processor on site B depends
on some previous state being established with the browser (for
example, a particular cookie that must already be set, or only
accepting posts with a "valid" HTTP_REFERER value) before posting the


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to