CSP-CERT® Resources:
Discovering A2 Broken Authentication and Session Management

by CSP-CERT® VAPT Team Manager - John Patrick Lita
posted October 2017



Hello everyone, i am going to share with you today one of my private program, but the company who handle this application give's me a permission to share how i discover this vulnerability.


A2 - Broken Authentication and Session Management is an application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities (temporarily or permanently).


The vendor behind the the Online NBI Clearance announce a bug hunting challenge and the person who can find a security flaw on their system can win a MACBOOK AIR! well that's interesting after the conference, i jump in on my laptop and try to check and search for vulnerability analysing stuff from source code and behavioural analysis.




I fired up my burp suite and do some passive scanning on the application, reviewing all the response from the server then i notice an interesting flaw on the system the issuing of token on the application.


i signed in on the application and check all the responses of the application




on the login page the application is using a POST method for sending credentials on the system. then after login the application will issue a token but this time it uses a GET Method and things are getting interesting? alright now i try to login and log out in using different account and save all the token issued by the application to know how the application generate this tokens.




First thing comes into my mind is the GET Method, using GET means it requests a data from a specified resource take note of this

  • GET requests can be cached

  • GET requests remain in the browser history

  • GET requests can be bookmarked

  • GET requests should never be used when dealing with sensitive data

  • GET requests have length restrictions

  • GET requests should be used only to retrieve data


now these are the behaviour of the GET Method, if you are going to test an application we also need to test the application in different types of browser to know what are the difference and behaviour.


Ok now i copy the URL of the token once the application issues the token and paste the token in a different browser. what to expect?

  1. Application can determine what is the user-agent where the application issued that token so i can expect error message or restrictions.

  2. Or there is a Cookie and Session Token verification to identify session highjacking or token stealing

  3. GET requests can be bookmarked


but what i saw is this response "Status": 200"


Firefox:




Chrome:




It expose the data of theuser in clear text. but wait there's more, remember that the GET Method can be booked marked? yeap! i tried to bookmark all the sessions i made and try it to check and used it every hours and i notice the token didn't expire automatically once the user log-out.





The Expiration of the token is another issues, because anyone can still the session just run a wireshark on the network, save all the pcaps and review all the transactions made on the NBI Online Clearance.


then i create a report and send it to the owner/vendor

Report Sent: Mon, Jun 20, 2016 at 12:54 PM

Reply: Tue, Jun 21, 2016 at 7:36 AM - Push a Fix

Fix Pushed: Mon, Jun 27, 2016 at 11:45 AM - Fix Verified!

July 15, 2016 - I GOT MY BOUNTY!




Thanks for reading! Have a great day!