Handling Attackers
Anyone designing an application for which security is remotely important must work on the assumption that it will be directly targeted by dedicated and skilled attackers. A key function of the application’s security mechanisms is to be able to handle and react to these attacks in a controlled way. These mechanisms often incorporate a mix of defensive and offensive measures designed to frustrate an attacker as much as possible, and provide appropriate notification and evidence to the application’s owners of what has taken place. Measures implemented to handle attackers typically include the following tasks:
■ Handling errors
■ Maintaining audit logs
■ Alerting administrators
■ Reacting to attacks
Handling Errors
However careful an application’s developers are in validating user input, it is virtually inevitable that some unanticipated errors will occur. Errors resulting from the actions of ordinary users are likely to be identified during functionality and user acceptance testing, and so will be taken account of before the application is deployed in a production context. However, it is very difficult to anticipate every possible way in which a malicious user may interact with the application, and so further errors should be expected when the application comes under attack.
A key defense mechanism is for the application to handle unexpected errors in a graceful manner, and either recover from them or present a suitable error message to the user. In a production context, the application should never return any system-generated messages or other debug information in its responses. As you will see throughout this book, overly verbose error messages can greatly assist malicious users in furthering their attacks against the application. In some situations, an attacker can leverage defective error handling to retrieve sensitive information within the error messages themselves, providing a valuable channel for stealing data from the application. Figure -1 shows an example of an unhandled error resulting in a verbose error message.
Figure -1 : An unhandled error
Most web development languages provide good error-handling support through try-catch blocks and checked exceptions. Application code should make extensive use of these constructs to catch specific and general errors and handle them appropriately. Further, most application servers can be configured to deal with unhandled application errors in customized ways, for example by presenting an uninformative error message.
Effective error handling is often integrated with the application’s logging mechanisms, which record as much debug information as possible about unanticipated errors. Very often, unexpected errors point to defects within the application’s defenses that can be addressed at the source if the application’s owner has the required information.
Maintaining Audit Logs
Audit logs are primarily of value when investigating intrusion attempts against an application. Following such an incident, effective audit logs should enable the application’s owners to understand exactly what has taken place, which vulnerabilities (if any) were exploited, whether the attacker gained unauthorized access to data or performed any unauthorized actions, and as far as possible, provide evidence as to the intruder’s identity.
In any application for which security is important, key events should belogged as a matter of course. At a minimum, these typically include:
■ All events relating to the authentication functionality, such as successful and failed login, and change of password.
■ Key transactions, such as credit card payments and funds transfers.
■ Access attempts that are blocked by the access control mechanisms.
■ Any requests containing known attack strings that indicate overtly malicious intentions.
In many security-critical applications, such as those used by online banks, every single client request is logged in full, providing a complete forensic record that can be used to investigate any incidents.
Effective audit logs typically record the time of each event, the IP address from which the request was received, the session token, and the user’s account (if authenticated). Such logs need to be strongly protected against unauthorized read or write access. An effective approach is to store audit logs on an autonomous system that accepts only update messages from the main application. In some situations, logs may be flushed to write-once media to ensure their integrity in the event of a successful attack.
In terms of attack surface, poorly protected audit logs can provide a gold mine of information to an attacker, disclosing a host of sensitive information such as session tokens and request parameters that may enable them to immediately compromise the entire application.
Figure -2: Poorly protected application logs containing sensitive
information submitted by other users
Alerting Administrators
Audit logs enable an application’s owners to retrospectively investigate intrusion attempts, and if possible, take legal action against the perpetrator. However, in many situations it is desirable to take much more immediate action, in real time, in response to attempted attacks. For example, administrators may block the IP address or user account being used by an attacker. In extreme cases, they may even take the application offline while the attack is investigated and remedial action taken. Even if a successful intrusion has already occurred, its practical effects may be mitigated if defensive action is taken at an early stage.
In most situations, alerting mechanisms must balance the conflicting objectives of reporting each genuine attack reliably and of not generating so many alerts that these come to be ignored. A well-designed alerting mechanism can
use a combination of factors to diagnose that a determined attack is underway, and can aggregate related events into a single alert where possible. Anomalous events monitored by alerting mechanisms often include:
■ Usage anomalies, such as large numbers of requests being received from a single IP address or user, indicating a scripted attack.
■ Business anomalies, such as an unusual number of funds transfers being made to or from a single bank account.
■ Requests containing known attack strings.
■ Requests where data that is hidden from ordinary users has been modified.
Reacting to Attacks
In addition to alerting administrators, many security-critical applications contain built-in mechanisms to react defensively to users who are identified aspotentially malicious.
Because each application is different, most real-world attacks require an attacker to probe systematically for vulnerabilities, submitting numerous requests containing crafted input designed to indicate the presence of various common vulnerabilities. Effective input validation mechanisms will identify many of these requests as potentially malicious, and block the input from having any undesirable effect on the application. However, it is sensible to assume that some bypasses to these filters exist, and that the application does contain some actual vulnerabilities waiting to be discovered and exploited. At some point, an attacker working systematically is likely to discover these defects.
Reacting to apparent attackers is not, of course, a substitute for fixing any vulnerabilities that exist within the application. However, in the real world, even the most diligent efforts to purge an application of security flaws may leave some exploitable defects remaining. Placing further obstacles in the way of an attacker is an effective defense in depth measure that reduces the likelihood that any residual vulnerabilities will be found and exploited.
next article is ..Managing the Application……
