4

I have run a penetration test on a web server. To generate session IDs with this Bash script :

#! /bin/bash
NUMBEROFSESSIONS=3000
for i in $(seq 1 ${NUMBEROFSESSIONS})
do
curl -s -c cookie 'URL' 1> /dev/null # URL is the address of my server
cat cookie | grep HttpOnly >> sessionIDs.lst
done

When this test is run on a Linux machine, the session ID are not repeated, but on Mac I get some repeated IDs.

Does anyone know why?

To check for repeated IDs I do :

wc -l sessionIDs.lst; cat sessionIDs.lst | uniq |wc -l
  • Is the Mac the client or the server or both? Also, how is the server generating the session IDs? – Ladadadada Oct 29 '13 at 18:28
  • The mac is the client running the pentesting script on. The server is win server 2K8 R2 with apache tomcat 7. In the code source the session id cannot be repeated. The script is run several times on linux machines and there is no repeated session ID. – user2933032 Nov 1 '13 at 2:24
  • Wouldn't this just be coincidence? Run curl in verbose mode (add -v to the command line) on both Linux and Mac and see if the requests differ. – André Borie Dec 14 '15 at 9:42
  • Are you using an explicit or transparent proxy between your client and server? – dan Dec 14 '15 at 10:08
1

It's difficult to tell the exact reason why, especially if it is a black-box test and you don't have access to the source code. Session generation and management should normally be handled on server-side, so the repetition in Mac, top of my mind, could mean one of two things.

  1. It could be pure coincidence
  2. The session id generation has dependency on client-side

The second could mean a flaw in generation of session id. You could do a thorough check on the scripts in the client-side to see if the client could indeed influence the session id.

For pentesting session ids, may I suggest to just do an entropy test. Recommended entropy is at least 128-bits. Judging from your script, you can easily send the http request to burp sequencer, and run an entropy test with 20,000 as sample size.

  • Since the client side appears to be the same in both tests, option 2 seems unlikely, my first assumption is that there is a defect in the session id generation - most likely a bad random number generator (something for which an application should defer to the operating system). – symcbean Apr 10 '17 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.