Why a new Login Sequence Recorder, and what it means to users

The new Login Sequence Recorder (LSR) in version 10 is probably the most evident change to the product. The LSR has been re-engineered from the ground up to better meet the requirements of crawling and scanning modern web applications.

The new LSR helps pen-testers and quality assurance engineers alike by simplifying the testing of applications that have complex login mechanisms that are becoming increasingly popular in modern web applications.

To understand how the new LSR has improved over it’s predecessor, we need to identify the major differences between the two approaches. In previous versions, the LSR relied upon collecting every HTTP request that occurred during the recording of a login sequence. For a long time this worked well, however, websites and web applications have started to move away from the more traditional login mechanisms where replaying HTTP requests would work. A few examples would be authentication mechanisms relying on Single Sign-on (for example logging in using your Facebook, Google or Twitter account), OAuth and more crucially, websites making use of anti-CSRF tokens.

Anti-CSRF and other authentication  tokens are security mechanisms that, apart from preventing Cross-site Request Forgery vulnerabilities, are also specifically designed to prevent replaying of HTTP requests. Since CSRF tokens are recorded as part of the HTTP request, the moment the token expires, the crawler would get kicked out of the authenticated session — that’s exactly the outcome we don’t want during a web application scan.

In order to be able to get past anti-CSRF tokens and support modern authentication mechanisms, the LSR was re-designed to record user actions as opposed to HTTP requests. This approach makes it much easier for the scanner to authenticate and maintain session with a web application.

Login Sequence Wizard

 

The LSR is not just important for logging in, it’s also used to restrict the scanner from following links or making particular HTTP requests that could terminate the session — in other words, if the scanner logs in, but clicks a ‘logout’ link, the scanner will obviously get kicked out of the session. The LSR now supports HTTP methods commonly used in RESTful web services such as PATCH, PUT, DELETE in addition to the standard GET and POST requests — all of which can be set-up as restricted actions that are more restricting links with wildcard support for nonces or other one-time tokens in HTTP requests.

Automatic Session Detection, which is a mechanism for the LSR, the crawler and the scanner to differentiate between a logged-in and a logged-out state has also been improved. The LSR will now try to pick up unique entries made during the recording of the login sequence (such as usernames) and looks for these patterns within pages to determine a correct session pattern automatically. Further to session detection, the LSR can now also support authentication mechanisms that don’t use cookies, but rather use HTML5 storage mechanisms such as LocalStorage, WebSQL and IndexDB.

The re-designed LSR greatly helps users who need to scan authenticated web pages without the need to install any dependencies, write scripts or setup manual intervention (except for instances that require the input of CAPTCHAs or multi-factor authentication tokens).

Share this post

Leave a Reply

Your email address will not be published.