3

I have been looking at OWASP and other forms of checklists on testing web applications. One of the best practices is to ensure session IDs generated are sufficiently random and unpredictable.

Assuming that I am a corporate end user without having permissions to install software on my laptop, to test the security of a web application from my web browser.

From my understanding, if we were to have a web app that always enforce an encrypted HTTPS (SSL/TLS) connection to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks, this ensures that anyone cannot simply capture the session ID from web browser traffic.

If the session IDs are indeed encrypted due to HTTPS, are we still able to determine if the session IDs are sufficiently random and unpredictable? I was asking myself this question and for me, a close and probable answer I would give myself, is no. (I might be wrong)

Am I also right to say, to know that if session IDs are generated randomly and unpredictably, you would actually need to have access to the internal web application code? There are probably a lot more that I can't do without additional tools to gather more information on the web application.

What are the other kind of test cases - as an end user, who might not have advanced tools to sniff the network or to read underlying code, to test more comprehensively and value-add on my test cases on the web applications? For e.g. testing for invalid input and seeing if errors are thrown.

1
  • One way to test session IDs is to obtain a bunch of them (e.g. by repeatedly logging in) and seeing if they change predictably. That said, the randomness has nothing to do with HTTPS. – multithr3at3d Jan 19 '20 at 21:15
0

If the session IDs are indeed encrypted due to HTTPS, are we still able to determine if the session IDs are sufficiently random and unpredictable? I was asking myself this question and for me, a close and probable answer I would give myself, is no. (I might be wrong)

To read the session ID used by an application, you don't necessarily need any tool other than your browser. All you need to do on chrome is to right click on the web page and click inspect. In the window that opens, click on the 'Network' tab. As you click on anything in the web application, the requests can be seen there and in the cookies in request headers you can find the session token. You can log out and log in a few times to see if the session tokens are obviously predictable. However identifying insecure random patterns just by looking at the token may not always be possible as human brain can only comprehend that much with the limited data set.

Am I also right to say, to know that if session IDs are generated randomly and unpredictably, you would actually need to have access to the internal web application code? There are probably a lot more that I can't do without additional tools to gather more information on the web application.

For example if the application generates session ID as given below an attacker can easily guess the session ID. However for someone with no access to the source code, or the knowledge of this equation which the application is using, the session ID may seem random. So you are somewhat right when you say that reviewing the code is the only fool proof way to know for sure.

sessionId = SHA2(username+timestamp)

What are the other kind of test cases - as an end user, who might not have advanced tools to sniff the network or to read underlying code, to test more comprehensively and value-add on my test cases on the web applications? For e.g. testing for invalid input and seeing if errors are thrown.

  1. An approach which can be used is to generate as many session tokens as possible by logging in and out and calculate the entropy.
  2. Guess attacks to see if the session token is time linked - Verifying if the session ID is hash(tstamp) or hash(tstamp+something)

Reference:

https://www.owasp.org/index.php/Testing_for_Session_Management_Schema_(OTG-SESS-001)#Session_ID_Predictability_and_Randomness

3
  • Are we seeing the actual session ID or the encrypted version of the session ID when viewing the session ID via the browser on an HTTPS connection? – ndantonio Jan 9 '20 at 11:32
  • We will be seeing the actual session ID. Also you can look at the browser's cookie jar to see the session ID. In Firefox, open settings and search for cookies. – hax Jan 9 '20 at 11:34
  • HTTPS is encryption in transit. For a browser at one end of it, no data is encrypted. It gets encrypted when the data is being sent to the server. – hax Jan 9 '20 at 11:35
0

If the session IDs are sufficiently random and unpredictable?

To check just for randomisation and unpredictability, I use myself Burp Suite - Sequencer. Burp Suite Community edition is free to use.

You would actually need to have access to the internal web application code?

Sequencer can make any request where in response you get ID you want to check. It can make a lot of requests and analyse the response cookie. In the example, it would be JSESSIONID.

e.g.

Request: www.google.com/login

Response: Cookie: JSESSIONID=5858FBAA9874233FB133936RR9D3E21F

What are the other kind of test cases to check for sufficiently random and unpredictable cookies?

It would be hard to analyse randomisation and unpredictability without any tools.

Test more comprehensively and value-add on my test cases on the web applications (without tools)

You can check for something like CWE-209: Information Exposure Through an Error Message.

Hopefully someone else can add to this answer who is maybe not testing with tools.

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.