|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| − | = Concept = | + | {{taggedDocument |
| − | | + | | type=delete |
| − | The idea is to detect suspicious and malicious behavior by a user within an application, by identifying typical things that attackers would do but normal users could not possibly do, even by accident, and then taking action by for example logging them out or locking their account. Unacceptable behavior could include unauthorized scraping of content, searching for vulnerabilities, and attempts undertake fraud.
| + | | comment=Very old material that can be deleted. |
| − | | + | }} |
| − | = Introduction =
| |
| − | | |
| − | All users make mistakes, but attackers also perform actions that the user interface doesn't offer or are impossible to do without using tools like intercepting proxies. The AppSensor concept describes how to make applications attack-aware.
| |
| − | | |
| − | AppSensor will:
| |
| − | | |
| − | * Identify whether your application is under attack in real time
| |
| − | * Optionally initiate an immediate response action to protect the application and its data
| |
| − | | |
| − | AppSensor does not:
| |
| − | | |
| − | * Implement error handling for you (although detection points are often inherently linked with error handling code)
| |
| − | * Perform application security logging (but logging mechanisms could be used to record detected events)
| |
| − | * Protect you if you have existing vulnerabilities (fix known vulnerabilities and implement secure-SDLC activities to avoid new ones)
| |
| − | | |
| − | Where possible implement the recommendations in the other cheat sheets as thoroughly as possible first, before considering the ideas within AppSensor. Robust error handling mechanisms and security event logging should already be part of well designed quality software.
| |
| − | | |
| − | = Purpose =
| |
| − | | |
| − | Attackers take a finite number of attempts to find vulnerabilities, and additional attempts to craft an exploit. This may be scores or hundreds of attempts; or tens or hundreds of thousands if using automated tools. If you can detect some of these steps, you identify an attack and take some immediate action.
| |
| − | | |
| − | Distribute detection points in the application to detect very suspicious and blatantly malicious use
| |
| − | | |
| − | Collect these event event data
| |
| − | | |
| − | Define a very low tolerance threshold, and take a predefined automated action once a user exceeds the limits of reasonable use
| |
| − | | |
| − | = Pre-requisities =
| |
| − | | |
| − | * application that is fully tested (e.g. functional, stress) since the AppSensor concet relies on detecting abnormal behavior, and errors in an application could be misinterpredted
| |
| − | * secure application (using a secure development life cycle) to minimize the existence of unknown weaknesses
| |
| − | | |
| − | | |
| − | | |
| − | = What to detect =
| |
| − | | |
| − | It is very important not to make detection overly complex, and vital not to include events which could be triggered by normal, even accidental, behavior.
| |
| − | | |
| − | The most commonly implemented detection points are exceptions relating to:
| |
| − | | |
| − | *
| |
| − | * access control (e.g. a user attempting to access a resource they do not have permission to)
| |
| − | * whitelist input validation (e.g. non-numerical characters for a non-editable parameter value that is expected to be a positive non-zero integer)
| |
| − | | |
| − | | |
| − | = How to respond =
| |
| − | | |
| − | Legally. Policy.
| |
| − | | |
| − | Thresholds:
| |
| − | | |
| − | *
| |
| − | *
| |
| − | *
| |
| − | | |
| − | Typical responses, that the application may already support in some manner, are:
| |
| − | | |
| − | * Change monitoring of the user (e.g. increase logging level)
| |
| − | * Raise an alert
| |
| − | * Add time delays
| |
| − | * Log a user out (and possibly lock the account)
| |
| − | | |
| − | More advanced responses could include
| |
| − | | |
| − | *
| |
| − | * Changing a function (adding a CAPTCHA, ??? )
| |
| − | * Disabling a function (for the user, for a group of users, for all users)
| |
| − | * Affecting behaviour of another systems (e.g. goods despatch held, firewall blocks IP address)
| |
| − | * Altering user properties (changing their credit level)
| |
| − | | |
| − | | |
| − | | |
| − | = How to =
| |
| − | | |
| − | == Software acquisition ==
| |
| − | | |
| − | == In your own code ==
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | == No code available ==
| |
| − | | |
| − | Watch out for
| |
| − | | |
| − | | |
| − | | |
| − | = Related articles =
| |
| − | | |
| − | Other [http://www.jtmelton.com/2012/05/01/year-of-security-for-java-week-18-perform-application-layer-intrusion-detection/ Year of Security for Java Week 18 - Perform Application Layer Intrusion Detection ]
| |
| − | | |
| − | | |
| − | = Authors and primary contributors =
| |
| − | | |
| − | | |
| − | | |
| − | Colin Watson - colin.watson[at]owasp.org
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | {{Cheatsheet_Navigation}}
| |
| − | | |
| − | [[Category:Cheatsheets]] [[Category:OWASP_Defenders]]
| |
