Log, Monitor, and Alert
The application’s session management functionality should be closely integrated with its mechanisms for logging, monitoring, and alerting, in order to provide suitable records of anomalous activity and enable administrators to take defensive actions where necessary:
■ The application should monitor requests that contain invalid tokens. Except in the most trivially predictable cases, a successful attack attempting to guess the tokens issued to other users will typically involve issuing large numbers of requests containing invalid tokens, leaving a noticeable mark in the application’s logs.
■ Brute-force attacks against session tokens are difficult to block altogether, because there is no particular user account or session that can be disabled to stop the attack. One possible action is to block source IP addresses for a period when a number of requests containing invalid tokens have been received. However, this may be ineffective when one user’s requests originate from multiple IP addresses (e.g., AOL users) or when multiple users’ requests originate from the same IP address (e.g., users behind a proxy or a firewall performing network address translation).
■ Even if brute-force attacks against sessions cannot be effectively prevented in real time, keeping detailed logs and alerting administrators enables them to investigate the attack and take appropriate action where they are able to.
■ Wherever possible, users should be alerted to anomalous events relating to their session — for example, concurrent logins or apparent hijacking (detected using per-page tokens). Even though a compromise may already have occurred, this enables the user to check whether any unauthorized actions such as funds transfers have taken place.
Reactive Session Termination
The session management mechanism can be leveraged as a highly effective defense against many kinds of other attacks against the application. Some security-critical applications such as online banking are extremely aggressive in terminating a user’s session every time the user submits some anomalous request — for example, any request containing a modified hidden HTML form field or URL query string parameter, any request containing strings associated with SQL injection or cross-site scripting attacks, and any user input that would normally have been blocked by client-side checks such as length restrictions.
Of course, any actual vulnerabilities that may be exploited using such requests need to be addressed at source. But forcing users to reauthenticate every time they submit an invalid request can slow down the process of probing the application for vulnerabilities by many orders of magnitude, even where automated techniques are employed. If residual vulnerabilities do still exist, they are far less likely to be discovered by anyone in the field. Where this kind of defense is implemented, it is also recommended that it can be easily switched off for testing purposes. If a legitimate penetration test of the application is slowed down in the same way as a real-world attacker, then its effectiveness is dramatically reduced, and it is very likely that the presence of the mechanism will result in more vulnerabilities remaining in production code than if the mechanism were absent.
NEXT is..Attacking Access Controls.,.,.,.,.,,.,.,.,.,.
