OWASP - User contributions [en]

Access Control Cheat Sheet

2015-06-22T16:40:48Z

Jkurucar: /* Discretionary Access Control (DAC)' */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.

==What is Access Control / Authorization?==

Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused. Authentication is providing and validating identity. In a system that uses a simple username and password scheme, the authentication process collects the username and validates the identity using the password. Authorization is the execution of access control properties, ensuring the proper allocation of access rights once authentication is successful.

Access Control is the method or mechanism of authorization to enforce that requests to a system resource or functionality should be granted.

== Role Based Access Control (RBAC) ==
In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base. The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).

An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.
*Roles are assigned based on organizational structure with emphasis on the organizational security policy
*Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
*Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
*Roles are granted permissions based on the principle of least privilege.
*Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
*Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
*Roles can be only be transferred or delegated using strict sign-offs and procedures.
*Roles are managed centrally by a security administrator or project leader

OWASP has a role based access control implementation project, [[OWASP_PHPRBAC_Project|OWASP RBAC Project]].

== Discretionary Access Control (DAC) ==

Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.
*Data Owners can transfer ownership of information to other users
*Data Owners can determine the type of access given to other users (read, write, copy, etc.)
*Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
*Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminate copying by users ("cutting and pasting" of information)
*Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
*Access to information is determined based on authorizations to access control lists based on user identifier and group membership.

== Mandatory Access Control (MAC) ==

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.
*Only administrators, not data owners, make changes to a resource's security label.
*All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
*All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
*All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
*All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
*Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
*Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)

== Attribute Based Access Control (ABAC) ==

[http://csrc.nist.gov/publications/drafts/800-162/sp800_162_draft.pdf NIST Special Publication (SP) 800-162 (Draft)]

=Attacks on Access Control=

Vertical Access Control Attacks - A standard user accessing administration functionality

Horizontal Access Control attacks - Same role, but accessing another user's private data

Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective

=Access Control Issues=
*Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges

*Authorization Logic often relies on Security by Obscurity (STO) by assuming:
**Users will not find unlinked or hidden paths or functionality
**Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)

*Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges

*Many administrative interfaces require only a password for authentication
*Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
*Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
*Authorization/Access Control relies on client-side information (e.g., hidden fields)
*Web and application server processes run as root, Administrator, LOCALSYSTEM or other privileged accounts
*Some web applications access the database via sa or other administrative account (or more privileges than required)
*Some applications implement authorization controls by including a file or web control or code snippet on every page in the application

<input type="text" name="fname" value="Derek">
<input type="text" name="lname" value="Jeter">
<input type="hidden" name="usertype" value="admin">

=Access Control Anti-Patterns=

*Hard-coded role checks in application code
*Lack of centralized access control logic
*Untrusted data driving access control decisions
*Access control that is "open by default"
*Lack of addressing horizontal access control in a standardized way (if at all)
*Access control logic that needs to be manually added to every endpoint in code
*non-anonymous entry point DO NOT have an access control check
*No authorization check at or near the beginning of code implementing sensitive activities

==Hard Coded Roles==

if (user.isManager() ||
user.isAdministrator() ||
user.isEditor() ||
user.isUser()) {
//execute action
}

'''Hard Codes Roles can create several issues including:'''

*Making the policy of an application difficult to "prove" for audit or Q/A purposes
*Causing new code to be pushed each time an access control policy needs to be changed.
*They are fragile and easy to make mistakes

==Order Specific Operations==

Imagine the following parameters

http://example.com/buy?action=chooseDataPackage
http://example.com/buy?action=customizePackage
http://example.com/buy?action=makePayment
http://example.com/buy?action=downloadData

'''Can an attacker control the sequence?'''

'''Can an attacker abuse this with concurrency?'''

==Never Depend on Untrusted Data==

*Never trust user data for access control decisions
*Never make access control decisions in JavaScript
*Never depend on the order of values sent from the client
*Never make authorization decisions based solely on
**hidden fields
**cookie values
**form parameters
**URL parameters
**anything else from the request

=Attacking Access Controls=

*Elevation of privileges
*Disclosure of confidential data - Compromising admin-level accounts often result in access to a user's confidential data
*Data tampering - Privilege levels do not distinguish users who can only view data and users permitted to modify data

=Testing for Broken Access Control=

*Attempt to access administrative components or functions as an anonymous or regular user
**Scour HTML source for “interesting” hidden form fields
**Test web accessible directory structure for names like admin, administrator, manager, etc (i.e. attempt to directly browse to “restricted” areas)
*Determine how administrators are authenticated. Ensure that adequate authentication is used and enforced
*For each user role, ensure that only the appropriate pages or components are accessible for that role.
*Login as a low-level user, browse history for a higher level user’s cache, load the page to see if the original authorization is passed to a previous session.
*If able to compromise administrator-level account, test for all other common web application vulnerabilities (poor input validation, privileged database access, etc)

=Defenses Against Access Control Attacks=

*Implement role based access control to assign permissions to application users for vertical access control requirements
*Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
*Avoid assigning permissions on a per-user basis
*Perform consistent authorization checking routines on all application pages
*Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
*Where possible restrict administrator access to machines located on the local area network (i.e. it’s best to avoid remote administrator access from public facing access points)
*Log all failed access authorization requests to a secure location for review by administrators
*Perform reviews of failed login attempts on a periodic basis
*Utilize the strengths and functionality provided by the SSO solution you chose

'''Java'''

<pre>

if ( authenticated ) {

request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;

}

</pre>

'''.NET (C#)'''

<pre>

if ( authenticated ) {

Session[“AUTHLEVEL”] = X_USER;

}

</pre>

'''PHP'''

<pre>

if ( authenticated ) {

$_SESSION[‘authlevel’] = X_USER; // X_USER is defined elsewhere as meaning, the user is authorized

}

</pre>

=Best Practices=

==Best Practice: Code to the Activity==

if (AC.hasAccess(ARTICLE_EDIT)) {
//execute activity
}
*Code it once, never needs to change again
*Implies policy is persisted/centralized in some way
*Avoid assigning permissions on a per-user basis
*Requires more design/work up front to get right

==Best Practice: Centralized ACL Controller==

*Define a centralized access controller
ACLService.isAuthorized(ACTION_CONSTANT)
ACLService.assertAuthorized(ACTION_CONSTANT)
*Access control decisions go through these simple API’s
*Centralized logic to drive policy behavior and persistence
*May contain data-driven access control policy information
*Policy language needs to support ability to express both access rights and prohibitions

==Best Practice: Using a Centralized Access Controller==

*In Presentation Layer

if (isAuthorized(VIEW_LOG_PANEL))
{
Here are the logs
<%=getLogs();%/>
}

*In Controller

try (assertAuthorized(DELETE_USER))
{
deleteUser();
}

==Best Practice: Verifying policy server-side==

*Keep user identity verification in session
*Load entitlements server side from trusted sources
*Force authorization checks on ALL requests
**JS file, image, AJAX and FLASH requests as well!
**Force this check using a filter if possible

=SQL Integrated Access Control=

'''Example Feature'''

http://mail.example.com/viewMessage?msgid=2356342

'''This SQL would be vulnerable to tampering'''

select * from messages where messageid = 2356342

'''Ensure the owner is referenced in the query!'''

select * from messages where messageid = 2356342 AND messages.message_owner =

=Access Control Positive Patterns=

*Code to the activity, not the role
*Centralize access control logic
*Design access control as a filter
*Deny by default, fail securely
*Build centralized access control mechanism
*Apply same core logic to presentation and server-side access control decisions
*Determine access control through Server-side trusted data

=Data Contextual Access Control=

'''Data Contextual / Horizontal Access Control API examples'''

ACLService.isAuthorized(EDIT_ORG, 142)
ACLService.assertAuthorized(VIEW_ORG, 900)

Long Form

isAuthorized(user, EDIT_ORG, Organization.class, 14)

*Essentially checking if the user has the right role in the context of a specific object
*Centralize access control logic
*Protecting data at the lowest level!

=Authors and Primary Editors=

Jim Manico - jim [at] owasp dot org<br/>
Fred Donovan - fred.donovan [at] owasp dot org<br/>
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Access Control Cheat Sheet

2015-06-22T16:39:03Z

Jkurucar: /* What is Access Control / Authorization? */

= DRAFT CHEAT SHEET - WORK IN PROGRESS =
=Introduction=

This article is focused on providing clear, simple, actionable guidance for providing Access Control security in your applications.

==What is Access Control / Authorization?==

Authorization is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication - as these terms and their definitions are frequently confused. Authentication is providing and validating identity. In a system that uses a simple username and password scheme, the authentication process collects the username and validates the identity using the password. Authorization is the execution of access control properties, ensuring the proper allocation of access rights once authentication is successful.

Access Control is the method or mechanism of authorization to enforce that requests to a system resource or functionality should be granted.

== Role Based Access Control (RBAC) ==
In Role-Based Access Control (RBAC), access decisions are based on an individual's roles and responsibilities within the organization or user base. The process of defining roles is usually based on analyzing the fundamental goals and structure of an organization and is usually linked to the security policy. For instance, in a medical organization, the different roles of users may include those such as doctor, nurse, attendant, nurse, patients, etc. Obviously, these members require different levels of access in order to perform their functions, but also the types of web transactions and their allowed context vary greatly depending on the security policy and any relevant regulations (HIPAA, Gramm-Leach-Bliley, etc.).

An RBAC access control framework should provide web application security administrators with the ability to determine who can perform what actions, when, from where, in what order, and in some cases under what relational circumstances. http://csrc.nist.gov/rbac/ provides some great resources for RBAC implementation. The following aspects exhibit RBAC attributes to an access control model.
*Roles are assigned based on organizational structure with emphasis on the organizational security policy
*Roles are assigned by the administrator based on relative relationships within the organization or user base. For instance, a manager would have certain authorized transactions over his employees. An administrator would have certain authorized transactions over his specific realm of duties (backup, account creation, etc.)
*Each role is designated a profile that includes all authorized commands, transactions, and allowable information access.
*Roles are granted permissions based on the principle of least privilege.
*Roles are determined with a separation of duties in mind so that a developer Role should not overlap a QA tester Role.
*Roles are activated statically and dynamically as appropriate to certain relational triggers (help desk queue, security alert, initiation of a new project, etc.)
*Roles can be only be transferred or delegated using strict sign-offs and procedures.
*Roles are managed centrally by a security administrator or project leader

OWASP has a role based access control implementation project, [[OWASP_PHPRBAC_Project|OWASP RBAC Project]].

== Discretionary Access Control (DAC)' ==

Discretionary Access Control (DAC) is a means of restricting access to information based on the identity of users and/or membership in certain groups. Access decisions are typically based on the authorizations granted to a user based on the credentials he presented at the time of authentication (user name, password, hardware/software token, etc.). In most typical DAC models, the owner of information or any resource is able to change its permissions at his discretion (thus the name). DAC has the drawback of the administrators not being able to centrally manage these permissions on files/information stored on the web server. A DAC access control model often exhibits one or more of the following attributes.
*Data Owners can transfer ownership of information to other users
*Data Owners can determine the type of access given to other users (read, write, copy, etc.)
*Repetitive authorization failures to access the same resource or object generates an alarm and/or restricts the user's access
*Special add-on or plug-in software required to apply to an HTTP client to prevent indiscriminate copying by users ("cutting and pasting" of information)
*Users who do not have access to information should not be able to determine its characteristics (file size, file name, directory path, etc.)
*Access to information is determined based on authorizations to access control lists based on user identifier and group membership.

== Mandatory Access Control (MAC) ==

Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary web application user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.
*Only administrators, not data owners, make changes to a resource's security label.
*All data is assigned security level that reflects its relative sensitivity, confidentiality, and protection value.
*All users can read from a lower classification than the one they are granted (A "secret" user can read an unclassified document).
*All users can write to a higher classification (A "secret" user can post information to a Top Secret resource).
*All users are given read/write access to objects only of the same classification (a "secret" user can only read/write to a secret document).
*Access is authorized or restricted to objects based on the time of day depending on the labeling on the resource and the user's credentials (driven by policy).
*Access is authorized or restricted to objects based on the security characteristics of the HTTP client (e.g. SSL bit length, version information, originating IP address or domain, etc.)

== Attribute Based Access Control (ABAC) ==

[http://csrc.nist.gov/publications/drafts/800-162/sp800_162_draft.pdf NIST Special Publication (SP) 800-162 (Draft)]

=Attacks on Access Control=

Vertical Access Control Attacks - A standard user accessing administration functionality

Horizontal Access Control attacks - Same role, but accessing another user's private data

Business Logic Access Control Attacks - Abuse of one or more linked activities that collectively realize a business objective

=Access Control Issues=
*Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges

*Authorization Logic often relies on Security by Obscurity (STO) by assuming:
**Users will not find unlinked or hidden paths or functionality
**Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)

*Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges

*Many administrative interfaces require only a password for authentication
*Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
*Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
*Authorization/Access Control relies on client-side information (e.g., hidden fields)
*Web and application server processes run as root, Administrator, LOCALSYSTEM or other privileged accounts
*Some web applications access the database via sa or other administrative account (or more privileges than required)
*Some applications implement authorization controls by including a file or web control or code snippet on every page in the application

<input type="text" name="fname" value="Derek">
<input type="text" name="lname" value="Jeter">
<input type="hidden" name="usertype" value="admin">

=Access Control Anti-Patterns=

*Hard-coded role checks in application code
*Lack of centralized access control logic
*Untrusted data driving access control decisions
*Access control that is "open by default"
*Lack of addressing horizontal access control in a standardized way (if at all)
*Access control logic that needs to be manually added to every endpoint in code
*non-anonymous entry point DO NOT have an access control check
*No authorization check at or near the beginning of code implementing sensitive activities

==Hard Coded Roles==

if (user.isManager() ||
user.isAdministrator() ||
user.isEditor() ||
user.isUser()) {
//execute action
}

'''Hard Codes Roles can create several issues including:'''

*Making the policy of an application difficult to "prove" for audit or Q/A purposes
*Causing new code to be pushed each time an access control policy needs to be changed.
*They are fragile and easy to make mistakes

==Order Specific Operations==

Imagine the following parameters

http://example.com/buy?action=chooseDataPackage
http://example.com/buy?action=customizePackage
http://example.com/buy?action=makePayment
http://example.com/buy?action=downloadData

'''Can an attacker control the sequence?'''

'''Can an attacker abuse this with concurrency?'''

==Never Depend on Untrusted Data==

*Never trust user data for access control decisions
*Never make access control decisions in JavaScript
*Never depend on the order of values sent from the client
*Never make authorization decisions based solely on
**hidden fields
**cookie values
**form parameters
**URL parameters
**anything else from the request

=Attacking Access Controls=

*Elevation of privileges
*Disclosure of confidential data - Compromising admin-level accounts often result in access to a user's confidential data
*Data tampering - Privilege levels do not distinguish users who can only view data and users permitted to modify data

=Testing for Broken Access Control=

*Attempt to access administrative components or functions as an anonymous or regular user
**Scour HTML source for “interesting” hidden form fields
**Test web accessible directory structure for names like admin, administrator, manager, etc (i.e. attempt to directly browse to “restricted” areas)
*Determine how administrators are authenticated. Ensure that adequate authentication is used and enforced
*For each user role, ensure that only the appropriate pages or components are accessible for that role.
*Login as a low-level user, browse history for a higher level user’s cache, load the page to see if the original authorization is passed to a previous session.
*If able to compromise administrator-level account, test for all other common web application vulnerabilities (poor input validation, privileged database access, etc)

=Defenses Against Access Control Attacks=

*Implement role based access control to assign permissions to application users for vertical access control requirements
*Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
*Avoid assigning permissions on a per-user basis
*Perform consistent authorization checking routines on all application pages
*Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis
*Where possible restrict administrator access to machines located on the local area network (i.e. it’s best to avoid remote administrator access from public facing access points)
*Log all failed access authorization requests to a secure location for review by administrators
*Perform reviews of failed login attempts on a periodic basis
*Utilize the strengths and functionality provided by the SSO solution you chose

'''Java'''

<pre>

if ( authenticated ) {

request.getSession(true).setValue(“AUTHLEVEL”) = X_USER;

}

</pre>

'''.NET (C#)'''

<pre>

if ( authenticated ) {

Session[“AUTHLEVEL”] = X_USER;

}

</pre>

'''PHP'''

<pre>

if ( authenticated ) {

$_SESSION[‘authlevel’] = X_USER; // X_USER is defined elsewhere as meaning, the user is authorized

}

</pre>

=Best Practices=

==Best Practice: Code to the Activity==

if (AC.hasAccess(ARTICLE_EDIT)) {
//execute activity
}
*Code it once, never needs to change again
*Implies policy is persisted/centralized in some way
*Avoid assigning permissions on a per-user basis
*Requires more design/work up front to get right

==Best Practice: Centralized ACL Controller==

*Define a centralized access controller
ACLService.isAuthorized(ACTION_CONSTANT)
ACLService.assertAuthorized(ACTION_CONSTANT)
*Access control decisions go through these simple API’s
*Centralized logic to drive policy behavior and persistence
*May contain data-driven access control policy information
*Policy language needs to support ability to express both access rights and prohibitions

==Best Practice: Using a Centralized Access Controller==

*In Presentation Layer

if (isAuthorized(VIEW_LOG_PANEL))
{
Here are the logs
<%=getLogs();%/>
}

*In Controller

try (assertAuthorized(DELETE_USER))
{
deleteUser();
}

==Best Practice: Verifying policy server-side==

*Keep user identity verification in session
*Load entitlements server side from trusted sources
*Force authorization checks on ALL requests
**JS file, image, AJAX and FLASH requests as well!
**Force this check using a filter if possible

=SQL Integrated Access Control=

'''Example Feature'''

http://mail.example.com/viewMessage?msgid=2356342

'''This SQL would be vulnerable to tampering'''

select * from messages where messageid = 2356342

'''Ensure the owner is referenced in the query!'''

select * from messages where messageid = 2356342 AND messages.message_owner =

=Access Control Positive Patterns=

*Code to the activity, not the role
*Centralize access control logic
*Design access control as a filter
*Deny by default, fail securely
*Build centralized access control mechanism
*Apply same core logic to presentation and server-side access control decisions
*Determine access control through Server-side trusted data

=Data Contextual Access Control=

'''Data Contextual / Horizontal Access Control API examples'''

ACLService.isAuthorized(EDIT_ORG, 142)
ACLService.assertAuthorized(VIEW_ORG, 900)

Long Form

isAuthorized(user, EDIT_ORG, Organization.class, 14)

*Essentially checking if the user has the right role in the context of a specific object
*Centralize access control logic
*Protecting data at the lowest level!

=Authors and Primary Editors=

Jim Manico - jim [at] owasp dot org<br/>
Fred Donovan - fred.donovan [at] owasp dot org<br/>
Mennouchi Islam Azeddine - azeddine.mennouchi [at] owasp.org

== Other Cheatsheets ==
{{Cheatsheet_Navigation}}

[[Category:Cheatsheets]]

Intrusion Detection

2015-06-20T23:59:42Z

Jkurucar: /* Description */

{{Template:Control}}

==Description==

Within the past few years, the line between Intrusion Detection and Intrusion Prevention systems (IDS and IPS respectively) has become increasingly blurred. However, these two controls are distinguished primarily by how they respond to detected attacks. While an Intrusion Detection system passively monitors for attacks and provides notification services, an Intrusion Prevention system actively stops the threat. For example, a Network Intrusion Detection system (NIDS) will monitor network traffic and alert security personnel upon discovery of an attack. A Network Intrusion Prevention system (NIPS) functions more like a stateful firewall and will automatically drop packets upon discovery of an attack.

There are two primary reasons why many organizations favor the use of IDSs over IPSs. The first is that, in the event of a false positive (normal activity mistakenly identified as an attack), an IPS will actively stop the normal activity which is likely to negatively impact business functions. An IDS, on the other hand, will only notify on the false positive and will not impact business functions while the security professional verifies the validity of the alert. The second reason is that IPSs can become a serious bottleneck. While IPSs must be placed in-line in order to actively stop attacks, and IDS may be placed on a mirrored port, thus preventing a potential bottle neck.

Intrusion detection is an important countermeasure for most applications, especially client-server applications like web applications and web services. Many newer technologies are beginning to include integrated services such as a single device that incorporates a firewall, IDS, and limited IPS functionality. [[Logging]] is an important aspect of intrusion detection, but is best viewed as a way to record intrusion-related activity, not to determine what is an intrusion in the first place. The vast majority of applications do not detect attacks, but instead try their best to fulfill the attackers' requests.

Lack of intrusion detection allows an attacker to attempt attacks until a successful one is identified. Intrusion detection allows the attack to be identified long before a successful attack is likely. It is not very difficult for a web application to identify some attack traffic. A simple rule-of-thumb is that if the traffic could not have reasonably been generated by a legitimate user of the application, it is almost certainly an attack. Once alerted by the IDS and the attacks are identified, then the security professional can respond appropriately. Typically, this means logging off the user, invalidating their account, potentially recording information for the authorities, or patching the root cause vulnerability.

There are three types of requests that an application might receive:
* Almost certainly an attack
* Not sure whether it an attack or not
* Almost certainly legitimate input

The question for application developers is how to deal with these three categories. The safest rule is to assume that everything except legitimate traffic is an attack. However, this will probably create a lot of false alarms for users. So perhaps it is best to accept the requests that you are not sure about and log some extra information so that you can investigate it later. This is a policy decision that you should make during the requirements phase of the lifecycle.

In terms of the accuracy of an IDS, there are four possible states for each activity observed. A true positive state is when the IDS identifies an activity as an attack and the activity is actually an attack. A true positive is a successful identification of an attack. A true negative state is similar. This is when the IDS identifies an activity as acceptable behavior and the activity is actually acceptable. A true negative is successfully ignoring acceptable behavior. Neither of these states are harmful as the IDS is performing as expected. A '''false positive''' state is when the IDS identifies an activity as an attack but the activity is acceptable behavior. A false positive is a false alarm. A '''false negative''' state is the most serious and dangerous state. This is when the IDS identifies an activity as acceptable when the activity is actually an attack. That is, a false negative is when the IDS fails to catch an attack. This is the most dangerous state since the security professional has no idea that an attack took place. False positives, on the other hand, are an inconvenience at best and can cause significant issues. However, with the right amount of overhead, false positives can be successfully adjudicated; false negatives cannot.

There are different types of Intrusion Detection systems based on different approaches. The two main divisions exist between signature based IDSs and behavioral IDSs. There are multiple subcategories depending on the specific implementation. Signature based IDSs, like Snort, function like anti-virus software. They have known attack lists against which they check new activity for attacks. If the new activity matches a known attack signature, the system will generate an alert. Behavioral based IDSs work differently. They learn, through a number of methods (the most popular of which is statistical analysis), what constitutes normal behavior. Once the system has a profile of normal behavior, it aims to detect abnormal behavior, which generates alerts. Currently, signature based systems are more common since they are more reliable (less false negatives), provide less false positives, and allow for easier false positive resolution. Behavioral based IDSs tend to be less accurate (more false negatives), produce an extremely large number of false positives, and false positives are more difficult to adjudicate. That being said, it is possible for a behavioral IDS to identify novel attacks like zero day exploits, given that the novel attack varies from normal behavior. A signature based IDS cannot ever identify novel attacks like zero day exploits since it identifies attacks based on known attack signatures.

In addition, there are different types of Intrusion Detection systems based on the goal of the system. While the market on the following types of IDSs is become more and more fractured, the primary types by goal are '''Network based IDSs (NIDS)''' and '''Host based IDSs (HIDS)'''. There are some extensions of this dichotomy to include distributed IDSs and comprehensive host based security systems. However, the main distinction is the goal and placement of the IDS. A NIDS monitors network traffic, usually on a mirrored port or in-line and can be placed in a variety of locations on the network. NIDS work by inspecting network traffic and can be signature based or behavioral based. HIDS monitors system logs, application logs, and other activities on a host system such as a server or user workstation. HIDS work primarily by monitory system logs and behavior and can be signature based (include rule sets that enforce tailored security policies) or behavioral based. Most organizations use both types of IDSs. They use HIDSs to secure critical host systems and NIDSs to secure their network(s).

Best practices for the placements of NIDS is a future topic.

==Related Countermeasures==
* [[Input Validation]]
* [[Error Handling]]
* [[Logging]]

[[Category: Control]]

User:Jkurucar

2015-06-04T15:18:09Z

Jkurucar:

More than five years of experience in the IT/IS profession. Job titles include project officer, quality assurance manager, developer, and administrator. I have numerous certifications to include CISSP, Compita Security+, A+, Network+, CASQ (Certified Associate in Software Quality), CSQA (Certified Software Quality Analyst). I plan on adding CISM and CEH in the near future.

Denial of Service

2015-02-03T05:42:37Z

Jkurucar: /* Risk Factors */

{{Template:Attack}}
<br>
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==
The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.
If a service receives a very large number of requests, it may cease to be available to legitimate users. In the same way, a service may stop if a programming vulnerability is exploited, or the way the service handles resources it uses.

Sometimes the attacker can inject and execute arbitrary code while performing a DoS attack in order to access critical information or execute commands on the server.
Denial-of-service attacks significantly degrade the service quality experienced by legitimate users. These attacks introduce large response delays, excessive losses, and service interruptions, resulting in direct impact on availability.

==Risk Factors==
Risk factors can break down into multiple categories. Two principle sources of risk include inadequate resources and non-technical threat motivators.

The first example of a risk factor, inadequate resources, requires attention if system architecture was not designed to meet traffic demand overflows. This risk reduces the difficulty of successfully executing a DoS attack and can, left unchecked, result in DoS symptoms absent an actual attack.

The second example and perhaps the largest risk factor is not technical and is in the domain of public relations or strategic communications. An organization should avoid taking action that can make them a target of a DoS attack unless the benefits of doing so outweigh the potential costs or mitigating controls are in place.

Other risk factors may also exist depending on the specific environment.
[[Category:FIXME|need content]]

==Examples ==
The following DoS techniques and examples were extracted from OWASP Testing Guide v2.

===DoS User Specified Object Allocation===

If users can supply, directly or indirectly, a value that will specify how many of an object to create on the application server, and if the server does not enforce a hard upper limit on that value, it is possible to cause the environment to run out of available memory. The server may begin to allocate the required number of objects specified, but if this is an extremely large number, it can cause serious issues on the server, possibly filling its whole available memory and corrupting its performance.

The following is a simple example of vulnerable code in Java:

String TotalObjects = request.getParameter(“numberofobjects”);
int NumOfObjects = Integer.parseInt(TotalObjects);
ComplexObject[] anArray = new ComplexObject[NumOfObjects]; // wrong!

===DoS User Input as a Loop Counter===

Similar to the previous problem of User Specified Object Allocation, if the user can directly or indirectly assign a value that will be used as a counter in a loop function, this can cause performance problems on the server.

The following is an example of vulnerable code in Java:

public class MyServlet extends ActionServlet {
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
. . .
String [] values = request.getParameterValues("CheckboxField");
// Process the data without length check for reasonable range – wrong!
for ( int i=0; i<values.length; i++) {
// lots of logic to process the request
}
. . .
}
. . .
}

As we can see in this simple example, the user has control over the loop counter. If the code inside the loop is very demanding in terms of resources, and an attacker forces it to be executed a very high number of times, this might decrease the performance of the server in handling other requests, causing a DoS condition.

===DoS Failure to Release Resources===

If an error occurs in the application that prevents the release of an in-use resource, it can become unavailable for further use. Possible examples include:
* An application locks a file for writing, and then an exception occurs but does not explicitly close and unlock the file
* Memory leaking in languages where the developer is responsible for memory management such as C & C++. In the case where an error causes normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should be reclaimed
* Use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the DB connections, as the code will still hold the open DB object, never releasing the resource.
The following is an example of vulnerable code in Java. In the example, both the Connection and the CallableStatement should be closed in a finally block.
public class AccountDAO {
… …
public void createAccount(AccountInfo acct)
throws AcctCreationException {
… …
try {
Connection conn = DAOFactory.getConnection();
CallableStatement calStmt = conn.prepareCall(…);
… …
calStmt.executeUpdate();
calStmt.close();
conn.close();
} catch (java.sql.SQLException e) {
throw AcctCreationException (...);
}
}
}

===DoS Buffer Overflows===

Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a [[Buffer Overflow]]. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes.

The following is a simplified example of vulnerable code in C:
void overflow (char *str) {
char buffer[10];
strcpy(buffer, str); // Dangerous!
}

int main () {
char *str = "This is a string that is larger than the buffer of 10";
overflow(str);
}

If this code example were executed, it would cause a segmentation fault and dump core. The reason is that strcpy would try to copy 53 characters into an array of 10 elements only, overwriting adjacent memory locations. While this example above is an extremely simple case, the reality is that in a web based application there may be places where the user input is not adequately checked for its length, making this kind of attack possible.

===DoS Storing too Much Data in Session===

Care must be taken not to store too much data in a user session object. Storing too much information in the session, such as large quantities of data retrieved from the database, can cause denial of service issues. This problem is exacerbated if session data is also tracked prior to a login, as a user can launch the attack without the need of an account.

===DoS Locking Customer Accounts===

The first DoS case to consider involves the authentication system of the target application. A common defense to prevent brute-force discovery of user passwords is to lock an account from use after between three to five failed attempts to login. This means that even if a legitimate user were to provide their valid password, they would be unable to login to the system until their account has been unlocked. This defense mechanism can be turned into a DoS attack against an application if there is a way to predict valid login accounts.

Note, there is a business vs. security balance that must be reached based on the specific circumstances surrounding a given application. There are pros and cons to locking accounts, to customers being able to choose their own account names, to using systems such as CAPTCHA, and the like. Each enterprise will need to balance these risks and benefits, but not all of the details of those decisions are covered here.

==Related [[Threat Agents]]==
* [[:Category:Logical Attacks]]
[[Category:FIXME|not a threat agent]]

==Related [[Attacks]]==
* [[Resource Injection]]
* [[Setting Manipulation]]
* [[Regular expression Denial of Service - ReDoS]]
* [[Cash Overflow]]

==Related [[Vulnerabilities]]==
* [[:Category: Input Validation Vulnerability]]
* [[:Category: API Abuse]]

==Related [[Controls]]==
* [[Blocking Brute Force Attacks]]
* [[Memory Management]]

==References==
* http://capec.mitre.org/data/index.html - Denial of Service through Resource Depletion

[[Category: Spoofing]]
[[Category: Probabilistic Techniques]]
[[Category: Resource Depletion]]
[[Category:Attack]]