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?
TrackBack URL for this entry: http://www.unix-girl.com/mt/mt-tb.cgi/1265
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.
#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.
#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.
#Are you saying that the problem is "Session ID in a URL" or "insufficient protection against hijacked session IDs"?
#The problem is insufficient security. Session ID in the URL wouldn't be an issue if there was some protection against hijacking it.
#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.
#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.
#Yah.. I wouldn't have posted this otherwise since it wouldn't have been a problem, would it?
#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.
#Is the thing running over SSL? If so, what's the big deal?
#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.
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.
#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.