Kill the session

I was sitting at my desk when one of the teaching directors came in and said, “We have a huge problem!” I asked her what was the problem. Here are the main points:

Special Education teachers use a web based program to track special ed kids and their progress.
The program allows them to create meeting invitations for parents. The invitation is a Word document that must be downloaded and then emailed to the parent.
One of the special ed teachers inadvertently emailed the web page. The teacher had copied the director on the email. When the director opened the HTM page, she was able to get into the special ed site without having to log in.

So, the problem boiled down to the fact that the parent could open the file and be able to see every kids personal information. The information available included SSN, home address and parent contact information. I asked for a copy of the file so she went back to her office and forwarded the email to me.

I opened the file and verified that I could see information for several students. The good news is that it was only for the students at one particular school. Since the site opened on my computer and I had never logged on to the site before, I figured that the web site used sessions to maintain logins. I looked at the source code of the file and couldn’t believe it. The session URL was actually embedded in the code. That means that if they clicked a link to go out to another site, say Google, then the referral URL would have the session information as well.

I told the director to call the teacher and have her log off the site. She did that but the file still opened the site. It turned out that the teacher had closed IE without logging off the site the first time. A new session ID was given to her when she logged back on to the site so logging off did nothing to the original session.

Fifteen minutes had passed since the email went out. The director was panicking because she was afraid the parent may have already opened the file. That could mean a lot of trouble for the school system. I opened the file again and noticed that it flashed a timer in the status bar showing that it would auto-log off after 60 minutes. Sixty minutes was too long to wait for the session to automatically close.

I looked on the page for a logout button to kill the open session. I couldn’t find a logout button on the first couple of pages I checked. How could they not have a logout button on every page? I called the director and asked where the logout button was. She told me how to get to it (four clicks?!) and I clicked it. That worked because now, every time the page was opened, I received an error stating that the page was invalid as my session had expired.

I called the director and had her try it. She said, “It’s still working! It asked for my password.” She had opened the page using a shortcut from the IE favorites menu. I told her to try the page that was emailed. When she did that, she said, “Oh thank you, thank you, thank you! How did you fix it?” I told her that I just clicked the logoff button on the page and that killed the session.

The sad part is that the program is used by several school systems so there’s no telling how many other teachers made the same mistake. I don’t see why they embed the session information in the web page instead of using a cookie to store the session information.

Idealism is what precedes experience; cynicism is what follows. - David T. Wolf

20.Dec.07 Security