|
|
Posted by Oli Filth on 11/14/05 20:52
Marcus said the following on 14/11/2005 18:38:
> I think I just figured out the reasoning...
>
> Oli, in response to what you said, I believe we don't want to just store
> the user agent in the session in plain text because if an attacker were
> to hijack the session, he would easily know what user agent to spoof in
> order to trick the system into thinking he is the legit user.
>
> Even with the md5 representation, I don't think it would be *that*
> difficult for an attacker who was motivated to supply the correct user
> agent for a compromised session, although obviously it would be more
> difficult than plain text.
>
> I believe the reason for padding the fingerprint with extra data is so
> that if an attacker does in fact hijack a session, it would be tougher
> for him to reverse engineer what the user agent is from the saved
> fingerprint (as opposed to plain text or the md5 of just the browser).
But a hacker doesn't have access to the saved fingerprint, because it's
saved server-side. It never leaves the server. So encrypting it, etc. is
pointless.
The only exception to this is if the hacker has actually somehow got
access to the session data folder on the server, but if he has that
level of access then you're buggered anyway.
Regardless of how the user-agent string is stored server-side, the input
to the session "validation" routine is simply the plain user-agent string.
Either the hacker knows the user-agent-string or he doesn't, so IMO what
happens behinds the scenes is completely irrelevant.
i.e. if you have some string X, and want to validate it against string
Y, it doesn't matter whether you do:
if (X == Y) ...
or:
if (f(X) == f(Y)) ...
> Someone please correct me if I am wrong, but as far as I know md5 is a
> one way function, i.e. we can't reverse it and come back to our original
> string.
This is true.
--
Oli
Navigation:
[Reply to this message]
|