Revision as of 09:04, 4 June 2013

About This Document

These response actions are part of the OWASP AppSensor project which advocates bringing intelligent intrusion detection inside the application. These responses can be used to counter a malicious user that has been detected probing for vulnerabilities or weaknesses within your application.

Overview

The following table lists possible AppSensor Responses (ASRs), other than no response (ASR-P). The application response actions are categorized here from the user's perspective (not from the application/server's perspective):

Silent: User(s) unaware of any application change

Passive: Process altered, but user(s) may still continue to process completion

Active: Functionality reduced or disabled

Intrusive: Non-malicious action on user's system

To add a response action, just use the next available letter (e.g. "ASR-Q") - they don't have to be in alphabetical order below, but place it in the appropriate category (silent, passive, active or intrusive). The image in the table below can be updated later to keep in step with the page content.

A text version of the table, with some examples and alternative classifications, is described in AppSensor - Response Actions (63 KB PDF). The information on the page below is likely to be more up-to-date.

Detailed Listing

Classifications are:

Purposes: Logging, Notifying, Disrupting and Blocking

Target: One, Some or All users

Response duration: Instantaneous (e.g. just for the request), Period (e.g. time period or session duration), Permanent

Silent

ASR-P: No Response

id

ASR-P

title

No Response

classifications

(not applicable)

category

Silent

description

There is no response. This could be used to record in logs that a detection event did not lead to any particular response action.

consideration

examples

Example 1: A detection point fired, but the threshold for response has not been reached

code

-

ASR-A: Logging Change

id

ASR-A

title

Logging Change

classifications

Logging | One, some or all users | Instantaneous (request) or for a period

ASR-C: Other Notification

Notification message sent to something or someone other than Administrators (see ASR-B) or the User (see ASR-E)

consideration

The message recipient (e.g. firewall) could take some action otherwise unavailable to the application (e.g. disruptive - the application makes a silent response, but the firewall actively intervenes and perhaps blocks the user).

Active

ASR-G: Process Terminated

An interruption to the sending, display or process, such that the user has to start again, or start somewhere else. For authenticated users, this would not include termination of their session (see ASR-J). And, they would be free to attempt the process again (e.g. access the resource after logging in, submit a payment transfer, etc).

Example 8: Additional human interactive proof challenges added due to the number of incorrect guesses of CAPTCHAs outnumbering the correct guesses by more than a certain factor (e.g. Token bucket idea)

code

-

ASR-I: Function Disabled

id

ASR-I

title

Function Disabled

classifications

Logging, notifying (sometimes), disrupting and blocking | One, some or all users | For a period or permanent

category

Active

description

A function or functions are disabled for one, some or all users. Other functionality continues to work as normal.

consideration

For changes that affect multiple users, be careful the response cannot be used too easily for denial of service.

Be careful the response cannot be used too easily for denial of service.

examples

Example 1: Website shut down and replaced with temporary static page

Example 2: Application taken offline

code

-

Intrusive

ASR-M: Collect Data from User

id

ASR-M

title

Collect Data from User

classifications

Logging | One user | For a period

category

Intrusive

description

Direct action to collect further information from the user's system.

consideration

This response is meant to be non-malicious in intent - it is simply additional information gathering - and not retaliatory or damaging to the user, their systems or data, nor make any permanent change. An alert user might be aware of the action. Be very wary of data collected and perform appropriate validation and sanitization. Ensure any use of this type of response is legally permissible in the relevant jurisdictions, and complies with corporate policies and the application's terms of use, privacy notice and corporate policies.

To a certain extent, any additional payload in a response might cause a user's browser or computer to crash, and this might have unforeseen circumstances.

The information collection could use techniques like these described elsewhere: