1

I wonder if anyone can suggest an answer here:

We have a system which is secured using PHP sessions (and other measures such as SSL, before anyone starts talking security at me!) and we want to send out direct links into the system via email, when contacting clients about specific issues. The links we send out include GET parameters.

Our advice has been for the client to make sure they're logged in, then click the link - the link launches in the browser, picks up the session, and takes the user straight to the required page. However, this doesn't work when the user clicks the link from a Microsoft Office application.

When clicking the link from Outlook (or indeed, Excel) the session variable is not picked up, and the user is asked to re-authenticate. Digging a bit further, it appears as though the request is coming through with user-agent set to Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0E; .NET4.0C; ms-office) but the site is launching in Chrome (which is also the browser where the session is set). I wonder if there's some session-security code kicking in, saying that if the browser is different, the session must be spoofed?

Trying to get around this, I tried setting up a redirect page for the initial page-load: 

if (isset($_GET['targetpage'])) {
  // It's a GET request - redirect using header-location
  $all_get = $_GET;
  unset($all_get['targetpage']);
  $redir = $_GET['targetpage'].'?'.http_build_query($all_get);
  header('User-Agent:');
  header("Location: {$redir}");
  die();
}

This fails: the request still comes through with the User-Agent set, and the session is absent.

Any thoughts/suggestions?

almcnicoll
  • 405
  • 3
  • 21
  • So what user-agent do you see AFTER the redirect? Is it empty, does it still contain MS-OFFICE, or has it become normal again? – nl-x Apr 10 '13 at 10:36
  • @nl-x, the user-agent comes out as the ms-office one, however when the session is not found and the site redirects to the login page, that request is made using Chrome's user-agent string. – almcnicoll Apr 12 '13 at 09:45

2 Answers2

1

Don't do header('User-Agent:'); ... as this will give an empty user-agent, while in the subsequent request, the normal user-agent will again be used.

And you could try different HTTP 30x codes ... I know browsers tend to behave differently depending on the exact 30x code used.

nl-x
  • 11,762
  • 7
  • 33
  • 61
  • I like this idea, and may try it shortly. My concern is that behaviour across browsers (or perhaps, across office versions) will not be consistent. – almcnicoll Apr 12 '13 at 09:46
  • By the way. You send a link with some kind of hash I presume that you check on the first page and create a session for? Correct? Then it fails on the first next page? Correct? Why not send the hash... Then on the first page, redirect to the second page sending along the hash but WITHOUT creating a session. And then on the second page check the hash and create the session? – nl-x Apr 12 '13 at 10:27
  • Actually, no - that's possibly a little more complex than what's in place. When users log in, they get a straight PHP session; the links that I'm getting to work need to be perpetual, so they simply pass in a reference to an id of what they're looking up. They need to be generated at a time when there is no session present, so I can't hash anything to do with the session into the link, nor can I spoof the login because it could be any user clicking the link. – almcnicoll Apr 12 '13 at 13:01
0

This is only a partial solution, but for me it counts as good enough.

Use of our site requires JavaScript to be enabled, so I don't really have to worry about users with js disabled. I have put on a JavaScript redirect, with a "click here if not redirected" link, and that appears to be sufficient.

almcnicoll
  • 405
  • 3
  • 21