[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1889.65.128.224.203.1064538261.squirrel@mail.solo.net>
From: newsfeed at solo.net (David A. Koran)
Subject: Verisign Login Hijacking
Sure enough, this works under most of the browsers I've tried, and at
least shows the pittfalls of not cutting your session cookies short, or at
least periodically killing, at least, login cookies. Damn, even Microsoft
does a better job of it. Dotster and others don't seem to have this
problem with session expiration. There are obviously better ways to keep
session state between machines, even under SSL. A former employer had me
manage that through a Cisco/Arrowpoint CS series content switch, and it
worked like a charm, and we didn't expose login sessions, plus the perl
proxy code handled authorization and other session keys on the backend
through a database.. simple enough idea. I wonder if this poor programming
extends itself to their server for signing up and managing digital
certificates...
Well, if anybody gets a hold of a good spoofed URL, I'm sure we'll see the
UN, CNN, NyTimes, or other sites bumped off the map (not just web traffic
but entire domains) by unauthorised redirections. I'm sure with enough
effort, you can pick the salt up for the session keys and start generating
your own logins.
I'm not notifying Verisign, I think it's up to them to come to us. Just my
personal opinion...
Really, didn't these guys take a class in programming for the web, even a
distributed systems class would have tought them to bump down and ticketed
session down to 5-10 minutes at most. Wouldn't you hash the session with
an originating IP or something to make sure the session can be verified
and not hijacked? Most folks would rather close the browser window than
logout, thus keeping the server session active.
Powered by blists - more mailing lists