Title: The DBMS must provide a logout functionality to allow the user to manually terminate the session.
Vulnerability ID: V-32524
IA Controls: None
Description: Manually terminating an application session allows users to immediately depart the physical vicinity of the system they are logged into without the risk of subsequent system users reactivating or continuing their application session. User’s who log into applications must have the ability to manually terminate their application session.
Without an observable manual logout capability provided by the application, the user will have no means of manually terminating their application session. Their session could remain active until which time the inactivity period expires and the application automatically logs the user out. This increases the likelihood that the next subsequent user of the system could pick up on the previous user’s session and continue utilizing the application as the previous user.
Check Text: Review DBMS settings and vendor documentation to verify users have the capability to log out of the system manually. If the DBMS does not provide functionality for the user to manually log out of the system, this is a finding.
If the DBMS does provide the functionality for the user to manually log out of the system but the functionality is not enabled, this is a finding.
Fix Text: Utilize a DBMS product that allows users to manually log out of the system.
Configure DBMS settings to allow users to manually log out of the system.[divider]
In general the logout capability is provided through whichever application or client is interfacing with SQL Server. Connections to SQL Server are managed as sessions and can be identified on SQL Server using the included procedures sp_who or sp_who2. You can also identify active sessions using the downloadable sp_whoisactive (from Adam Machanic). In general when a connection is severed the session ends. Additional time-outs can be added. You will also want to be aware of connection pooling.
Connection Pooling is not usually in the realm of a DBA, but knowledge of it is not a bad thing. Connection Pooling is almost entirely implemented in the client stack, not SQL Server, so you will want to verify with any developers of applications and providers of clients to see if that is the default behavior of the component.
Connection pooling basically is a set of idle, open, and reusable connections to the database maintained by the database so the connections can be reused when requests for data are received. This does not mean the same login information is maintained, just a connection to minimize the resources used to establish the connection. The application or client connection via the connection pool will need to issue a disconnect statement to remove itself from the pool and allow that connection to be used by other applications and clients. More information about connection pooling can be found here.