|
Posted by Marcus on 09/25/56 11:28
Gordon Burditt wrote:
>>Thank you for the detailed response, it helps greatly. With regards to
>>the session handling and SSL, I am not concerned about my data really,
>>as I am not dealing with any financial data or anything that is very
>>personal info at all. The only sensitive info is passwords, and those
>>pages are SSL'd.
>>
>>My concern is this - I am obviously not 100% sure about all the details
>>of session handling, but my concern is that if someone is able to hijack
>>a session via whatever method, perhaps packet sniffing and getting the
>>session id, wouldn't this person then be able to take over the user's
>>existing session and function as that user?
>
>
> Yes, assuming you don't ask for authentication information again
> when doing sensitive changes. But remember that if someone is able
> to guess the user's *password*, he can do that also, and he may be
> able to continue doing that for years, as opposed to a session,
> which hopefully doesn't last very long.
>
> Which do you think is easier to guess, a user's session ID or a
> user's password? Take a look at the session IDs generated on
> your system and the length of typical user passwords actually
> selected by real users.
>
>
>>In other words, the
>>attacker could function as if he/she were the user and potentially
>>delete important data that the user has authority to delete, but does
>>not want to delete. To me, someone gaining access to someone else's
>>session could wreak havoc, even if there is technically no sensitive
>>information at stake. Am I reading too much into this?
>
>
> People won't bother trying to hijack sessions if they can guess
> passwords. Users tend to choose lousy passwords. On the other
> hand, session code tends to choose randomized session IDs.
>
> What is the threat here? Would someone spend days trying to sniff
> session data to delete user info which the user could re-type-in
> in 10 minutes? Why? If this is a forum for something like IRC,
> where just logging in can attract an attack, and in-person meetings
> between people on the same IRC channel are likely to involve automatic
> weapons and cluster bombs, if not suitcase nukes, I can see the
> problem.
>
> Gordon L. Burditt
Gordon,
I see your point, I think I will just re-generate the session ID after
every user request so that the last session ID is no longer valid.
Hopefully that will provide enough security for the non-SSL'd pages.
My last question is this: I read online that you should never pass
session data between http and https servers. I have successfully
carried sessions between the two without passing any information in the
URL... since I know this can be done, is there a reason not to do so?
Does it expose any other security risks I am not aware of?
Navigation:
[Reply to this message]
|