[Sorry for the re-edit, a co-worker pointed out a small problem in my grammar]
In my day job (at a nameless fortune 500 company). I work on a top secret app that let's the executives of the company monitor different aspects of the company globally.
It's the type of thing that our security department worries about... Suffice to say we have multiple locks on the door... (it wouldn't be easy to hack into...) The site (yes, unfortunately it is a web site.. and not an Intranet site) is primarily ASP (with a tiny bit of COM)
That said, I recently added a section of the site that is ASP.NET. The key portions of a user's credentials are stored in the asp session. So one of the major items I needed to conquer was to transfer asp session to asp.net session. Initially I tried the method mentioned in this article... I thought I had it made. I simply detected when session needed to be transferred (which is going to be in only 2 pages), and simply posted the session to the other page. I added checks to make sure that the HTTP referred was my transfer page and I was all set... right?
WRONG! One of the things I have learned is that Security is an ongoing process. You either are secure everyday and you analyze your code for security flaws or you are only partially secure. Vigilance is your best friend. If something seems like it might be susceptible... you should minimize the window of opportunity/ the level of attack, etc. And you should NEVER be satisfied!
OK, so here is what is wrong with the above strategy (in case you don't already know). HTTP Referrer can be spoofed... I did a search on it to see how secure it was only to find that it can be spoofed... ouch! BTW, in case you don't get it... if I can spoof together a transfer page operating elsewhere and post to the receiving page on the secure site... then I can effectively login as the president of the company and see everything there is to see (BTW, there are other safeguards that go way beyond what I'm talking about, but I didn't want someone inside the company to be able to bypass the security using spoofing).
I read on article on MSDN that suggests that you write a COM object in .Net and use it from ASP (well, this is not 100% accurate, but do a search on MSDN I'm sure you'll find the article). Their idea may or may not work, but for me going through that level of ripping apart of my asp site didn't sound appealing to me. (there's also a cool article by Billy Yuen that describes the approach I took)
So what did I do? I went back to my transfer pages. For my particular efforts I decided to use XML as a format for the session (although there are variations on this theme that would also work).
1) if there is no session when I'm in a transfer page the user goes back to login.
2) if there is a session I "serialize" the session data into XML, and stuffed it into the database which in turn gives me back a GUID (which is the Row Identifier). BTW, I use Stored Procs
3) I stuffed this GUID into a cookie and sent it back to the other side (either ASP or ASP.Net).
4) The receiving page uses the GUID (if there's no GUID and the referrer was the transfer page then the user goes to login) to lookup the XML doc in the database.
5) it re-creates the session, and then deletes the row in the database (it also cleans up any old sessions.
This is not perfect, but I can live with it. I use the native session objects in both environments and my window for being hacked is about half a second (obviously the one flaw is that session data could get abandoned in process)...
BTW, my ideas are not entirely my own, but one more article on this subject could not hurt... it took me a long time to figure this out completely (because security was the key concern).
| posted on Wednesday, April 14, 2004 11:42 PM