[cdavisonnucleus.com]

| There are practices that can keep you safe from session hijacking,
| and none of them involve using a cookie instead of GET or POST
| data:

Nobody has talked about POST data in this thread. It is the GET data
that cause problems.

| A. You need to delete session IDs when a user logs out

Yes, but the session-id is still valid as long as the user is logged
in, or as long as the session is valid if the user forgets to log out.

| B. You need to expire session IDs after a period of inactivity

Yes, but the session-id is still valid as long as that period of
inactivity is not reached. And the period of inactivity will be
extended if the attacker uses the session-id.

| C. You have to make sure that session IDs are unique to the session
| and not to the credentials or IP address

I'm not sure I understand this. The session-id should, of course, be
a large random number (preferably cryptographically random) that
doesn't match any other existing session-id.

| Other Safeguards:

| D. You may want to tie the session ID to the user's IP address

In many cases that won't help. I've been a customer of a Norwegian
ISP that used a transparent proxy for it's thousands of users. Any of
these users could hijack the other users' session even if that
constraint was put into place.

And AOL (and possibly others) use load balanced proxy servers: One
user may legitimately come from several IP addresses during a single
session. (I'm not sure how that would work if SSL/TLS was in use.)

| E. You may want to change the session ID between pageviews - i.e. a
| freshly generated page will update the session ID on the
| server, and every link and form on that page will point to the
| new ID

That would help a lot, but users who (like me) often have several
browser windows at the same site open at once would be frustrated.
And it wouldn't help that lot either: If the attacker is fast, he may
do a _real_ hijacking, meaning that he would take over the session
entirely, making access impossible for the victim. The earliest bird,
and so on.

| There are other hints that will keep your sessions reasonably safe.

What are those? I can't say I find the above hints reasonably safe,
so I would really like to hear the other ones.

| What the other poster was trying to say is that you haven't made
| the session ID any more secret by putting it in a cookie - the
| method of transfer of the sessionID is irrelevant. Instead of
| constructing a GET request with your session ID, the attacker w

Something got lost here I guess, as I see an incomplete sentence. I
would nevertheless like to say this: A cookie may be stolen using
packet sniffing. That can be avoided if the server demands SSL/TLS
(and the browser isn't buggy, which seems to be a problem these days).
A cookie may be stolen by Cross-site Scripting. That can be avoided
if the server does proper HTML encoding of _all_ output.

URL parameters, on the other hand, show up in Referer logs on
third-party sites, in proxy server logs, and in the browser's history.
Those three troubles are most easily controlled on the client-side. I
_still_ see cookies as more secure than URL parameters, as the former
leave more of the security to the server side.

If you can prove that GET is as safe as cookies (HTTP headers) when it
comes to secrets, you should really try to make those HTTP people
rewrite their RFC.

Sverre.

-- 
shhthathost.com		Computer Geek?  Try my Nerd Quiz
http://shh.thathost.com/	http://nerdquiz.thathost.com/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]