How to test session identifier strength with WebScarab - Revision history

Paco: /* Caveats on Predictability and Randomness */

2007-01-08T14:13:08Z

‎Caveats on Predictability and Randomness

Paco: /* Plotting the results in an external program */

2007-01-08T14:10:02Z

‎Plotting the results in an external program

Bholuguard-torrentmatrix: /* Collecting session identifiers */

2006-12-26T05:35:38Z

‎Collecting session identifiers

Paco: /* Looking at the graph */

2006-11-03T03:29:47Z

‎Looking at the graph

Paco at 03:09, 3 November 2006

2006-11-03T03:09:29Z

RoganDawes: Added a worked example showing how the calculations are done

2006-10-31T17:13:20Z

Added a worked example showing how the calculations are done

Mlandis: /* Collecting session identifiers */

2006-09-15T17:40:46Z

‎Collecting session identifiers

Jeff Williams at 00:57, 27 May 2006

2006-05-27T00:57:11Z

Rdawes at 05:24, 24 May 2006

2006-05-24T05:24:13Z

Rdawes at 05:23, 24 May 2006

2006-05-24T05:23:28Z

@@ Line 99: / Line 99: @@
 === Caveats on Predictability and Randomness ===
-Predictability and randomness are relative terms. If the algorithm appears to be "predictable", but the key space that you'd have to check is greater than about 100000 items, it is likely to be infeasible to actually find a session belonging to someone else during that session's lifetime. Obviously, this depends on your own CPU power, network bandwidth, the target's CPU power and network bandwidth, the typical lifetime of a session, and a bunch of other factors. Please look at the scale of the numbers before deciding that an identifier is predictable.
+Predictability and randomness are relative terms. If the algorithm appears to be "predictable", but the key space that you'd have to check is greater than about 100000 items, it is likely to be infeasible to actually find a session belonging to someone else during that session's lifetime. Obviously, this depends on your own CPU power, network bandwidth, the target's CPU power and network bandwidth, the typical lifetime of a session, and a bunch of other factors. Please look at the scale of the numbers before deciding that a predictable identifier is a realistic risk. It is possible for something to be "predictable" in the strictest mathematical sense, but not exploitable in a practical sense.
 One very important thing to note about the conversion algorithm is that it works from right (Least Significant Bit) to left (Most Significant Bit), much as one would expect from a numerical conversion. What this means in practice is that if you have a session identifier that has some sequential data at the left, and significant random data to the right, the sequential data will appear to dominate the values, and will result in a straight line graph. Again, check the scale of the numbers before deciding that an identifier is predictable.

@@ Line 78: / Line 78: @@
 <dl>
-<dt><b>/^(\d+)/</b></dt>
+<dt><b>/^(\d+)/</b>
-<dd>Match some digits beginning at the beginning of the line.</dd>
+<dd>Match some digits beginning at the beginning of the line.
-<dt><b>strftime("%m\/%d\/%Y %H:%M:%S",</b></dt>
+<dt><b>strftime("%m\/%d\/%Y %H:%M:%S",</b>
-<dd>This is the format for the time to come out. Notice a couple things: It doesn't have the fraction of a second (that is done separately) and it has backslashes to escape the forward slashes in the date. Otherwise those forward slashes would confuse the regular expression parser.</dd>
+<dd>This is the format for the time to come out. Notice a couple things: It doesn't have the fraction of a second (that is done separately) and it has backslashes to escape the forward slashes in the date. Otherwise those forward slashes would confuse the regular expression parser.
-<dt><b>localtime($1\/1000)</b></dt>
+<dt><b>localtime($1\/1000)</b>
-<dd>This is where we take the number we found on the beginning of the line and divide it by 1000. That way, we get Unix seconds, which <tt>localtime</tt> likes.</dd>
+<dd>This is where we take the number we found on the beginning of the line and divide it by 1000. That way, we get Unix seconds, which <tt>localtime</tt> likes.
-<dt><b>. "." . ($1 % 1000)</b></dt>
+<dt><b>. "." . ($1 % 1000)</b>
-<dd>Take the output of the <tt>strftime()</tt> call and append some stuff on the end. Namely, a literal "." and then the milliseconds value from the time.</dd>
+<dd>Take the output of the <tt>strftime()</tt> call and append some stuff on the end. Namely, a literal "." and then the milliseconds value from the time.
 <p>That's it! It's not easy stuff, but it is wonderfully effective.</p>
 <p>The three lines above get turned into:</p>

@@ Line 18: / Line 18: @@
 In order to check that your regular expression is actually correctly matching the text in the response, use the "Test" button to show what would be extracted. The results of the test are not stored for later use.
-Once you are satisfied with your configuration, simply enter the number of samples desired, and press "Go". If you decide to interrupt the collection process, you can do so by requesting 0 samples, and pressing "Go" again.
+Once you are satisfied with your configuration, simply enter the number of samples desired, and press "Go". If you decide to interrupt the collection process, you can do so by requesting 0 samples, and pressing "Fetch" again.
 == Analysing the results ==

@@ Line 52: / Line 52: @@
 The calculated values are then plotted on a graph against time. The idea is that the human eye is very good at visually identifying patterns, which may not be obvious from a list of numbers. The most likely patterns that you will see are lines or bands (possibly interrupted/broken), or else points scattered all over the graph. The first indicates predictability, while the second suggests randomness.
 === Plotting the results in an external program ===
@@ Line 91: / Line 93: @@
 /02/2006 14:00:42.224,11293771226654801443,6c30cf10801d38497e23
 If you're familiar with Excel, you'll realize that Excel can handle those date formats just fine. Now you can plot the data in Excel, which gives me a bit more control than WebScarab does directly.

@@ Line 53: / Line 53: @@
 The calculated values are then plotted on a graph against time. The idea is that the human eye is very good at visually identifying patterns, which may not be obvious from a list of numbers. The most likely patterns that you will see are lines or bands (possibly interrupted/broken), or else points scattered all over the graph. The first indicates predictability, while the second suggests randomness.
-'''NOTE!!!''' Predictability and randomness are relative terms. If the algorithm appears to be "predictable", but the key space that you'd have to check is greater than about 100000 items, it is likely to be infeasible to actually find a session belonging to someone else during that session's lifetime. Obviously, this depends on your own CPU power, network bandwidth, the target's CPU power and network bandwidth, the typical lifetime of a session, and a bunch of other factors. Please look at the scale of the numbers before deciding that an identifier is predictable.
+=== Plotting the results in an external program ===
 One very important thing to note about the conversion algorithm is that it works from right (Least Significant Bit) to left (Most Significant Bit), much as one would expect from a numerical conversion. What this means in practice is that if you have a session identifier that has some sequential data at the left, and significant random data to the right, the sequential data will appear to dominate the values, and will result in a straight line graph. Again, check the scale of the numbers before deciding that an identifier is predictable.

← Older revision		Revision as of 17:13, 31 October 2006
Line 23:		Line 23:

	As mentioned earlier, WebScarab uses a per-position base-conversion algorithm to convert a string into a number. What this really means is that the string is converted to a number using the same approach that one uses to convert a number of one base (e.g. hex - base 16) to another (e.g. decimal - base 10). The major difference is that the base can change for each position/index, according to what characters have actually been observed in that position throughout the sampled series. This means that if you have a constant character in the middle of your series, the base ends up being "1", the only possible value in a base-1 number system is 0, and so the constant character plays no part in actually calculating the numerical value of the total.		As mentioned earlier, WebScarab uses a per-position base-conversion algorithm to convert a string into a number. What this really means is that the string is converted to a number using the same approach that one uses to convert a number of one base (e.g. hex - base 16) to another (e.g. decimal - base 10). The major difference is that the base can change for each position/index, according to what characters have actually been observed in that position throughout the sampled series. This means that if you have a constant character in the middle of your series, the base ends up being "1", the only possible value in a base-1 number system is 0, and so the constant character plays no part in actually calculating the numerical value of the total.
		+
		+	Here is a worked example, on a small scale.
		+
		+	Assuming we have the following session ids:
		+
		+	AAAA
		+	AAAC
		+	ABAB
		+	ABAD
		+
		+	Starting from the left-most column (MSB), we have the following observed character sets:
		+
		+	1: "A"
		+	2: "A", "B"
		+	3: "A"
		+	4: "A", "B", "C", "D"
		+
		+	So, our bases are, in order (1,2,1,4).
		+
		+	Let's calculate the value of each id. In order to translate each character to a number, we use its zero-based position in the sorted character set:
		+
		+	AAAA = 0 * (214) + 0 * (14) + 0 (4) + 0 = 0
		+	AAAC = 0 * (214) + 0 * (14) + 0 (4) + 2 = 2
		+	ABAB = 0 * (214) + 1 * (14) + 0 (4) + 1 = 5
		+	ABAD = 0 * (214) + 1 * (14) + 0 (4) + 3 = 7

	== Looking at the graph ==		== Looking at the graph ==

@@ Line 9: / Line 9: @@
 == Collecting session identifiers ==
-It is possible to collect session identifiers from both Set-Cookie headers, as well as from within the body of the response. WebScarab will collect all identifiers from all cookies if the radio button is set to "Cookies". It is not necessasry to provide a name for the session identifier, as WebScarab will use the site name, path and cookie name to construct a unique identifier. If you choose to extract session identifiers from the body of the response, you have to give it a unique name, and provide a regular expression that defines which part of the response body is considered to be the identifier. This is typically done by using ".*" to indicate all characters leading up to some unique surrounding text, followed by that unique text, then a pattern surrounded by a regex group (e.g. "(....)" would take 4 characters), finally followed by ".*" again to indicate all characters to the end of the body text.
+It is possible to collect session identifiers from both Set-Cookie headers, as well as from within the body of the response. WebScarab will collect all identifiers from all cookies if the radio button is set to "Cookies". It is not necessary to provide a name for the session identifier, as WebScarab will use the site name, path and cookie name to construct a unique identifier. If you choose to extract session identifiers from the body of the response, you have to give it a unique name, and provide a regular expression that defines which part of the response body is considered to be the identifier. This is typically done by using ".*" to indicate all characters leading up to some unique surrounding text, followed by that unique text, then a pattern surrounded by a regex group (e.g. "(....)" would take 4 characters), finally followed by ".*" again to indicate all characters to the end of the body text.
 For a more concrete example, let's suppose that the identifier is in a URL query parameter in the body text, and the url parameter is called "id". An example might look like:

← Older revision		Revision as of 00:57, 27 May 2006
Line 1:		Line 1:
−	~~[[Category:How To]]~~
−	~~[[Category:OWASP WebScarab Project]]~~
−	~~[[Category:Session Management]]~~
−
−
	== Objective ==		== Objective ==

Line 36:		Line 31:

	One very important thing to note about the conversion algorithm is that it works from right (Least Significant Bit) to left (Most Significant Bit), much as one would expect from a numerical conversion. What this means in practice is that if you have a session identifier that has some sequential data at the left, and significant random data to the right, the sequential data will appear to dominate the values, and will result in a straight line graph. Again, check the scale of the numbers before deciding that an identifier is predictable.		One very important thing to note about the conversion algorithm is that it works from right (Least Significant Bit) to left (Most Significant Bit), much as one would expect from a numerical conversion. What this means in practice is that if you have a session identifier that has some sequential data at the left, and significant random data to the right, the sequential data will appear to dominate the values, and will result in a straight line graph. Again, check the scale of the numbers before deciding that an identifier is predictable.
		+
		+	[[Category:How To]]
		+	[[Category:OWASP WebScarab Project]]
		+	[[Category:Session Management]]
		+	[[Category:OWASP Testing Project]]

@@ Line 1: / Line 1: @@
 [[Category:How To]]
 [[Category:OWASP WebScarab Project]]
@@ Line 34: / Line 33: @@
 The calculated values are then plotted on a graph against time. The idea is that the human eye is very good at visually identifying patterns, which may not be obvious from a list of numbers. The most likely patterns that you will see are lines or bands (possibly interrupted/broken), or else points scattered all over the graph. The first indicates predictability, while the second suggests randomness.
-NOTE!!! Predictability and randomness are relative terms. If the algorithm appears to be "predictable", but the key space that you'd have to check is greater than about 100000 items, it is likely to be infeasible to actually find a session belonging to someone else during that session's lifetime. Obviously, this depends on your own CPU power, network bandwidth, the target's CPU power and network bandwidth, the typical lifetime of a session, and a bunch of other factors. Please look at the scale of the numbers before deciding that an identifier is predictable.
+'''NOTE!!!''' Predictability and randomness are relative terms. If the algorithm appears to be "predictable", but the key space that you'd have to check is greater than about 100000 items, it is likely to be infeasible to actually find a session belonging to someone else during that session's lifetime. Obviously, this depends on your own CPU power, network bandwidth, the target's CPU power and network bandwidth, the typical lifetime of a session, and a bunch of other factors. Please look at the scale of the numbers before deciding that an identifier is predictable.
 One very important thing to note about the conversion algorithm is that it works from right (Least Significant Bit) to left (Most Significant Bit), much as one would expect from a numerical conversion. What this means in practice is that if you have a session identifier that has some sequential data at the left, and significant random data to the right, the sequential data will appear to dominate the values, and will result in a straight line graph. Again, check the scale of the numbers before deciding that an identifier is predictable.