Open Close

Challenges in automated testing of session management


As we all know, web application scanners are meant to assist a user in identifying the vulnerabilities in a web application. The user/ audience for this tool can be penetration testers, developers or auditors. The true potential of any tool can be extracted only by a user who understands the domain and the tool he is operating. That means, these tools should only become in assisting a skilled or semi skilled person to conduct a web test. Even after more than a decade of engineering a security scanner for web applications, we see mixed reports on why some scanners perform poorly while some perform better. From my experience, most of the benchmarking reports I see are for test websites and when it comes to real applications, most of the scanner’s perform relatively the same.

If web application tests are compared to network tests, it will be noticed that web application tests are considered to be costlier than network tests. Day-by-day network tests will only become cheaper but web application tests are not going to follow that path. The classic difference is that network tests are conducted on a well defined protocol where it is meant for the machines to understand. If you look at the nessus plugins, it would be quite clear that the attack request and its response communicate a well defined protocol and structure. While in the case of web applications, even though the protocol it uses is HTTP, the crux of the problem is in understanding the context within which the application tests are conducted. Here also, there are reliable tests with zero false positives possible if it is fairly based on injections, error/pattern matching etc. But what about business logic tests, privilege escalation tests etc. Can they be truly automated?

(Read More:  Must Know Business Logic Vulnerabilities In Banking Applications)

So here, I would like to discuss one aspect of web application testing and check out the possibilities of true automation, where even a person who is not qualified to do a test should benefit from it. I will particularly refer to some aspects of OWASP testing guide v3’s Session Management testing [1].

Session Management Testing

At the core of any web application is to handle state information and there by handle the user interaction with the target site. As the transport mechanism used is HTTP, and it being a stateless protocol, the state needs to be carried in a way so that the client and server understand it. This session or state information can be tracked in cookie, URL or hidden form parameters at the client side and when it is transferred to the server, this information can be located in URL, Cookie header or in the body of the request (as a URL encoded data). Understanding these basic concepts, now let’s see how different black box tests can be truly automated and what could be the challenges in automation.

In a true automated scanning for session management, the scanner should be able to login to the application. This could be fairly simple to complex, based on how the scanner automatically detects the login page and processes it. Some heuristics can be applied for detecting login page, such as; if there are only two input boxes and the type for one input box is ‘text’ and the type for the other input box is ‘password’. Now this heuristic may apply in most cases but processing login page itself involves rather other set of problems like execution of javascript and rendering of the DOM, the URL for form submission is only generated by java script, the form submission for login is an event etc.

(Read More:  Web Application Vulnerability Statistics

In a simple scenario, where the credentials are given in the scan profile and if the scanner should make an automatic login to the application, it needs to understand the difference between a successful login and a login failure. To automatically understand this difference, a scanner can send “n” number of login requests with wrong credentials and create a statistical score of the failed login pages. Once the scanner understands how a login failure looks like, then it can submit the form for login with the correct credentials and check the statistical difference of this page’s response to the failed login pages. In this way, to some extent a scanner can reliably learn a successful login page attempt.

Another key challenge for the scanners is to understand the true order of execution of java script events in a page. This is an open problem in truly understanding the order of events. A scanner can try out all the “n” possible combinations of event execution starting from a pivot event and later process the branches independently. This way of execution is very time consuming and it will lead to an exponential order to even complete the testing of a single page. As with web 2.0 applications, this complexity will only rise and the practical solution is to do a depth first search of events or a breadth first search of events and test it accordingly, so that ensuring at least a registered event for an element is executed once.

Another millennium challenge would be truly testing for privilege escalations. Considering the case where, the scan profile consists of two or more different user role credentials, then the scanner can automatically login to the application. Now if the scanner keeps the map of resources that are accessible from each role after authentication, the scanner can try to access the resources (which are not present in the current role’s list) listed in other roles. This might sound fairly simple but it is awfully complex to implement for any real world application. Some of the reasons are (1) Determining two responses whether they are the same or not has a context involved in it (2) Order of execution of events cannot be determined (3) if the resources are dynamic pages, then that requires valid query parameters etc. Most of the problems for true automation of testing arise because of the way web applications are designed and developed.

Download Free Checklist:   How to assess your Penetration Testing Vendor?

Other than that, some of the easy and automatable cases in session management testing are given below:

Testing for Set-Cookie directives tagged as Secure.

This test for checking “secure” attribute can be truly automated after fetching the Set-Cookie header value and parsing the Cookie object or doing a pattern matching for “Secure”.

Testing for Cookie operations over unencrypted transport

This test can also be truly automated by checking the scheme of transport for any transaction where cookie is transferred to the server.

Testing for Cookie be forced over unencrypted transport

This test can be truly automated based on certain conditions such as assumption of an HTTP service running at any other port. The test can check for sending of cookie to the default HTTP port and as it is not an encrypted channel, we can check the response coming from the server. If the HTTP is not running on a default port, then this test will fail to complete.

Testing for Cookies persistence.

This test can be truly automated by checking the attributes of the cookie and also checking if the cookie’s are deleted once the session is expired.

What Expires= times are used on persistent cookies, and are they reasonable?

This test can be truly automated and a check on reasonable value of expiration can be compared with a policy set with the scan configuration/profile.

This is not a comprehensive guide on explaining what all can be automated for session management testing. The objective for this post was to make others aware of some of the challenges in building true automation for testing. So a tool like scanners should only assist any user in conducting his test for the application. Even zero false positive scanners’ can not be absolutely zero false positive if they are intending to have larger coverage of OWASP test cases. If it is solved in any innovative way, I would like to read a research paper regarding the same.


(Read More:  Beyond Secure Software Development Life Cycle (SDLC) : Moving Towards Secure Dev-Ops)




Leave a comment

All fields marked (*) are required