Retarded web security
iEmployee.com is written by some not very bright people. Forget that the damn thing has to be hacked to work in a browser other than IE.... I can get around that.. whatever.
Their whole session security relies on a session ID in a url. That's right.. knowing the URL you can get into someone elses session. That site contains nice things like my social security number, address.. date of birth.. employment information (after all it's an HR company).. why do they even bother with ssl if this is their idea of a security model?
I think I'll suggest at work we drop these morons.
Considering the kind of information they provide online, wouldn't security be a top priority? Pretty please?
Comments
If any part of that is your medical information (insurance coverage, etc.) point out that it's a HIPAA violation which can get them Serious Federal Pimpsmacking if the data is even *capable* of being compromised.
Posted by: Derek | July 5, 2004 01:25 AM
Isn't that pretty much the same as relying on a Java HttpSession? Afterall, jsessionid is either a cookie or a url parameter, guess that and I have your session.
Posted by: Michael Koziarski | July 5, 2004 05:51 AM
Yes.. pretty much, although it's about 2 minutes more work to fake a cookie... There are better ways of ensuring sesssions aren't easily hijacked.. like hash ip, browser info.. gives it a touch more security.
Posted by: kasia | July 5, 2004 09:21 AM
Are you saying that the problem is "Session ID in a URL" or "insufficient protection against hijacked session IDs"?
Posted by: Steve Friedl | July 5, 2004 03:07 PM
The problem is insufficient security. Session ID in the URL wouldn't be an issue if there was some protection against hijacking it.
Posted by: kasia | July 5, 2004 03:14 PM
Does "knowing the URL" not imply the same level of security as "knowing the root password"? The size of the key-space for session id's is sufficiently large and if the session id only gets sent over SSL, what's the issue? Someone guessing it? I don't understand your concern.
Posted by: Morten | July 5, 2004 04:10 PM
Have you actually confirmed that the session ID can be used from any browser from any IP? If they are checking these things on the server there is nothing to be gained by hashing the information and using it as the session ID. Any method of implementing sessions for HTTP is nothing more than an ugly hack.
Posted by: Anthony | July 5, 2004 05:40 PM
Yah.. I wouldn't have posted this otherwise since it wouldn't have been a problem, would it?
Posted by: kasia | July 5, 2004 06:37 PM
Meow! Look at Kasia go ;)
Valid point all round though - if all that's necessary to fake a log in is a "cut and paste" of a legitimate one then its extremely flaky. Given the amount of packet sniffing activity going on in the real world, and the nature of this site, it would be possible to get some pretty significant data if so were so minded.
Posted by: Ant | July 6, 2004 10:26 AM
Is the thing running over SSL? If so, what's the big deal?
Posted by: Mark | July 6, 2004 02:27 PM
Even if you do drop those morons, make sure you get them to remove the information from the system; they sound like the kind of people who would just leave it in there rather than getting rid of it.
Posted by: Timothy McClanahan | July 6, 2004 07:36 PM
Packet sniffing won't work if its SSLinized since the URL is encrypted in transit as well (or so when I last read SSL documentation).
I might not have my head straight on. So feel free to give me a kick if i've been reading those docs backwards.
Posted by: david | July 6, 2004 07:49 PM
This is crap - for one, IE is run in 96% of computers in the world, so I get sick of the whiners saying everything needs to work on Nutscrape - Netscape is SO inferior programatically. They were the best once, but get out of the 90's people, Netscape is dead.
As for their security, I'm willing to bet you couldn't 'hack' their security if you tried for a year - you're just talking smack about something you have no clue about, obviously.
Posted by: formation X | July 9, 2004 08:45 AM