Safari Preview Swamps SSO Server

Posted: May 17, 2012 in tech
Tags: , ,

Sometimes when I log in to my SSO console I would see a lot of sessions for a single user. I can understand three, four, even six, between restarting the browser and using multiple browsers. I do that a lot since I am responsible for the SSO system and have to check out the multiple ways of authentication. But the excessive sessions for a few users bother me. I mean excessive like 20 or 40. And for ME!

It’s not a big deal — the SSO server (CAMS by CafeSoft) could handle it. But I needed to know what was going on. What if this is something that needs to be fixed? A hole that needs to be plugged? Besides that, I try to save money where we can and sometimes we hit our licensing limit for development and integration/testing and I don’t want to have to buy more seats if we do not need them.

By process of elimination I was able to narrow it down to either one particular browser or the Kerberos authentication that it was configured to do. I had been watching the logfiles to see the requests that were made and redirected to the authentication links, the unique session id assigned to it… and then nothing. That sessionId was never used. There was no success message logged with that session ticket.

Now it was time to get sneaky and figure out what the browser was doing. I was already thinking that it was related to the browser pre-fetching things to try and be faster. So I killed my browser and had another admin remove all my session from the system. With Wireshark running and capturing everything for my server subnet I launched Safari again and followed my Usual Methods.

  1. Launch browser, type over the address bar with the address of my dev server
  2. Admin in other room constantly refreshes and reports no new sessions as I am typing the address. That shoots down my initial thoughts of pre-fetching.
  3. I hit enter and observe the usual redirects and invisible kerberos login
  4. My assistant from the other room reports I now have one session. Everything is perfectly normal
  5. I begin typing on the address bar for a slightly different space on same server but different Apache virtual host and eventually hit enter. My assistant reports still only one.
  6. Launch new tab– Eureka! Assistant reports I now have sixteen sessions.

So… Safari is configured to display the “Top Sites” thumbnails in a new tab. And those “Top Sites” are not built based on cache but with new requests. Whaaaa????
Safari Tabs setting

It gets worse.

Remember I had Wireshark capturing in the background while I was doing this? I examined the packets and was able to determine what was going on. I see Safari making the request and the server responding with the 302 HTTP code to be redirected to the kerberos login page.

GET /CamsConsole/sessions/ HTTP/1.1
Host: *****.********
X-Purpose: preview
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8)
AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5 Safari/534.55.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Thu, 17 May 2012 16:04:36 GMT
Set-Cookie: BigIPDensitySecure=604176650.37663.0000; path=/
Vary: Accept-Encoding, User-Agent

There are several interesting things to note in this request. First – there is a special HTTP Header being used by Safari, X-Purpose: Preview. Second, there is a very notable lack of other HTTP headers. In fact, you could say just the basics of compression, the Agent, and KeepAlive. That last one is important by the way at figuring out what is going on.

There is one important clue in the reply from the webserver and it is not really that obvious until you look at the later packets.

When you filter a conversation in Wireshark it makes a new filter for stream=xxx to show you everything in that conversation. With most HTTP servers this stream can be open for a 100 requests, five minutes, or something in between. It’s all negotiated between client and server. This is part of the function of the “KeepAlive” header, it is the client telling the web server, “Hey, I support keeping this session open if you do”. So it stays open for further requests.

And if I thought I was done looking at everything that my browser was doing I would miss some other details. Because this conversation keeps repeating. Several times. Exactly the same.

So I clear the Wireshark filter to restore all the conversations to see them as they happen by time. The very next stream is the request to get logged in via Kerberos. I’ll try to keep this long post short and summarize — the browser says give me “this”, and server says “401- please login with ‘Negotiate’, and here’s your BigIP cookie”, and browser says “hey, I have ticket, here you go”, and the server says “OK, here’s your SSO cookie and here’s your BigIP cookie”.

And then I see that again. And again. Several times over multiple streams just like the original stream. And meanwhile the Cams authentication service creates a new session for me. And again. And again. As long as it keeps doing it.

And that is when it hits me. The Safari X-Purpose Preview function does not utilize cookies. It seemingly does not accept, keep, track, or submit any cookies. It never sends the BigIP or SSO cookie.

It’s just going to fill up my logs with useless new sessions and deplete my available licenses.

I’ve been scripting a lot of fancy things into our F5 BigIP LTM-1500 lately and this seems like another perfect way to solve this little problem. A simple iRule applied to the virtual server instance can intercept the HTTP Request before it even goes to the web server.

This iRule goes up near the top of the other iRule items (before any ProxyPass iRules if you use those) and acts on HTTP Requests only. When it detects that Safari header it responds with a 200 and a short message and never ever goes to the web server, Cams, or passes Go.

Haiku Preview Message

Haiku Preview Message

Yes.. I did wax a little more poetic than absolutely necessary, but that white box in the picture above is my short and quick way to stop Safari Preview from depleting my development Cams licenses.
iRule script download

  1. volkerk says:

    So which Safari bug did you file in response to this excellent discovery?

    • kevincreason says:

      I have not made a bug. I am still sitting on the fence. I can understand why they chose to do it this way for a variety of reasons. Yet the unintended results can be an issue they need to know about… So I really should. Are you seeing the same type of thing?

      • volkerk says:

        Oh yes, we do see this at many of our client sites – and the same issue will arise with any appserver that manages sessions via cookies (=pretty much anyone). The redirect loop resulting from the lack of cookie support amounts to a DoS attack, so I’m thinking about filing a CVE too. On the other hand this isn’t a clear-cut issue – cookie support in the user-agent may have been intentionally disabled by the user, and sites should technically detect whether the user-agent supports cookies BEFORE creating a session. And earlier versions of Safari did actually use cookies in the preview requests, which led to complaints about artificially boosted Slashdot rankings etc. Just goes to confirm again that things are rarely as simple as they seem at first glance.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s