Session Management Testing, Authorization Testing, and Business Logic Testing (from OWASP)

1. SESSION MANAGEMENT TESTING
At the core of any web-based application is the way in which it maintains state and thereby controls user-interaction with the site. Session Management broadly covers all controls on a user from authentication to leaving the application. HTTP is a stateless protocol, meaning that web servers respond to client requests without linking them to each other. Even simple application logic requires a user's multiple requests to be associated with each other across a "session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built-in session handling routines. Some kind of identification token will typically be issued, which will be referred to as a “Session ID” or Cookie.

There are a number of ways in which a web application may interact with a user. Each is dependent upon the nature of the site, the security, and availability requirements of the application. Whilst there are accepted best practices for application development, such as those outlined in the OWASP Guide to Building Secure Web Applications, it is important that application security is considered within the context of the provider’s requirements and expectations. In this chapter we describe the following items.

4.5.1 Testing for Session Management Schema (OWASP-SM-001)
This describes how to analyse a Session Management Schema, with the goal to understand how the Session Management mechanism has been developed and if it is possible to break it to bypass the user session. It explains how to test the security of session tokens issued to the client's browser: how to reverse engineer a cookie, and how to manipulate cookies to hijack a session.

We used addons Add & Edit cookies.

4.5.2 Testing for Cookies attributes (OWASP-SM-002)
Cookies are often a key attack vector for malicious users (typically, targeting other users) and, as such, the application should always take due diligence to protect cookies. In this section, we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured.

This Cookies atribut we found:
akakom_tpl=akakom; __utma=242819602.2057941145.1307427908.1307427908.1307430421.2; __utmz=242819602.1307427908.1.1.utmcsr=172.17.38.254|utmccn=(referral)|utmcmd=referral|utmcct=/login; __utmb=242819602.2.10.1307430421; 69cb2eb0a19889c0e172765110b05475=9hjssavtaja0476hriti01gt25; __utmc=242819602

4.5.3 Testing for Session Fixation (OWASP-SM_003)
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known to the attacker.

4.5.4 Testing for Exposed Session Variables (OWASP-SM-004)
Session Tokens represent confidential information because they tie the user identity with his own session. It's possible to test if the session token is exposed to this vulnerability and try to create a replay session attack.

4.5.5 Testing for CSRF (OWASP-SM-005)
Cross Site Request Forgery describes a way to force an unknowing user to execute unwanted actions on a web application in which he is currently authenticated. This section describes how to test an application to find this kind of vulnerability.

2. Authorization testing
Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization means understanding how the authorization process works, and using that information to circumvent the authorization mechanism. Authorization is a process that comes after a successful authentication, so the tester will verify this point after he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester.

4.6.1 Testing for Path Traversal (OWASP-AZ-001)
First, we test if it is possible to find a way to execute a path traversal attack and access reserved information

About input vector:

Looking for getUserProfile.jsp


Tried for main.cgi


Looking for filetype ".cgi"


4.6.2 Testing for bypassing authorization schema (OWASP-AZ-002)
This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources.

4.6.3 Testing for Privilege Escalation (OWASP-AZ-003)
During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.

3. Business logic testing (OWASP-BL-001)
Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional ways. If an application's authentication mechanism is developed with the intention of performing steps 1,2,3 in order to authenticate, what happens if you go from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open, deny access, or just error out with a 500 message? There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, but, at the same time, usually one of the most detrimental to the application, if exploited.

Business logic may include:
• Business rules that express business policy (such as channels, location, logistics, prices, and products); and
• Workflows based on the ordered tasks of passing documents or data from one participant (a person or a software system) to another.

Attacks on the business logic of an application are dangerous, difficult to detect, and are usually specific to the application being tested.