Lets start in the simple scenario:
first session_id = 1, next session_id = 2, ...
Too simple, yes.
But tomcat digests the incoming random number (in this scenario, its not random, its sequential) using SHA1. So the incoming "random" number is transformed into a wicked long string. The string can't be transformed into its original number because ... well thats the way message digesting works. I don't understand the math theory behind it. (Thankfully - I don't have to)
So in this scenario, tomcat generates (hypothecially):
1 --> A3BED12F80B5CF1CB8C3A9359888BBD9
2 --> 898EF7B975B13E527856E8F3C6F30DAC
..
The nice thing about the digester is similar incoming data 1,2,3,or "timmy","tommy","tammy" will all be transformed into vastly "different looking" strings.
Without knowing the algorthim that performs the transformation, using a sequential number as the source input is reasonably OK. Security through obscurity - woohoo.
But tomcat is open source (or lets say someone "peeks" at the source). Now someone knows the algorithm. There is only one way to determine the source random number: brute force (since the transformed string can't be "un-digested" into its source input).
Since I know the algorithm - I can brute force all numbers until I get a sessionId match. I can make things easier by guessing where to start my guessing of numbers by estimating your site traffic. Or the source code might provide hints on where to start. ("Seed sequential number to 0 on restart - or current time in milliseconds on restart") Creating a new session id is not extremely cpu intensive, so I could probably determine the source number pretty quick. From there I would try to obtain another session id. Then use brute force that to get derive the second input source number. From there I can start guestimating what sessions are available. And if I keep enough notes, future attacks will be easier because I would have good estimations on where your source input number is.
By using a using a random number, my attacker can brute force the sessionid to get the source random number. But the next number out of the randon number gen is ... random. So the attacker can't easily guess session ids. But this is also based on the assumption the random number generator does is a "good one" since all computer random number generators are not random. (Use google to get more info on that).
Anyone - please slap me up side the head if this is in anyway incorrect.
-Tim
Jon Scott Stevens wrote:
on 2002/12/24 5:52 AM, "Tim Funk" <[EMAIL PROTECTED]> wrote:I hope you were joking about the monotonic increase of sessionIds. If that were done - it would be trivial to steal another's sessionId by guessing.
How is that?
laskdfowifjwo2i3jofij2oi3jofwjieogih934htwo4i1
io2oiwejofiwjoijr9238jr9iejofij2oi3jro23ij2i32
Aslkdjfalskdjflaksjdflkasjdflkjlsdkjflaskjdfl3
lakdjflkasjdflkjwoeirjowiejo2ij4o3ij4o2i4o3jo4
flaksjdflksajdflkjsdlfkjsdlkfalsdjflasdkflksd5
laksdfjlkasjdflaskjdflksjdfowiejreowiefjowiee6
The only problem with it is that the session id would grow in length as more
digits are added. I don't see how adding a number would make things more
easily to steal (as long as the first part is unique random garbage), but
maybe I'm missing something. It would be best to do something like this:
SHA1(laskdfowifjwo2i3jofij2oi3jofwjieogih934htwo4i1)
SHA1(io2oiwejofiwjoijr9238jr9iejofij2oi3jro23ij2i32)
SHA1(Aslkdjfalskdjflaksjdflkasjdflkjlsdkjflaskjdfl3)
SHA1(lakdjflkasjdflkjwoeirjowiejo2ij4o3ij4o2i4o3jo4)
SHA1(flaksjdflksajdflkjsdlfkjsdlkfalsdjflasdkflksd5)
...
SHA1(laksdfjlkasjdflaskjdflksjdfowiejreowiefjowiee600)
So that you always have a uniform length.
Just trying to learn...
-jon
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
