OWASP - User contributions [en]

Access Control Cheat Sheet

2014-09-11T21:42:42Z

Kcfredman:

= 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.

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

2014-03-27T23:01:14Z

Kcfredman: /* Activity Based Access Control (ABAC) */

= 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 defininitions are frequently confused.

Access Control is the method or mechanism of authorization to enfore 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

== 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 concurency?'''

==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

2012-03-11T20:21:43Z

Kcfredman: /* Hard Coded Roles */

=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 defininitions are frequently confused.

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

'''Role Based Access Control (RBAC)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.

'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an operating system.

'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be dominated by the object being written to the system. To "read down", a subject's clearance level must govern the security level of the object being read. In this system, a subject may be able to write to an object, but will never be able to read it. This prevents malicious software from being able to leak data from different classification levels. "Write up" prevents leakage from high to low.
(See the [http://csrc.nist.gov/publications/history/dod85.pdf Orange Book] for more information about classification levels and confidentiality controls in "DAC" and "MAC".)

=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)

<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

==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 concurency?'''

==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

=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 [manico] dot net

Fred Donovan - fred.donovan [at] owasp dot org

Access Control Cheat Sheet

2012-03-11T19:09:27Z

Kcfredman: /* Data Contextual Access Control */

=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 defininitions are frequently confused.

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

'''Role Based Access Control (RBAC)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.

'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an operating system.

'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be dominated by the object being written to the system. To "read down", a subject's clearance level must govern the security level of the object being read. In this system, a subject may be able to write to an object, but will never be able to read it. This prevents malicious software from being able to leak data from different classification levels. "Write up" prevents leakage from high to low.
(See the [http://csrc.nist.gov/publications/history/dod85.pdf Orange Book] for more information about classification levels and confidentiality controls in "DAC" and "MAC".)

=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)

<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

==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

==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 concurency?'''

==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

=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 [manico] dot net

Fred Donovan - fred.donovan [at] owasp dot org

Access Control Cheat Sheet

2012-03-11T19:04:47Z

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

=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 defininitions are frequently confused.

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

'''Role Based Access Control (RBAC)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.

'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an operating system.

'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be dominated by the object being written to the system. To "read down", a subject's clearance level must govern the security level of the object being read. In this system, a subject may be able to write to an object, but will never be able to read it. This prevents malicious software from being able to leak data from different classification levels. "Write up" prevents leakage from high to low.
(See the [http://csrc.nist.gov/publications/history/dod85.pdf Orange Book] for more information about classification levels and confidentiality controls in "DAC" and "MAC".)

=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)

<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

==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

==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 concurency?'''

==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

=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 a the lowest level!

=Authors and Primary Editors=

Jim Manico = jim [manico] dot net

Fred Donovan - fred.donovan [at] owasp dot org

Access Control Cheat Sheet

2012-03-11T18:21:03Z

Kcfredman: /* Access Control Issues */

=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 defininitions are frequently confused.

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

'''Role Based Access Control (RBAC)''' is commonly used to manage permissions within an application. Permissions are assigned to users in a many to many relationship.

'''Discretioinary Access Control (DAC)''' is commonly used to manage permissions within an application.

'''Mandatory Access Control (MAC)''' is a classification based system of objects and subjects. To "write up", a subject's clearance level must be

=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)

<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

==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

==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 concurency?'''

==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

=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 a the lowest level!

=Authors and Primary Editors=

Jim Manico = jim [manico] dot net

Fred Donovan - fred.donovan [at] owasp dot org

Cryptographic Storage Cheat Sheet

2011-07-30T08:25:48Z

Kcfredman:

= Introduction =

This article provides a simple model to follow when implementing solutions for data at rest.<br>

== Architectural Decision ==

An architectural decision must be made to determine the appropriate method to protect data at rest. There are such wide varieties of products, methods and mechanisms for cryptographic storage. This cheat sheet will only focus on low-level guidelines for developers and architects who are implementing cryptographic solutions. We will not address specific vendor solutions, nor will we address the design of cryptographic algorithms.

= Providing Cryptographic Functionality =

== Benefits ==

== Basic Requirements ==

== Secure Cryptographic Storage Design ==

=== Rule - Only store sensitive data that you need ===

Many eCommerce businesses utilize third party payment providers to store credit card information for recurring billing. This offloads the burden of keeping credit card numbers safe.

=== Rule - Only use strong cryptographic algorithms ===

Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing. Do not use weak algorithms, such as MD5 or SHA1. Note that the classification of a "strong" cryptographic algorithm can change over time.

http://csrc.nist.gov/groups/STM/cavp/index.html

The CAVP program located at the above link is a good default place to go for validation of cryptographic algorithms when one does not have AES or one of the authenticated encryption modes that provide confidentiality and authenticity (i.e., data origin authentication) such as CCM, EAX, CMAC, etc. For Java, if you are using SunJCE that will be the case. The cipher modes supported in JDK 1.5 and later are CBC, CFB, CFBx, CTR, CTS, ECB, OFB, OFBx, PCBC. None of these cipher modes are authenticated encryption modes. (That's why it is added explicitly.) If you are using an alternate JCE provider such as Bouncy Castle, RSA JSafe, IAIK, etc., then some of these authenticated encryption modes probably should be preferred.

Use salts when appropriate. Note that integrity should use a MAC such as HMAC-SHA256 or HMAC-SHA512 which is a better choice.

==== Rule - Ensure that random numbers are cryptographically strong ====

Ensure that all random numbers, random file names, random GUIDs, and random strings are generated in a cryptographically strong fashion. Also ensure that random algorithms are seeded with sufficient entropy.

==== Rule - Only use widely accepted implementations of cryptographic algorithms ====

Do not implement an existing cryptographic algorithm on your own, no matter how easy it appears. Instead, use widely accepted algorithms and widely accepted implementations. Ensure that the implementation has (at minimum) had some cryptography experts involved in its creation. If possible, use an implementation that is FIPS 140-2 certified.

==== Rule - Prefer authenticated encryption modes ====

Use cryptographic cipher modes that offer both confidentiality and authenticity. Recommended modes include counter with CBC-MAC (CCM) mode and Galois/counter mode (GCM). These authenticated encryption (AE) modes resist padding oracle attacks which can be used in many cases to recover plaintext from ciphertext without knowledge of the encryption key.

If an authenticated encryption mode is not available, then the best option is to consult with a professional cryptographer. Ask the cryptographer to review and customize the system to counter padding oracle attacks. This customization will typically involve the use of a message authentication code (MAC) that must be carefully employed in order to be effective.

In the worst case, where neither an AE mode nor a professional cryptographer are available, then the cryptography is definitely vulnerable to a padding oracle attack. The best that can be done in this situation is to design the overall system so that the decryption function is only given ciphertext that is retrieved directly from a canonical source which itself must be protected by other integrity controls. While this technique will help reduce the risk of a padding oracle attack, it does not eliminate the risk, and it should be treated as a temporary workaround until an AE-based solution can be implemented.

When selecting a cryptographic mode for this worse case, cipher-block chaining (CBC) mode is a strong choice as it has been carefully studied, is well understood, and is readily available in many cryptographic APIs. In all cases avoid the electronic codebook (ECB) mode. If using cipher modes that create streaming ciphers from block ciphers, such as the output feedback (OFB) or cipher feedback (CFB) modes, be careful not to repeat the IV for the same encryption key.

See [http://www.cryptopp.com/wiki/Authenticated_Encryption Authenticated Encryption] on the Crypto++ wiki for a more complete discussion of the technique. NIST's CRSC [http://csrc.nist.gov/groups/ST/toolkit/BCM/current_modes.html Current Modes] and [http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html Modes Development] documents offer an abbreviated list of cipher modes. Additional block cipher modes can be found in Wikipedia's [http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation Block cipher modes of operation] article.

=== Rule - Store the hashed and salted value of passwords ===

Store the salted hashed value of the password. Salt each hash. Preferably use a different random salt for each password hash instead of a constant long salt. Never store the clear text password or an encrypted version of the password.

Cryptographic framework for password hashing is described in [http://www.rsa.com/rsalabs/node.asp?id=2127 PKCS #5 v2.1: Password-Based Cryptography Standard]. Specific secure password hashing algorithms exist such as [http://www.usenix.org/events/usenix99/provos/provos_html/node1.html bcrypt], [http://www.tarsnap.com/scrypt/scrypt.pdf scrypt]. Implementations of secure password hashing exist for PHP ([http://www.openwall.com/phpass/ phpass]), ASP.NET ([http://msdn.microsoft.com/en-us/library/ms998372.aspx#pagpractices0001_sensitivedata ASP.NET 2.0 Security Practices]), Java ([http://www.owasp.org/index.php/Hashing_Java OWASP Hashing Java]).

=== Rule - Ensure that the cryptographic protection remains secure even if access controls fail ===

This rule supports the principle of defense in depth. Access
controls (usernames, passwords, privileges, etc.) are one layer of
protection. Storage encryption should add an additional layer of
protection that will continue protecting the data even if an
attacker subverts the database access control layer.

=== Rule - Ensure that any secret key is protected from unauthorized access ===

==== Rule - Define a key lifecycle ====

The key lifecycle details the various states that a key will move through during its life. The lifecycle will specify when a key should no longer be used for encryption, when a key should no longer be used for decryption (these are not necessarily coincident), whether data must be rekeyed when a new key is introduced, and when a key should be removed from use all together.

==== Rule - Store unencrypted keys away from the encrypted data ====

If the keys are stored with the data then any compromise of the data will easily compromise the keys as well. Unencrypted keys should never reside on the same machine or cluster as the data.

==== Rule - Use independent keys when multiple keys are required ====

Ensure that key material is independent. That is, do not choose a second key which is easily related to the first (or any preceeding) keys.

==== Rule - Protect keys in a key vault ====

Keys should remain in a protected key vault at all times. In particular, ensure that there is a gap between the threat vectors that have direct access to the data and the threat vectors that have direct access to the keys. This implies that keys should not be stored on the application or web server (assuming that application attackers are part of the relevant threat model).

==== Rule - Document concrete procedures for managing keys through the lifecycle ====

These procedures must be written down and the key custodians must be adequately trained.

==== Rule - Build support for changing keys periodically ====

Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).

==== Rule - Document concrete procedures to handle a key compromise ====

==== Rule - Rekey data at least every one to three years ====

Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.

=== Rule - Follow applicable regulations on use of cryptography ===

==== Rule - Under PCI DSS requirement 3, you must protect cardholder data ====

The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. The standard was introduced in 2005 and replaced individual compliance standards from Visa, Mastercard, Amex, JCB and Diners. The current version of the standard is 2.0 and was initialized on January 1, 2011.

PCI DSS requirement 3 covers secure storage of credit card data. This requirement covers several aspects of secure storage including the data you must never store but we are covering Cryptographic Storage which is covered in requirements 3.4, 3.5 and 3.6 as you can see below:

'''3.4 Render PAN (Primary Account Number), at minimum, unreadable anywhere it is stored'''

Compliance with requirement 3.4 can be met by implementing any of the four types of secure storage described in the standard which includes encrypting and hashing data. These two approaches will often be the most popular choices from the list of options. The standard doesn't refer to any specific algorithms but it mandates the use of '''Strong Cryptography'''. The glossary document from the PCI council defines '''Strong Cryptography''' as:

''Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). SHA-1 is an example of an industry-tested and accepted hashing algorithm. Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher).''

If you have implemented the second rule in this cheat sheet you will have implemented a strong cryptographic algorithm which is compliant with or stronger than the requirements of PCI DSS requirement 3.4. You need to ensure that you identify all locations that card data could be stored including logs and apply the appropriate level of protection. This could range from encrypting the data to replacing the card number in logs.

This requirement can also be met by implementing disk encryption rather than file or column level encryption. The requirements for '''Strong Cryptography''' are the same for disk encryption and backup media. The card data should never be stored in the clear and by following the guidance in this cheat sheet you will be able to securely store your data in a manner which is compliant with PCI DSS requirement 3.4

'''3.5 Protect any keys used to secure cardholder data against disclosure and misuse'''

As the requirement name above indicates, we are required to securely store the encryption keys themselves. This will mean implementing strong access control, auditing and logging for your keys. The keys must be stored in a location which is both secure and "away" from the encrypted data. This means key data shouldn't be stored on web servers, database servers etc

Access to the keys must be restricted to the smallest amount of users possible. This group of users will ideally be users who are highly trusted and trained to perform Key Custodian duties. There will obviously be a requirement for system/service accounts to access the key data to perform encryption/decryption of data.

The keys themselves shouldn't be stored in the clear but encrypted with a KEK (Key Encrypting Key). The KEK must not be stored in the same location as the encryption keys it is encrypting.

'''3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data'''

Requirement 3.6 mandates that key management processes within a PCI compliant company cover 8 specific key lifecycle steps:

'''3.6.1 Generation of strong cryptographic keys'''

As we have previously described in this cheat sheet we need to use algorithms which offer high levels of data security. We must also generate strong keys so that the security of the data isn't undermined by weak cryptographic keys. A strong key is generated by using a key length which is sufficient for your data security requirements and compliant with the PCI DSS. The key size alone isn't a measure of the strength of a key. The data used to generate the key must be sufficiently random ("sufficient" often being determined by your data security requirements) and the entropy of the key data itself must be high.<br>

'''3.6.2 Secure cryptographic key distribution'''

The method used to distribute keys must be secure to prevent the theft of keys in transit. The use of a protocol such as Diffie Hellman can help secure the distribution of keys, the use of secure transport such as SSLv3, TLS and SSHv2 can also secure the keys in transit.<br>

'''3.6.3 Secure cryptographic key storage'''

The secure storage of encryption keys including KEK's has been touched on in our description of requirement 3.5 (see above).

'''3.6.4 Periodic cryptographic key changes'''

The PCI DSS standard mandates that keys used for encryption must be rotated at least annually. The key rotation process must remove an old key from the encryption/decryption process and replace it with a new key. All new data entering the system must encrypted with the new key. While it is recommended that existing data be rekeyed with the new key, as per the Rekey data at least every one to three years rule above, it is not clear that the PCI DSS requires this.

'''3.6.5 Retirement or replacement of keys as deemed necessary when the integrity of the key has been weakened or keys are suspected of being compromised'''

The key management processes must cater for archived, retired or compromised keys. The process of securely storing and replacing these keys will more than likely be covered by your processes for requirements 3.6.2, 3.6.3 and 3.6.4

'''3.6.6 Split knowledge and establishment of dual control of cryptographic keys'''

The requirement for split knowledge and/or dual control for key management prevents an individual user performing key management tasks such as key rotation or deletion. The system should require two individual users to perform an action (i.e. entering a value from their own OTP) which creates to separate values which are concatenated to create the final key data.

'''3.6.7 Prevention of unauthorized substitution of cryptographic keys'''

The system put in place to comply with requirement 3.6.6 can go a long way to preventing unauthorised substitution of key data. In addition to the dual control process you should implement strong access control, auditing and logging for key data so that unauthorised access attempts are prevented and logged.

'''3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their key-custodian responsibilities '''

To perform the strong key management functions we have seen in requirement 3.6 we must have highly trusted and trained key custodians who understand how to perform key management duties. The key custodians must also sign a form stating they understand the responsibilities that come with this role.

= Related Articles =

OWASP - [[Testing for SSL-TLS (OWASP-CM-001)|Testing for SSL-TLS]], and OWASP [[Guide to Cryptography]]

OWASP – [http://www.owasp.org/index.php/ASVS Application Security Verification Standard (ASVS) – Communication Security Verification Requirements (V10)]

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Kevin Kenan - kevin[at]k2dd.com

David Rook - david.a.rook[at]gmail.com

Kevin Wall - kevin.w.wall[at]gmail.com

Jim Manico - jim[at]manico.net

Fred Donovan - fred.donovan(at)owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Session Management Cheat Sheet

2011-07-29T07:36:12Z

Kcfredman:

= Introduction =

'''Web Authentication, Session Management, and Access Control'''

A web session is a sequence of network HTTP request and response transactions associated to the same user. Modern and complex web applications require the retaining of information or status about each user for the duration of multiple requests. Therefore, sessions provide the ability to establish variables – such as access rights and localization settings – which will apply to each and every interaction a user has with the web application for the duration of the session.

Web applications can create sessions to keep track of anonymous users after the very first user request. An example would be maintaining the user language preference. Additionally, web applications will make use of sessions once the user has authenticated. This ensures the ability to identify the user on any subsequent requests as well as being able to apply security access controls, authorized access to the user private data, and to increase the usability of the application. Therefore, current web applications can provide session capabilities both pre and post authentication.

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP), client-based digital certificates, smartcards, or biometrics (such as fingerprint or eye retina). See the OWASP Authentication Cheat Sheet: [https://www.owasp.org/index.php/Authentication_Cheat_Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet].

HTTP is a stateless protocol (RFC2616 [5]), where each request and response pair is independent of other web interactions. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and access control (or authorization) modules commonly available in web applications:

[[Image:Session-Management-Diagram Cheat-Sheet.png|center|Session-Management-Diagram Cheat-Sheet.png]] <br> The session ID or token binds the user authentication credentials (in the form of a user session) to the user HTTP traffic and the appropriate access controls enforced by the web application. The complexity of these three components (authentication, session management, and access control) in modern web applications, plus the fact that its implementation and binding resides on the web developer’s hands (as web development framework do not provide strict relationships between these modules), makes the implementation of a secure session management module very challenging.

The disclosure, capture, prediction, brute force, or fixation of the session ID will lead to session hijacking (or sidejacking) attacks, where an attacker is able to fully impersonate a victim user in the web application. Attackers can perform two types of session hijacking attacks, targeted or generic. In a targeted attack, the attacker’s goal is to impersonate a specific (or privileged) web application victim user. For generic attacks, the attacker’s goal is to impersonate (or get access as) any valid or legitimate user in the web application.

<br>

= Session ID Properties =

In order to keep the authenticated state and track the users progress within the web application, applications provide users with a session identifier (session ID or token) that is assigned at session creation time, and is shared and exchanged by the user and the web application for the duration of the session (it is sent on every HTTP request). The session ID is a “name=value” pair.

With the goal of implementing secure session IDs, the generation of identifiers (IDs or tokens) must meet the following properties:

== Session ID Name Fingerprinting ==

The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”.

== Session ID Length ==

The session ID must be long enough to prevent brute force attacks, where an attacker can go through the whole range of ID values and verify the existence of valid sessions.

The session ID length must be at least 128 bits (16 bytes).

== Session ID Entropy ==

The session ID must be unpredictable (random enough) to prevent guessing attacks, where an attacker is able to guess or predict the ID of a valid session through statistical analysis techniques. For this purpose, a good PRNG (Pseudo Random Number Generator) must be used.

The session ID value must provide at least 64 bits of entropy (if a good PRNG is used, this value is estimated to be half the length of the session ID).<br>

'''''NOTE''''': The session ID entropy is really affected by other external and difficult to measure factors, such as the number of concurrent active sessions the web application commonly has, the absolute session expiration timeout, the amount of session ID guesses per second the attacker can make and the target web application can support, etc [2]. If a session ID with an entropy of 64 bits is used, it will take an attacker at least 292 years to successfully guess a valid session ID, assuming the attacker can try 10,000 guesses per second with 100,000 valid simultaneous sessions available in the web application [2].

== Session ID Content (or Value) ==

The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.

The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.

It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).

<br>

= Session Management Implementation =

The session management implementation defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID. There are multiple mechanisms available in HTTP to maintain session state within web applications, such as cookies (standard HTTP header), URL parameters (URL rewriting – RFC 2396), URL arguments on GET requests, body arguments on POST requests, such as hidden form fields (HTML forms), or proprietary HTTP headers.

The preferred session ID exchange mechanism should allow defining advanced token properties, such as the token expiration date and time, or granular usage constraints. This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods.

The usage of specific session ID exchange mechanisms, such as those where the ID is included in the URL, might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines), as well as facilitate other attacks, such as the manipulation of the ID or session fixation attacks [3].

== Built-in Session Management Implementations ==

Web development frameworks, such as J2EE, ASP .NET, PHP, and others, provide their own session management features and associated implementation. It is recommended to use these built-in frameworks versus building a home made one from scratch, as they are used worldwide on multiple web environments and have been tested by the web application security and development communities over time.

However, be advised that these frameworks have also presented vulnerabilities and weaknesses in the past, so it is always recommended to use the latest version available, that potentially fixes all the well-known vulnerabilities, as well as review and change the default configuration to enhance its security by following the recommendations described along this document.

The storage capabilities or repository used by the session management mechanism to temporarily save the session IDs must be secure, protecting the session IDs against local or remote accidental disclosure or unauthorized access.

== Used vs. Accepted Session ID Exchange Mechanisms ==

A specific web application can make use of a particular session ID exchange mechanism by default, such as cookies. However, if a user submits a session ID through a different exchange mechanism, such as a URL parameter, the web application might accept it. Effectively, the web application can use both mechanisms, cookies or URL parameters, or even switch from one to the other (automatic URL rewriting) if certain conditions are met (for example, the existence of web clients without cookies support or when cookies are not accepted due to user privacy concerns).

For this reason, it is crucial to differentiate between the mechanisms used by the web application (by default) to exchange session IDs and the mechanisms accepted by the web application to process and manage session IDs. Web applications must limit the accepted session tracking mechanisms to only those selected and used by design.

== Transport Layer Security ==

In order to protect the session ID exchange from active eavesdropping and passive disclosure in the network traffic, it is mandatory to use an encrypted HTTPS (SSL/TLS) connection for the entire web session, not only for the authentication process where the user credentials are exchanged.

Additionally, the “Secure” cookie attribute (see below) must be used to ensure the session ID is only exchanged through an encrypted channel. The usage of an encrypted communication channel also protects the session against some session fixation attacks where the attacker is able to intercept and manipulate the web traffic to inject (or fix) the session ID on the victims web browser [4].

The following set of HTTPS (SSL/TLS) best practices are focused on protecting the session ID (specifically when cookies are used) and helping with the integration of HTTPS within the web application:

*Web applications should never switch a given session from HTTP to HTTPS, or viceversa, as this will disclose the session ID in the clear through the network.
*Web applications should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute), as the request of any web object over an unencrypted channel might disclose the session ID.
*Web applications, in general, should not offer public unencrypted contents and private encrypted contents from the same host. It is recommended to instead use two different hosts, such as www.example.com over HTTP (unencrypted) for the public contents, and secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist). The former host only has port TCP/80 open, while the later only has port TCP/443 open.
*Web applications should avoid the extremely common HTTP to HTTPS redirection on the home page (using a 30x HTTP response), as this single unprotected HTTP request/response exchange can be used by an attacker to gather (or fix) a valid session ID.

See the OWASP Transport Layer Protection Cheat Sheet: [https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet].

It is important to emphasize that SSL/TLS (HTTPS) does not protect against session ID prediction, brute force, client-side tampering or fixation. Yet, session ID disclosure and capture from the network traffic is one of the most prevalent attack vectors even today.

<br>

= Cookies =

The session ID exchange mechanism based on cookies provides multiple security features in the form of cookie attributes that can be used to protect the exchange of the session ID:

== Secure Attribute ==

The “Secure” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic.

Forcing the web application to only use HTTPS for its communication (even when port TCP/80, HTTP, is closed in the web application host) does not protect against session ID disclosure if the “Secure” cookie has not been set - the web browser can be deceived to disclose the session ID over an unencrypted HTTP connection. The attacker can intercept and manipulate the victim user traffic and inject an HTTP unencrypted reference to the web application that will force the web browser to submit the session ID in the clear.

== HttpOnly Attribute ==

The “HttpOnly” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.

See the OWASP XSS Prevention Cheat Sheet: [https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet].

== Domain and Path Attributes ==

The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server. The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.

It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.

Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.

Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].

Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.

Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.

== Expire and Max-Age Attributes ==

Session management mechanisms based on cookies can make use of two types of cookies, non-persistent (or session) cookies, and persistent cookies. If a cookie presents the “Max-Age” (that has preference over “Expires”) or “Expires” attributes, it will be considered a persistent cookie and will be stored on disk by the web browser based until the expiration time. Typically, session management capabilities to track users after authentication make use of non-persistent cookies. This forces the session to disappear from the client if the current web browser instance is closed. Therefore, it is highly recommended to use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.

<br>

= Session ID Life Cycle =

== Session ID Generation and Verification: Permissive and Strict Session Management ==

There are two types of session management mechanisms for web applications, permissive and strict, related to session fixation vulnerabilities. The permissive mechanism allow the web application to initially accept any session ID value set by the user as valid, creating a new session for it, while the strict mechanism enforces that the web application will only accept session ID values that have been previously generated by the web application.

Although the most common mechanism in use today is the strict one (more secure). Developers must ensure that the web application does not use a permissive mechanism under certain circumstances. Web applications should never accept a session ID they have never generated, and in case of receiving one, they should generate and offer the user a new valid session ID. Additionally, this scenario should be detected as a suspicious activity and an alert should be generated.

== Manage Session ID as Any Other User Input ==

Session IDs must be considered untrusted, as any other user input processed by the web application, and they must be thoroughly validated and verified. Depending on the session management mechanism used, the session ID will be received in a GET or POST parameter, in the URL or in an HTTP header (e.g. cookies). If web applications do not validate and filter out invalid session ID values before processing them, they can potentially be used to exploit other web vulnerabiilties, such as SQL injection if the session IDs are stored on a relational database, or persistent XSS if the session IDs are stored and reflected back afterwards by the web application.

== Renew the Session ID After Any Privilege Level Change ==

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.

The most common web development frameworks provide session functions and methods to renew the session ID, such as “request.getSession(true) & HttpSession.invalidate()” (J2EE), “Session.Abandon() & Response.Cookies.Add(new…)“ (ASP .NET), or “session_start() & session_regenerate_id(true)” (PHP).

The session ID regeneration is mandatory to prevent session fixation attacks [3], where an attacker sets the session ID on the victims user web browser instead of gathering the victims session ID, as in most of the other session-based attacks, and independently of using HTTP or HTTPS. This protection mitigates the impact of other web-based vulnerabilities that can also be used to launch session fixation attacks, such as HTTP response splitting or XSS [4].

A complementary recommendation is to use a different session ID or token name (or set of session IDs) pre and post authentication, so that the web application can keep track of anonymous users and authenticated users without the risk of exposing or binding the user session between both states.

== Considerations When Using Multiple Cookies ==

If the web application uses cookies as the session ID exchange mechanism, and multiple cookies are set for a given session, the web application must verify all cookies (and enforce relationships between them) before allowing access to the user session.

It is very common for web applications to set a user cookie pre-authentication over HTTP to keep track of unauthenticated (or anonymous) users. Once the user authenticates in the web application, a new post-authentication secure cookie is set over HTTPS, and a binding between both cookies and the user session is established. If the web application does not verify both cookies for authenticated sessions, an attacker can make use of the pre-authentication unprotected cookie to get access to the authenticated user session [4].

<br>

= Session Expiration =

In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based attacks, as for the attacker to be able to reuse a valid session ID and hijack the associated session, it must still be active.

The shorter the session interval is, the lesser the time an attacker has to use the valid session ID. The session expiration timeout values must be set accordingly with the purpose and nature of the web application, and balance security and usability, so that the user can comfortably complete the operations within the web application without his session frequently expiring. Both the idle and absolute timeout values are highly dependent on the criticality of the web application and its data. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15- 30 minutes for low risk applications.

When a session expires, the web application must take active actions to invalidate the session on both sides, client and server. The later is the most relevant and mandatory from a security perspective.

For most session exchange mechanisms, client side actions to invalidate the session ID are based on clearing out the token value. For example, to invalidate a cookie it is recommended to provide an empty (or invalid) value for the session ID, and set the “Expires” (or “Max-Age”) attribute to a date from the past (in case a persistent cookie is being used):
<pre>Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00 GMT </pre>
In order to close and invalidate the session on the server side, it is mandatory for the web application to take active actions when the session expires, or the user actively logs out, by using the functions and methods offered by the session management mechanisms, such as “HttpSession.invalidate()” (J2EE), “Session.Abandon()“ (ASP .NET) or “session_destroy()/unset()“ (PHP).

== Automatic Session Expiration ==

=== Idle Timeout ===

All sessions should implement an idle or inactivity timeout. This timeout defines the amount of time a session will remain active in case there is no activity in the session, closing and invalidating the session upon the defined idle period since the last HTTP request received by the web application for a given session ID.

The idle timeout limits the chances an attacker has to guess and use a valid session ID from another user. However, if the attacker is able to hijack a given session, the idle timeout does not limit the attacker’s actions, as he can generate activity on the session periodically to keep the session active for longer periods of time.

Session timeout management and expiration must be enforced server-side. If the client is used to enforce the session timeout, an attacker could use the session token or other client parameters to track time references (e.g. login time) and extend the session duration.

=== Absolute Timeout ===

All sessions should implement an absolute timeout, regardless of session activity. This timeout defines the maximum amount of time a session can be active, closing and invalidating the session upon the defined absolute period since the given session was initially created by the web application. After invalidating the session, the user is forced to (re)authenticate again in the web application and establish a new session.

The absolute session limits the amount of time an attacker can use a hijacked session and impersonate the victim user.

== Manual Session Expiration ==

Web applications should provide mechanisms that allow security aware users to actively close their session once they have finished using the web application.

=== Logout Button ===

Web applications must provide a visible an easily accessible logout (logoff, exit, or close session) button that is available on the web application header or menu and reachable from every web application resource and page, so that the user can manually close the session at any time.

== Web Content Caching ==

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the “Cache-Control: no-cache,no-store” and “Pragma: no-cache” HTTP headers [5], and/or equivalent META tags on all or (at least) sensitive web pages.

Independently of the cache policy defined by the web application, if caching web application contents is allowed, the session IDs must never be cached, so it is highly recommended to use the “Cache-Control: no-cache="Set-Cookie"” directive, to allow web clients to cache everything except the session ID.

<br>

= Additional Client-Side Defenses for Session Management =

Web applications can complement the previously described session management defenses with additional countermeasures on the client side. Client-side protections, typically in the form of JavaScript checks and verifications, are not bullet proof and can easily be defeated by a skilled attacker, but can introduce another layer of defense that has to be bypassed by the attacker.

== Initial Login Timeout ==

Web applications can use JavaScript code in the login page to evaluate and measure the amount of time since the page was loaded and a session ID was granted. If a login attempt is tried after a specific amount of time, the client code can notify the user that the maximum amount of time to log in has passed and reload the login page, hence retrieving a new session ID.

This extra protection mechanism tries to force the renewal of the session ID pre-authentication, avoiding scenarios where a previously used (or manually set) session ID is reused by the next victim using the same computer, for example, in session fixation attacks.

== Force Session Logout On Web Browser Window Close Events ==

Web applications can use JavaScript code to capture all the web browser tab or window close (or even back) events and take the appropriate actions to close the current session before closing the web browser, emulating that the user has manually closed the session via the logout button.

== Disable Web Browser Cross-Tab Sessions ==

Web applications can use JavaScript code once the user has logged in and a session has been established to force the user to reauthenticate if a new web browser tab or window is opened against the same web application. The web application does not want to allow multiple web browser tabs or windows to share the same session. Therefore, the application tries to force the web browser to not share the same session ID simultaneously between them.

'''''NOTE''''': This mechanism cannot be implemented if the session ID is exchanged throughout cookies, as cookies are shared by all web browser tab/windows. 

<br>

= Session Attacks Detection =

== Session ID Guessing and Brute Force Detection ==

If an attacker tries to guess or brute force a valid session ID, he needs to launch multiple sequential requests against the target web application using different session IDs from a single (or set of) IP address(es). Additionally, if an attacker tries to analyze the predictability of the session ID (e.g. using statistical analysis), he needs to launch multiple sequential requests from a single (or set of) IP address(es) against the target web application to gather new valid session IDs.

Web applications must be able to detect both scenarios based on the number of attempts to gather (or use) different session IDs and alert and/or block the offending IP address(es).

== Detecting Session ID Anomalies ==

Web applications should focus on detecting anomalies associated to the session ID, such as its manipulation. The OWASP AppSensor Project [7] provides a framework and methodology to implement built-in intrusion detection capabilities within web applications focused on the detection of anomalies and unexpected behaviors, in the form of detection points and response actions. Instead of using external protection layers, sometimes the business logic details and advanced intelligence are only available from inside the web application, where it is possible to establish multiple session related detection points, such as when an existing cookie is modified or deleted, a new cookie is added, the session ID from another user is reused, or when the user location or User-Agent changes in the middle of a session.

== Binding the Session ID to Other User Properties ==

With the goal of detecting user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, it is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustily defend against session attacks, they significantly increase the web application detection capabilities. A skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots), by using the same outbound web proxy (very common in corporate environments), or by modifying his User-Agent to look exactly as the victim users does.

== Logging Sessions Life Cycle: Monitoring Creation, Usage, and Destruction of Session IDs ==

Web applications should increase their logging capabilities by including information regarding the full life cycle of sessions. In particular, it is recommended to record session related events, such as the creation, renewal, and destruction of session IDs, as well as details about its usage within login and logout operations, privilege level changes within the session, timeout expiration, invalid session activities (when detected), and critical business operations during the session.

The log details might include a timestamp, source IP address, web target resource requested (and involved in a session operation), HTTP headers (including the User-Agent and Referer), GET and POST parameters, error codes and messages, username (or user ID), plus the session ID (cookies, URL, GET, POST…). Sensitive data like the session ID should not be included in the logs in order to protect the session logs against session ID local or remote disclosure or unauthorized access. However, some kind of session-specific information must be logged into order to correlate log entries to specific sessions. It is recommended to log a salted-hash of the session ID instead of the session ID itself in order to allow for session-specific log correlation without exposing the session ID.

The session logs become one of the main web application intrusion detection data sources, and can also be used by intrusion protection systems to automatically terminate sessions and/or disable user accounts when (one or many) attacks are detected. If active protections are implemented, these defensive actions must be logged too.

== Simultaneous Session Logons ==

It is the web application design decision to determine if multiple simultaneous logons from the same user are allowed from the same or from different client IP addresses. If the web application does not want to allow simultaneous session logons, it must take effective actions after each new authentication event, implicitly terminating the previously available session, or asking the user (through the old, new or both sessions) about the session that must remain active.

It is recommended for web applications to add user capabilities that check the details of active sessions at any time, monitor and alert the user about concurrent logons, provide user features to remotely terminate sessions manually, and track account activity history (logbook) by recording multiple client details such as IP address, User-Agent, login date and time, idle time, etc.

<br>

= Session Management WAF Protections =

There are situations where the web application source code is not available or cannot be modified, or when the changes required to implement the multiple security recommendations and best practices detailed above imply a full redesign of the web application architecture, and therefore, cannot be easily implemented in the short term. In these scenarios, or to complement the web application defenses, and with the goal of keeping the web application as secure as possible, it is recommended to use external protections such as Web Application Firewalls (WAFs) that can mitigate the session management threats already described.

Web Application Firewalls offer detection and protection capabilities against session based attacks. On the one hand, it is trivial for WAFs to enforce the usage of security attributes on cookies, such as the “Secure” and “HttpOnly” flags, applying basic rewriting rules on the “Set-Cookie” header for all the web application responses that set a new cookie. On the other hand, more advanced capabilities can be implemented to allow the WAF to keep track of sessions, and the corresponding session IDs, and apply all kind of protections against session fixation (by renewing the session ID on the client-side when privilege changes are detected), enforcing sticky sessions (by verifying the relationship between the session ID and other client properties, like the IP address or User-Agent), or managing session expiration (by forcing both the client and the web application to finalize the session).

The open-source ModSecurity WAF, plus the OWASP Core Rule Set [6], provide capabilities to detect and apply security cookie attributes, countermeasures against session fixation attacks, and session tracking features to enforce sticky sessions.

<br>

= Related Articles =

[0] '''OWASP Cookies Database. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_Cookies_Database

[1] '''"HTTP State Management Mechanism". RFC 6265. IETF.''' http://tools.ietf.org/html/rfc6265

[2] '''Insufficient Session-ID Length. OWASP.''' https://www.owasp.org/index.php/Insufficient_Session-ID_Length

[3] '''Session Fixation. Mitja Kolšek. 2002.''' http://www.acrossecurity.com/papers/session_fixation.pdf

[4] '''"SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.'''

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf

https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf

[5] '''"Hypertext Transfer Protocol -- HTTP/1.1". RFC2616. IETF.''' http://tools.ietf.org/html/rfc2616

[6] '''OWASP ModSecurity Core Rule Set (CSR) Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

[7] '''OWASP AppSensor Project. OWASP.''' https://www.owasp.org/index.php/Category:OWASP_AppSensor_Project

<br> <br> {{Cheatsheet_Navigation}}

<br>

= Authors and Primary Editors =

Raul Siles - raul[at]taddong.com

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T20:08:31Z

Kcfredman: /* Incorrect responses examples */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least: 1 special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also give no indication to the status of an existing account.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"Login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms have a logical weakness. An attacker that undertakes a large numbers of authentication attempts on known account names can produce a result that locks out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T20:04:23Z

Kcfredman: /* Implement Account Lockout */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least: 1 special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also give no indication to the status of an existing account.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, the attacker has an opportunity to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms have a logical weakness. An attacker that undertakes a large numbers of authentication attempts on known account names can produce a result that locks out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T19:55:10Z

Kcfredman: /* Error Codes and URL's */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least: 1 special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also give no indication to the status of an existing account.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generic error page is shown to a user, the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, this provides the opportunity of the attacked to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms do have a logical weakness, however. It is possible for an attacker to attempt a large number of authentication attempts on known account names resulting in locking out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T19:53:41Z

Kcfredman: /* Authentication responses */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least: 1 special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also give no indication to the status of an existing account.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generc error page is shown to a user the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, this provides the opportunity of the attacked to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms do have a logical weakness, however. It is possible for an attacker to attempt a large number of authentication attempts on known account names resulting in locking out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T19:47:28Z

Kcfredman: /* Implement Proper Password Strength Controls */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

Longer passwords provide a greater combination of characters and consequently make it more difficult for an attacker to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least: 1 special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also no give any indication to the status of an account if it exists.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generc error page is shown to a user the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, this provides the opportunity of the attacked to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms do have a logical weakness, however. It is possible for an attacker to attempt a large number of authentication attempts on known account names resulting in locking out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Authentication Cheat Sheet

2011-07-28T19:44:22Z

Kcfredman: /* Introduction */

= Introduction =

'''Authentication''' is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

'''Session Management''' is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

For more information on Authentication, please see the OWASP [[Guide to Authentication]] page.

= Authentication General Guidelines =

== Implement Proper Password Strength Controls ==

A key concern when using passwords for authentication is password strength. A "strong" password policy makes it difficult or even improbable for one to guess the password either by using manual or automated means. The following characteristics define strong a strong password:

=== Password Length ===

The longer the password the more combinations possible combinations of characters exist and is hence more difficult to guess.

'''Important applications''': Minimum of 6 characters in length.

'''Critical applications''': Minimum of 8 characters in length. (consider multi-factor authentication)

'''Highly critical applications''': Consider multi-factor authentication

=== Password complexity ===

'''Example'''<br>Passwords should be checked for the following composition or a variance of such:

*at least: 1 uppercase character (A-Z)
*at least: 1 lowercase character (a-z)
*at least: 1 digit (0-9)
*at least one special character (!"£$%&...)
*a defined minimum length (e.g. 8 chars)
*a defined maximum length (as with all external input)
*no contiguous characters (e.g. 123abcd)
*not more than 2 identical characters in a row (1111)

== Implement Secure Password Recovery Mechanism ==

It is common for an application to have a mechanism that provides a means for a user to gain access to their account in the event they forget their password. Please see [https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet] for details on this feature.

== Utilize Multi-Factor Authentication ==

Multifactor factor authentication is using more than one of:

*Something you know (account details or passwords)
*Something you have (tokens or mobile phones)
*Something you are (biometrics)

to logon or process a transaction.

Authentication schemes such as One Time Passwords (OTP) implemented using a hardware token can also be key in fighting attacks such as CSRF and client-side malware.

== Authentication and Error Messages ==

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

'''An application should respond (both HTTP and HTML) in a generic manner which is not unique to the error condition or authentication failure.'''

==== Authentication responses ====

An application should respond with a generic error message regardless if the user ID or password was incorrect. It should also no give any indication to the status of an account if it exists.

==== Incorrect responses examples ====

*"Login for User foo: invalid password"
*"Login failed, invalid user ID"
*"Login failed; account disabled"
*"login failed; this user is not active"

==== Correct response example ====

*"Login failed; Invalid user ID or password"

The correct response does not indicate if the user ID or password is the incorrect parameter and hence inferring a valid user ID.

==== Error Codes and URL's ====

The application may return a different HTTP Error code depending on the authentication attempt response. It may respond with a 200 for a positive result and a 403 for a negative result. Even though a generc error page is shown to a user the HTTP response code may differ which can indicate a signature.

== Transmit Passwords Only Over TLS ==

See: "Transport Layer Protection Cheat Sheet"

[http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet]

"The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the "login landing page", must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user's credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user's authenticated session."

== Implement Account Lockout ==

If an attacker is able to guess passwords without the account becoming disabled due to failed authentication attempts, this provides the opportunity of the attacked to continue with a brute force attack until the account is compromised.

Automating brute-force/password guessing attacks on web applications is a trivial challenge. Password lockout mechanisms should be employed that lock out an account if more than a preset number of unsuccessful login attempts are made.

Password lockout mechanisms do have a logical weakness, however. It is possible for an attacker to attempt a large number of authentication attempts on known account names resulting in locking out entire blocks of application users accounts.

Given that the intent of a password lockout system is to protect from brute-force attacks, a sensible strategy is to lockout accounts for a number of hours. This significantly slows down attackers, while allowing the accounts to be open for legitimate users.

See also "Reverse Brute-force" [[Reverse Brute Force|Reverse_Brute_Force]]

= Session Management General Guidelines =

Session management is directly related to authentication. The '''Session Management General Guidelines''' previously available on this OWASP Authentication Cheat Sheet have been integrated into the new [https://www.owasp.org/index.php/Session_Management_Cheat_Sheet OWASP Session Management Cheat Sheet].

= Related Articles =

{{Cheatsheet_Navigation}}

= Authors and Primary Editors =

Eoin Keary eoinkeary[at]owasp.org

[[Category:How_To]] [[Category:Cheatsheets]] [[Category:OWASP_Document]] [[Category:OWASP_Top_Ten_Project]]

Summit 2011 Attendee/Attendee114

2011-02-06T22:56:35Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>OWASP 2011 Global Summit Attendee Tab</noinclude>
|-
| summit_attendee_name1 = Fred Donovan
| summit_attendee_email1 = fred.donovan@owasp.org
| summit_attendee_wiki_username1 = Fred.Donovan
|-
| summit_attendee_company = Attack Logic
|-
| Project Leadership (less than 6 months old) =
| Project Leadership (more than 6 months old) =
| Release Leadership (less than 6 months old) =
| Release Leadership (more than 6 months old) =
| Project Contribution (less than 6 months old) =
| Project Contribution (more than 6 months old) =
| Release Contribution (less than 6 months old) =
| Release Contribution (more than 6 months old) =
| Committee Membership =
| Chapter Co-Leadership = Indonesia
| Conference Co-Leadership =
| Projected Funding Cost =
|-
| summit_attendee_current_owasp_involvement_name1 =
| summit_attendee_current_owasp_involvement_url_1 =
| summit_attendee_current_owasp_involvement_name2 =
| summit_attendee_current_owasp_involvement_url_2 =
| summit_attendee_current_owasp_involvement_name3 =
| summit_attendee_current_owasp_involvement_url_3 =
| summit_attendee_current_owasp_involvement_name4 =
| summit_attendee_current_owasp_involvement_url_4 =
| summit_attendee_current_owasp_involvement_name5 =
| summit_attendee_current_owasp_involvement_url_5 =
|-
| summit_attendee_reason_for_summit_participation_name1 = XSS and the Frameworks
| summit_attendee_reason_for_summit_participation_url_1 = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session009
| notes_reason_for_participating_issues_to_be_discussed_1 =
| summit_attendee_reason_for_summit_participation_name2 = Protecting information Stored Client-Side
| summit_attendee_reason_for_summit_participation_url_2 = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session028
| notes_reason_for_participating_issues_to_be_discussed_2 =
| summit_attendee_reason_for_summit_participation_name3 = Development Guide
| summit_attendee_reason_for_summit_participation_url_3 = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session066
| notes_reason_for_participating_issues_to_be_discussed_3 =
| summit_attendee_reason_for_summit_participation_name4 =OWASP common vulnerability list
| summit_attendee_reason_for_summit_participation_url_4 = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session201
| notes_reason_for_participating_issues_to_be_discussed_4 =
| summit_attendee_reason_for_summit_participation_name5 =
| summit_attendee_reason_for_summit_participation_url_5 =
| notes_reason_for_participating_issues_to_be_discussed_5 =
|-
| summit_attendee_owasp_sponsor =
|-
| summit_attendee_summit_time_paid_by_name1 = self/employer
| summit_attendee_summit_time_paid_by_url_1 =
| summit_attendee_summit_time_paid_by_name2 =
| summit_attendee_summit_time_paid_by_url_2 =
|-
| summit_attendee_summit_expenses_paid_by_name1 = self/employer
| summit_attendee_summit_expenses_paid_by_url_1 =
| summit_attendee_summit_expenses_paid_by_name2 =
| summit_attendee_summit_expenses_paid_by_url_2 =
|-
| reason_for_sponsorship =
|-
| status = Confirmed, Funded
|-
| letter sent to sponsor =
|-
| notes for Kate =
|-
| attendee_name_mask =  Attendee114
| attendee_home_page =  Summit_2011_Attendee/Attendee114
}}

Summit 2011 Working Sessions/Session201

2011-02-04T16:56:39Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Vishal Garg
| summit_session_attendee_email1 = vishalgrg@gmail.com
| summit_session_attendee_username1 = Vishal_Garg
| summit_session_attendee_company1= AppSecure Labs
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Keith Turpin
| summit_session_attendee_email2 = keith.turpin@owasp.org
| summit_session_attendee_username2 = Keith_Turpin
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Fred Donovan
| summit_session_attendee_email3 = fred.donovan@owasp.org
| summit_session_attendee_username3 = Fred.Donovan
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5=
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6=
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7=
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8=
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9=
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10=
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11=
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12=
| summit_session_attendee_company12 =
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14=
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15=
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16=
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17=
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18=
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19=
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20=
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._individual_projects.jpg]]
| summit_ws_logo = [[Image:WS._individual_projects.jpg]]
| summit_session_name = OWASP Common vulnerability list
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session201
| mailing_list =

|-

| short_working_session_description =

There are many OWASP projects like OWASP Testing Guide, OWASP Code Review Guide, OWASP Developers Guide, etc which discuss on how to look for and remediate various vulnerabilities in a web application. For e.g., people using OWASP Testing Guide to test for vulnerabilities in their application can go through a list of vulnerabilities and test for it but there is no easy way for them to cross reference to dev guide to jump to a specific section and be able to access the relevant information quickly. These vulnerabilities are discussed as individual list in all the guides and there is no easy way to cross-reference all of them.

OWASP Common Vulnerability List will be a lightweight list, which will contain only the vulnerability ID, category, vulnerability name and a brief description. The main objective of this list is to provide a common platform for other guides and tools to provide a link to each other.

|-

| related_project_name1 = OWASP Common Vulnerability List
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Common_Vulnerability_List

| related_project_name2 = OWASP Testing Project
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Testing_Project

| related_project_name3 = OWASP Code Review Guide
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

| related_project_name4 = OWASP Building Guide
| related_project_url_4 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Build the first version of the OWASP Common vulnerability list

| summit_session_objective_name2 =

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources =

|-

| working_session_additional_details = The goals of OWASP common vulnerability list are:<br>
1. Serve as a common list to all other OWASP initiatives (Dev Guide, Testing Guide, CR Guide, etc) which has any reference to web application vulnerabilities (just like OWASP common numbering scheme).<br>
2. Can be referenced by various open source and commercial tools as the list of vulnerabilities being identified or for any other purpose.<br>
3. Provides a clear requirement for PCI and other compliance laws

|-

|summit_session_deliverable_name1 = Debating the vulnerability list and deliver the first version of the project.

|summit_session_deliverable_name2 =

|summit_session_deliverable_name3 =

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Matteo Meucci
| summit_session_leader_email1 = matteo.meucci@owasp.org
| summit_session_leader_username1 = Mmeucci

| summit_session_leader_name2 = Eoin Keary
| summit_session_leader_email2 = eoin.keary@owasp.org
| summit_session_leader_username2 = EoinKeary

| summit_session_leader_name3 = Anurag Agarwal
| summit_session_leader_email3 = Anurag.Agarwal@owasp.org
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =
|-

| meeting_notes =

|-
| session_name_mask =  Session201
| session_home_page =  Summit_2011_Working_Sessions/Session201
}}

Summit 2011 Working Sessions/Session009

2011-02-04T16:53:48Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Chris Eng
| summit_session_attendee_email1 = ceng@veracode.com
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Abraham Kang
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Tony UcedaVelez
| summit_session_attendee_email3 = tonyuv@owasp.org
| summit_session_attendee_username3 = Tony UcedaVelez
| summit_session_attendee_company3= VerSprite
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 = Fred Donovan
| summit_session_attendee_email4 = fred.donovan@owasp.org
| summit_session_attendee_username4 = Fred.Donovan
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._cross_site.jpg]]
| summit_ws_logo = [[Image:WS._cross_site.jpg]]
| summit_session_name = XSS and the Frameworks
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session009
| mailing_list =

|-

| short_working_session_description= Can we work with the common web frameworks to prevent XSS at the framework level? If the framework a developer uses handles the most common cases of XSS occurring, the overall prevalence of XSS will be reduced significantly.

|-

| related_project_name1 = ESAPI
| related_project_url_1 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Work on how OWASP can engage with the major web frameworks to move towards a "secure by default" stance

| summit_session_objective_name2 = Work on OWASP resources to provide patches/design approaches in conjunction with the frameworks

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = *'''Related resources:''' [[OWASP Working Session - Browser Security Letters]] <br> *'''Frameworks to invite:''' .NET, Struts, Spring, Ruby on Rails
|-

|summit_session_deliverable_name1 = OWASP statement/Press release to publicly ask the frameworks to build security in

|summit_session_deliverable_name2 = Engagement plan on how we'd work with (if at all) a framework to get ESAPI or similar functionality integrated

|summit_session_deliverable_name3 = White paper or standard for what we want the web frameworks to provide in terms of XSS defenses. Turning the XSS Prevention Cheat Sheet into a standard/metric for frameworks would be great.

|summit_session_deliverable_name4 = OWASP Standard defining an appraisal methodology for a framework’s XSS prevention capability based on the other deliverable.

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Justin Clarke
| summit_session_leader_email1 = justin.clarke@owasp.org
| summit_session_leader_username1 = Justin42

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-

| meeting_notes =

|-
| session_name_mask =  Session009
| session_home_page =  Summit_2011_Working_Sessions/Session009
}}

User:Fred.Donovan

2011-02-04T16:33:48Z

Kcfredman: Created page with '<h1>Fred Donovan, New York, USA</h1> <p class=MsoNormal>Fred is an application security researcher and the founder of Attack Logic, a U.S. based <span class=SpellE>AppSec</span>…'

<h1>Fred Donovan, New York, USA</h1>

<p class=MsoNormal>Fred is an application security researcher and the founder
of Attack Logic, a U.S. based <span class=SpellE>AppSec</span> consultancy. He
spent 3 years as a private researcher on campus at UNL’s Technology Park in the
field of InfoSec and for the past 11 years has provided executive level IT
services to public and private organizations. Application Security has been his
exclusive focus for the past seven with a general focus on information warfare
and the uses of counter intelligence for purposes of corporate defense. He is a
regular guest lecturer and speaker at Universities, Conferences, and
professional organizations. Mr. Donovan is alumni of the University of Missouri
-- Columbia (<span class=SpellE>Mizzou</span>) and the American Military
University (AMU).</p>

<p class=MsoNormal>OWASP Activities and Participation</p>

<p class=MsoNormal>ASDR: http://www.owasp.org/index.php/OWASP_ASDR_Project</p>

<p class=MsoNormal>Code Review Project: http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project</p>

<p class=MsoNormal>Conferences Collaborator/Presenter: </p>

OWASP EU Summit 2008<br>
OWASP_Ireland_AppSec_2009<br>
OWASP_IRELAND_2010<br>

<p class=MsoNormal>Email: <span class=SpellE>fred.donovan</span> ‘at’ <span
class=SpellE>owasp</span> ‘dot' org</p>

<p class=MsoNormal><span class=SpellE>LinkedIN</span>: http://www.linkedin.com/in/freddonovan

Summit 2011 Working Sessions/Session028

2011-02-04T03:54:18Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Elke Roth-Mandutz
| summit_session_attendee_email1 = elke.roth-mandutz@ohm-hochschule.de
| summit_session_attendee_username1 =
| summit_session_attendee_company1= GSO-University of Applied Sciences
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Jim Manico
| summit_session_attendee_email2 = jim@manico.net
| summit_session_attendee_username2 =
| summit_session_attendee_company2=Infrared Security
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Chris Schmidt
| summit_session_attendee_email3 = chris.schmidt@owasp.org
| summit_session_attendee_username3 =
| summit_session_attendee_company3=Aspect Security
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 = Justin Clarke
| summit_session_attendee_email4 = justin.clarke@owasp.org
| summit_session_attendee_username4 =
| summit_session_attendee_company4=Gotham Digital Science
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 = Neil Matatall
| summit_session_attendee_email5 = NEIL@OWASP.ORG
| summit_session_attendee_username5 = nmatatal
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 = Tony UcedaVelez
| summit_session_attendee_email6 = tonyuv@owasp.org
| summit_session_attendee_username6 = Tony UcedaVelez
| summit_session_attendee_company6= VerSprite
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 = Fred Donovan
| summit_session_attendee_email7 = fred.donovan@owasp.org
| summit_session_attendee_username7 =
| summit_session_attendee_company7= Attack Logic
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._secure_coding.jpg]]
| summit_ws_logo = [[Image:WS._secure_coding.jpg]]
| summit_session_name = Protecting Information Stored Client-Side
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session028
| mailing_list =
|-

| short_working_session_description=This section will focus on providing mechanisms for protecting important or sensitive data applications and services need to store client-side. Contexts this section aims to cover include:

* Personal or user-specific information
* Application-specific information (tokens, secrets)
* Key configuration data, other EIS/service information

For the purpose of the Portugal Summit, the session will focus on development within a "classic" N-tier Java application environment.

|-

| related_project_name1 =
| related_project_url_1 =

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Produce an informal threat model for each development scenario

| summit_session_objective_name2 = Impart clear and simple shared understanding of threats associated with each development scenario (and dispel common misunderstandings/idioms)

| summit_session_objective_name3 = Define solution that resists defined attacks

| summit_session_objective_name4 = Deliver solution implementation (snippets) to https://code.google.com/p/secure-coding-workshop/

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = Within the N-tier Java environment, the session will tackle the following development scenarios:

1) - Coat Check
* Removing information from a client
* Server-side storage, memento pattern
* Solving scale issues
2) - Purse
* Storing app-important information (like a purse)
* Resisting attack with augmented plain-text storage!
* Supporting back, reload, etc.
* Patterns & design for anti-tampering protocols
3) - Nuclear Briefcase
* Sensitive, opaque information
* Shuttling information between 3rd parties

Future summits will address the following two contexts as well:

* Phones (ios, Android)
* RIA

However, for the purpose of this coming session, we will only conduct planning and 'homework assignments' for these contexts in the next session (likely Minnesota).

The session will work each of the three above development scenarios within the n-tier environment using the following work stream:

* Define problem
* Conduct Cigital-style Threat Model (TM) exercise
* Co-design solution based on particular threats and attack vectors
* Implement solution within provided sample application-ette
* Discuss testing and verification strategies for solution.

Participants will be taken through the above work stream, an abbreviated 'build security in' process designed to focus on implementation (rather than documentation or assurance), to restructure applications to demonstrate security patterns, integrate existing security functionality, or build security controls as necessary.

|-

|summit_session_deliverable_name1 = (see objectives) Threat Models
|summit_session_deliverable_name2 = (see objectives) Code Snippets

|summit_session_deliverable_name3 = Plan and Extra-summit work-items for exercises in Phone and RIA contexts during next summit

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = John Steven
| summit_session_leader_email1 = John.Steven@owasp.org

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-
| meeting_notes =

|-
| session_name_mask =  Session028
| session_home_page =  Summit_2011_Working_Sessions/Session028
}}

Summit 2011 Working Sessions/Session009

2011-02-04T03:48:18Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Chris Eng
| summit_session_attendee_email1 = ceng@veracode.com
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Abraham Kang
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Tony UcedaVelez
| summit_session_attendee_email3 = tonyuv@owasp.org
| summit_session_attendee_username3 = Tony UcedaVelez
| summit_session_attendee_company3= VerSprite
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 = Fred Donovan
| summit_session_attendee_email4 = fred.donovan@owasp.org
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._cross_site.jpg]]
| summit_ws_logo = [[Image:WS._cross_site.jpg]]
| summit_session_name = XSS and the Frameworks
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session009
| mailing_list =

|-

| short_working_session_description= Can we work with the common web frameworks to prevent XSS at the framework level? If the framework a developer uses handles the most common cases of XSS occurring, the overall prevalence of XSS will be reduced significantly.

|-

| related_project_name1 = ESAPI
| related_project_url_1 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Work on how OWASP can engage with the major web frameworks to move towards a "secure by default" stance

| summit_session_objective_name2 = Work on OWASP resources to provide patches/design approaches in conjunction with the frameworks

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = *'''Related resources:''' [[OWASP Working Session - Browser Security Letters]] <br> *'''Frameworks to invite:''' .NET, Struts, Spring, Ruby on Rails
|-

|summit_session_deliverable_name1 = OWASP statement/Press release to publicly ask the frameworks to build security in

|summit_session_deliverable_name2 = Engagement plan on how we'd work with (if at all) a framework to get ESAPI or similar functionality integrated

|summit_session_deliverable_name3 = White paper or standard for what we want the web frameworks to provide in terms of XSS defenses. Turning the XSS Prevention Cheat Sheet into a standard/metric for frameworks would be great.

|summit_session_deliverable_name4 = OWASP Standard defining an appraisal methodology for a framework’s XSS prevention capability based on the other deliverable.

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Justin Clarke
| summit_session_leader_email1 = justin.clarke@owasp.org
| summit_session_leader_username1 = Justin42

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-

| meeting_notes =

|-
| session_name_mask =  Session009
| session_home_page =  Summit_2011_Working_Sessions/Session009
}}

Summit 2011 Working Sessions/Session009

2011-02-04T03:47:02Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Chris Eng
| summit_session_attendee_email1 = ceng@veracode.com
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Abraham Kang
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Tony UcedaVelez
| summit_session_attendee_email3 = tonyuv@owasp.org
| summit_session_attendee_username3 = Tony UcedaVelez
| summit_session_attendee_company3= VerSprite
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 = Fred Donovan
| summit_session_attendee_email5 = fred.donovan@owasp.org
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._cross_site.jpg]]
| summit_ws_logo = [[Image:WS._cross_site.jpg]]
| summit_session_name = XSS and the Frameworks
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session009
| mailing_list =

|-

| short_working_session_description= Can we work with the common web frameworks to prevent XSS at the framework level? If the framework a developer uses handles the most common cases of XSS occurring, the overall prevalence of XSS will be reduced significantly.

|-

| related_project_name1 = ESAPI
| related_project_url_1 = http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Work on how OWASP can engage with the major web frameworks to move towards a "secure by default" stance

| summit_session_objective_name2 = Work on OWASP resources to provide patches/design approaches in conjunction with the frameworks

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = *'''Related resources:''' [[OWASP Working Session - Browser Security Letters]] <br> *'''Frameworks to invite:''' .NET, Struts, Spring, Ruby on Rails
|-

|summit_session_deliverable_name1 = OWASP statement/Press release to publicly ask the frameworks to build security in

|summit_session_deliverable_name2 = Engagement plan on how we'd work with (if at all) a framework to get ESAPI or similar functionality integrated

|summit_session_deliverable_name3 = White paper or standard for what we want the web frameworks to provide in terms of XSS defenses. Turning the XSS Prevention Cheat Sheet into a standard/metric for frameworks would be great.

|summit_session_deliverable_name4 = OWASP Standard defining an appraisal methodology for a framework’s XSS prevention capability based on the other deliverable.

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Justin Clarke
| summit_session_leader_email1 = justin.clarke@owasp.org
| summit_session_leader_username1 = Justin42

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-

| meeting_notes =

|-
| session_name_mask =  Session009
| session_home_page =  Summit_2011_Working_Sessions/Session009
}}

Summit 2011 Working Sessions/Session201

2011-02-04T03:43:58Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Vishal Garg
| summit_session_attendee_email1 = vishalgrg@gmail.com
| summit_session_attendee_username1 = Vishal_Garg
| summit_session_attendee_company1= AppSecure Labs
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Keith Turpin
| summit_session_attendee_email2 = keith.turpin@owasp.org
| summit_session_attendee_username2 = Keith_Turpin
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Fred Donovan
| summit_session_attendee_email3 = fred.donovan@owasp.org
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5=
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6=
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7=
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8=
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9=
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10=
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11=
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12=
| summit_session_attendee_company12 =
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14=
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15=
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16=
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17=
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18=
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19=
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20=
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._individual_projects.jpg]]
| summit_ws_logo = [[Image:WS._individual_projects.jpg]]
| summit_session_name = OWASP Common vulnerability list
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session201
| mailing_list =

|-

| short_working_session_description =

There are many OWASP projects like OWASP Testing Guide, OWASP Code Review Guide, OWASP Developers Guide, etc which discuss on how to look for and remediate various vulnerabilities in a web application. For e.g., people using OWASP Testing Guide to test for vulnerabilities in their application can go through a list of vulnerabilities and test for it but there is no easy way for them to cross reference to dev guide to jump to a specific section and be able to access the relevant information quickly. These vulnerabilities are discussed as individual list in all the guides and there is no easy way to cross-reference all of them.

OWASP Common Vulnerability List will be a lightweight list, which will contain only the vulnerability ID, category, vulnerability name and a brief description. The main objective of this list is to provide a common platform for other guides and tools to provide a link to each other.

|-

| related_project_name1 = OWASP Common Vulnerability List
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Common_Vulnerability_List

| related_project_name2 = OWASP Testing Project
| related_project_url_2 = http://www.owasp.org/index.php/Category:OWASP_Testing_Project

| related_project_name3 = OWASP Code Review Guide
| related_project_url_3 = http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

| related_project_name4 = OWASP Building Guide
| related_project_url_4 = http://www.owasp.org/index.php/OWASP_Guide_Project

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Build the first version of the OWASP Common vulnerability list

| summit_session_objective_name2 =

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources =

|-

| working_session_additional_details = The goals of OWASP common vulnerability list are:<br>
1. Serve as a common list to all other OWASP initiatives (Dev Guide, Testing Guide, CR Guide, etc) which has any reference to web application vulnerabilities (just like OWASP common numbering scheme).<br>
2. Can be referenced by various open source and commercial tools as the list of vulnerabilities being identified or for any other purpose.<br>
3. Provides a clear requirement for PCI and other compliance laws

|-

|summit_session_deliverable_name1 = Debating the vulnerability list and deliver the first version of the project.

|summit_session_deliverable_name2 =

|summit_session_deliverable_name3 =

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Matteo Meucci
| summit_session_leader_email1 = matteo.meucci@owasp.org
| summit_session_leader_username1 = Mmeucci

| summit_session_leader_name2 = Eoin Keary
| summit_session_leader_email2 = eoin.keary@owasp.org
| summit_session_leader_username2 = EoinKeary

| summit_session_leader_name3 = Anurag Agarwal
| summit_session_leader_email3 = Anurag.Agarwal@owasp.org
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =
|-

| meeting_notes =

|-
| session_name_mask =  Session201
| session_home_page =  Summit_2011_Working_Sessions/Session201
}}

Summit 2011 Working Sessions/Session075

2011-02-04T03:40:31Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Fred Donovan
| summit_session_attendee_email1 = fred.donovan@owasp.org
| summit_session_attendee_username1 =
| summit_session_attendee_company1=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 =
| summit_session_attendee_email2 =
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 =
| summit_session_attendee_email3 =
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 =
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 =
| summit_session_attendee_email5 =
| summit_session_attendee_username5 =
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 =
| summit_session_attendee_email6 =
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._owasp.jpg]]
| summit_ws_logo = [[Image:WS._owasp.jpg]]
| summit_session_name = S is for Safety (as well as Security)
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session075
| mailing_list =

|-

| short_working_session_description=
[[File:Banner-securitysafety-2.png]]

This session has two aspects - safety critical systems, and safety in regards to protection of vulnerable groups (e.g. children).

* What can OWASP learn from software safety engineering?
* What can OWASP contribute to software safety engineering?
* How does OWASP's work tie in to wider concerns about internet safety?

Get your helmets (hard hats) on and come along to discuss whether we need a new OWASP project, a new OWASP guide or embed safety thinking throughout OWASP's work.

This session will be particularly relevant to those interested in process control, safety critical applications, critical national infrastructure and other applications that could have a direct impact on system & human safety.
|-

| related_project_name1 =
| related_project_url_1 =

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1= Create a whitepaper on ''application security for critical systems''

| summit_session_objective_name2 = Create a whitepaper on ''how application security protects people''

| summit_session_objective_name3 =

| summit_session_objective_name4 =

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details =

Safety is not only concerned with confidentiality, integrity and availability. A safety-critical system (or life-critical system) is one where failure or malfunction can lead to ([http://en.wikipedia.org/wiki/Life-critical_system Wikipedia]):
* death or serious injury to people, or
* loss or severe damage to equipment or
* environmental harm.
In languages other than English, the distinction between "safety" and "security" may be less clear. [http://www.dailywritingtips.com/safety-and-security/ Here] is a good description of their slightly different meanings in English.

With software being used in so many safety-critical systems, the impact of application security flaws can have critical impacts on humans, equipment and the environment. There have been great advances in safety system design, but control system security is less advanced ([http://www.controlglobal.com/articles/2010/SafetySecurity1004.html Byres & Cusimano]).

This session will discuss whether and how OWASP should contribute to the efforts in system safety.
|-

|summit_session_deliverable_name1 = A white paper describing how the safety ecosystem overlaps with the OWASP ecosystem and whether there should be more bridges built between them.

|summit_session_deliverable_name2 =

|summit_session_deliverable_name3 =

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Colin Watson
| summit_session_leader_email1 = colin.watson(at)owasp.org

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =

|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-

| meeting_notes =

|-
| session_name_mask =  Session075
| session_home_page =  Summit_2011_Working_Sessions/Session075
}}

Summit 2011 Working Sessions/Session066

2011-02-04T03:23:07Z

Kcfredman:

{{Template:<includeonly>{{{1}}}</includeonly><noinclude>Summit 2011 Working Sessions test tab</noinclude>
|-

| summit_session_attendee_name1 = Matthias Rohr
| summit_session_attendee_email1 = m.rohr@sec-consult.com
| summit_session_attendee_username1 =
| summit_session_attendee_company1= SEC Consult
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed1=

| summit_session_attendee_name2 = Eoin Keary
| summit_session_attendee_email2 = eoin.keary@owasp.org
| summit_session_attendee_username2 =
| summit_session_attendee_company2=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed2=

| summit_session_attendee_name3 = Steven van der Baan
| summit_session_attendee_email3 = steven.van.der.Baan@owasp.org
| summit_session_attendee_username3 =
| summit_session_attendee_company3=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed3=

| summit_session_attendee_name4 = Abraham Kang
| summit_session_attendee_email4 =
| summit_session_attendee_username4 =
| summit_session_attendee_company4=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed4=

| summit_session_attendee_name5 = Keith Turpin
| summit_session_attendee_email5 = keith.turpin@owasp.org
| summit_session_attendee_username5 = Keith_Turpin
| summit_session_attendee_company5=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed5=

| summit_session_attendee_name6 = Fred Donovan
| summit_session_attendee_email6 = fred.donovan@owasp.org
| summit_session_attendee_username6 =
| summit_session_attendee_company6=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed6=

| summit_session_attendee_name7 =
| summit_session_attendee_email7 =
| summit_session_attendee_username7 =
| summit_session_attendee_company7=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed7=

| summit_session_attendee_name8 =
| summit_session_attendee_email8 =
| summit_session_attendee_username8 =
| summit_session_attendee_company8=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed8=

| summit_session_attendee_name9 =
| summit_session_attendee_email9 =
| summit_session_attendee_username9 =
| summit_session_attendee_company9=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed9=

| summit_session_attendee_name10 =
| summit_session_attendee_email10 =
| summit_session_attendee_username10 =
| summit_session_attendee_company10=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed10=

| summit_session_attendee_name11 =
| summit_session_attendee_email11 =
| summit_session_attendee_username11 =
| summit_session_attendee_company11=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed11=

| summit_session_attendee_name12 =
| summit_session_attendee_email12 =
| summit_session_attendee_username12 =
| summit_session_attendee_company12=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed12=

| summit_session_attendee_name13 =
| summit_session_attendee_email13 =
| summit_session_attendee_username13 =
| summit_session_attendee_company13=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed13=

| summit_session_attendee_name14 =
| summit_session_attendee_email14 =
| summit_session_attendee_username14 =
| summit_session_attendee_company14=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed14=

| summit_session_attendee_name15 =
| summit_session_attendee_email15 =
| summit_session_attendee_username15 =
| summit_session_attendee_company15=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed15=

| summit_session_attendee_name16 =
| summit_session_attendee_email16 =
| summit_session_attendee_username16 =
| summit_session_attendee_company16=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed16=

| summit_session_attendee_name17 =
| summit_session_attendee_email17 =
| summit_session_attendee_username17 =
| summit_session_attendee_company17=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed17=

| summit_session_attendee_name18 =
| summit_session_attendee_email18 =
| summit_session_attendee_username18 =
| summit_session_attendee_company18=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed18=

| summit_session_attendee_name19 =
| summit_session_attendee_email19 =
| summit_session_attendee_username19 =
| summit_session_attendee_company19=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed19=

| summit_session_attendee_name20 =
| summit_session_attendee_email20 =
| summit_session_attendee_username20 =
| summit_session_attendee_company20=
| summit_session_attendee_notes,_reason_for_participating_and_issues_to_be discussed20=

|-
| summit_track_logo = [[Image:T._individual_projects.jpg]]
| summit_ws_logo = [[Image:WS._individual_projects.jpg]]
| summit_session_name = Development Guide
| summit_session_url = http://www.owasp.org/index.php/Summit_2011_Working_Sessions/Session066
| mailing_list =

|-

| short_working_session_description= If done from the earliest stages, secure applications cost about the same to develop as insecure applications, but are far more cost effective in the long run. The primary aim of the OWASP Development Guide is to help businesses, developers, designers and solution architects to build secure web applications from the outset. The next version of the guide is an extension from the existing version with further enhancements to make it more usable for all stake holders. The aim of the working session is to have a discussion on the shortcomings of the existing guide and to make it a basis for further enhancements, alignment of the guide to ASVS Standard and OWASP common numbering scheme, potential for alignment of all three OWASP guides (DG, CRG and TG) and the ways to improve the usefulness of the guide to all the stake holders.

|-

| related_project_name1 = Project Wiki Page
| related_project_url_1 = http://www.owasp.org/index.php/OWASP_Guide_Project#tab=Project_About

| related_project_name2 =
| related_project_url_2 =

| related_project_name3 =
| related_project_url_3 =

| related_project_name4 =
| related_project_url_4 =

| related_project_name5 =
| related_project_url_5 =

|-

| summit_session_objective_name1 = Discussion on major enhancements to the next version of the development guide

| summit_session_objective_name2 = Discussion on aligning the guide to ASVS standard and OWASP common numbering scheme

| summit_session_objective_name3 = Discussion on improving the usefulness of the guide to all stakeholders

| summit_session_objective_name4 = Collaboration with other OWASP guides - Top 10, ASDR, CRG and TG

| summit_session_objective_name5 =

|-

| working_session_date_and_time =

|-

| discussion_model = participants and attendees

|-

| operational_resources = Projector, whiteboards, markers, Internet connectivity, power

|-

| working_session_additional_details = The presence of participants on the Working Session [[Summit 2011 Working Sessions/Session085|'''Common structure and numbering for all guides''']] is advisable.

|-

|summit_session_deliverable_name1 = An updated outline for the development guide that is tied into the OWASP common numbering scheme

|summit_session_deliverable_name2 = A short white paper with ideas for revisions to the Development Guide for evaluation and discussion by the community at large.

|summit_session_deliverable_name3 = A committed project manager who can reach out to experts to get the document completed.

|summit_session_deliverable_name4 =

|summit_session_deliverable_name5 =

|summit_session_deliverable_name6 =

|summit_session_deliverable_name7 =

|summit_session_deliverable_name8 =

|-

| summit_session_leader_name1 = Vishal Garg
| summit_session_leader_email1 = vishalgrg@gmail.com

| summit_session_leader_name2 =
| summit_session_leader_email2 =
| summit_session_leader_username2 =

| summit_session_leader_name3 =
| summit_session_leader_email3 =
| summit_session_leader_username3 =
|-

| operational_leader_name1 =
| operational_leader_email1 =
| operational_leader_username1 =

|-

| meeting_notes =

|-
| session_name_mask =  Session066
| session_home_page =  Summit_2011_Working_Sessions/Session066
}}

Insecure Third Party Domain Access

2008-12-13T21:29:47Z

Kcfredman:

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

==Description==

Occurs when an application contains content provided from a 3rd party resource that is delivered without any type of content scrub.

'''Environments Affected'''

* Web servers
* Application servers
* Client Machines

==Risk Factors==
* Allowing hosted content from an untrusted server into a trusted application: affecting the server, server environment, and client machine.
* No confirmation of Third Party Controls.

==Examples==
This following example is a common method to insert third party hosted content into a trusted an application.
If the hosting site is vulnerable to attack, all content delivered to an application would be vulnerable malicious changes.
<pre>
<iframe src="http://site.com/share/Action.swf" width="720" height="420"
marginwidth="0" marginheight="0" scrolling="Auto" frameborder="0"></iframe>
</pre>

==Related [[Attacks]]==
[[Cross-Site_Request_Forgery]]

==Related [[Vulnerabilities]]==
TBD

==Related [[Controls]]==
TBD

==References==

[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Insecure Third Party Domain Access

2008-12-13T20:24:44Z

Kcfredman:

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

==Description==

Occurs when an application contains content provided from a 3rd party resource that is delivered without any type of content scrub.

'''Environments Affected'''

* Web servers
* Application servers
* Client Machines

==Risk Factors==
* Allowing hosted content from an untrusted server into a trusted application: affecting the server, server environment, and client machine.
* No confirmation of Third Party Controls.

==Examples==
This following type of development uses an iframe to insert a third party hosted flash into a trusted an application.
The site hosting the content could vulnerable to attack. As such, all content hosted on that site would be vulnerable to inheriting malicious content.
<pre>
<iframe src="http://site.com/share/Action.swf" width="720" height="420"
marginwidth="0" marginheight="0" scrolling="Auto" frameborder="0"></iframe>
</pre>

==Related [[Attacks]]==
[[Cross-Site_Request_Forgery]]

==Related [[Vulnerabilities]]==
TBD

==Related [[Controls]]==
TBD

==References==

[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Insecure Third Party Domain Access

2008-12-13T20:16:28Z

Kcfredman: New page: {{Template:Stub}} {{Template:Vulnerability}} __TOC__ ASDR Table of Contents Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' [[Category:FIXME|Thi...

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]

==Description==

Occurs when an application contains content provided from a 3rd party resource that is delivered without any type of content scrub.

'''Environments Affected'''

* Web servers
* Application servers
* Client Machines

==Risk Factors==
* Allowing hosted content from an untrusted server into a trusted application: affecting the server, server environment, and client machine.
* No confirmation of Third Party Controls.

==Examples==
This following type of development uses an iframe to insert a third party hosted flash into a trusted an application.
The site hosting the content could vulnerable to attack. As such, all content hosted on that site would be vulnerable to inheriting malicious content.
<pre>
<iframe src="http://site.com/share/Action.swf" width="720" height="420"
marginwidth="0" marginheight="0" scrolling="Auto" frameborder="0"></iframe>
</pre>

==Related [[Attacks]]==
[[Cross-Site_Request_Forgery]]

==Related [[Vulnerabilities]]==
TBD

==Related [[Controls]]==
TBD

==References==

[[Category:Vulnerability]]
[[Category:OWASP ASDR Project]]

Using a broken or risky cryptographic algorithm

2008-12-13T18:50:18Z

Kcfredman: /* Risk Factors */

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]

==Description==

Attempting to create non-standard and non-tested algorithms, using weak algorithms, or applying algorithms incorrectly will pose a high weakness to data that is meant to be secure.

'''Consequences'''

* Confidentiality: The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
* Integrity: The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
* Accountability: Any accountability to message content preserved by cryptography may be subject to attack.

'''Exposure period'''

* Design: The decision as to what cryptographic algorithm to utilize is generally made at design time.

'''Platform'''

* Languages: All
* Operating platforms: All

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium to High

Since the state of cryptography advances so rapidly, it is common to find algorithms, which previously were considered to be safe, currently considered unsafe. In some cases, things are discovered, or processing speed increases to the degree that the cryptographic algorithm provides little more benefit than the use of no cryptography at all.

==Risk Factors==

* Use of custom cryptographic algorithms.
* Use of weak and/or untested public algorithms.

==Examples==

In C/C++:

<pre>
EVP_des_ecb();
</pre>

In Java:

<pre>
Cipher des=Cipher.getInstance("DES...);
des.initEncrypt(key2);
</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Failure to encrypt data]]

==Related [[Controls]]==

* Design: Use a cryptographic algorithm that is currently considered to be strong by experts in the field.

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Cryptographic Vulnerability]]

Using a broken or risky cryptographic algorithm

2008-12-13T18:47:34Z

Kcfredman: /* Description */

{{Template:Vulnerability}}
{{Template:SecureSoftware}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]

==Description==

Attempting to create non-standard and non-tested algorithms, using weak algorithms, or applying algorithms incorrectly will pose a high weakness to data that is meant to be secure.

'''Consequences'''

* Confidentiality: The confidentiality of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
* Integrity: The integrity of sensitive data may be compromised by the use of a broken or risky cryptographic algorithm.
* Accountability: Any accountability to message content preserved by cryptography may be subject to attack.

'''Exposure period'''

* Design: The decision as to what cryptographic algorithm to utilize is generally made at design time.

'''Platform'''

* Languages: All
* Operating platforms: All

'''Required resources'''

Any

'''Severity'''

High

'''Likelihood of exploit'''

Medium to High

Since the state of cryptography advances so rapidly, it is common to find algorithms, which previously were considered to be safe, currently considered unsafe. In some cases, things are discovered, or processing speed increases to the degree that the cryptographic algorithm provides little more benefit than the use of no cryptography at all.

==Risk Factors==

TBD

==Examples==

In C/C++:

<pre>
EVP_des_ecb();
</pre>

In Java:

<pre>
Cipher des=Cipher.getInstance("DES...);
des.initEncrypt(key2);
</pre>

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Failure to encrypt data]]

==Related [[Controls]]==

* Design: Use a cryptographic algorithm that is currently considered to be strong by experts in the field.

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==

TBD

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]
[[Category:Cryptographic Vulnerability]]

Error Message Infoleaks

2008-12-13T17:03:32Z

Kcfredman: /* Examples */

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
[[Category:FIXME|Stub article, needs review]]

==Description==

Displaying unsolicited excess detail within Error messages that can be used to facilitate an attack.

==Risk Factors==

TBD

==Examples==

* [[Displaying debug or stack trace information]]
* [[Retaining commented-out code within the production source code]]

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Discrepancy Information Leaks]]

==Related [[Controls]]==

* [[:Category:Error Handling]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]

Error Message Infoleaks

2008-12-13T17:01:22Z

Kcfredman: /* Examples */

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
[[Category:FIXME|Stub article, needs review]]

==Description==

Displaying unsolicited excess detail within Error messages that can be used to facilitate an attack.

==Risk Factors==

TBD

==Examples==

• Displaying debug or stack trace information
• Retaining commented-out code within the production source code

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Discrepancy Information Leaks]]

==Related [[Controls]]==

* [[:Category:Error Handling]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]

Error Message Infoleaks

2008-12-13T16:57:13Z

Kcfredman: /* Description */

{{Template:Stub}}
{{Template:Vulnerability}}

__TOC__

[[ASDR Table of Contents]]

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

[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
[[Category:FIXME|Stub article, needs review]]

==Description==

Displaying unsolicited excess detail within Error messages that can be used to facilitate an attack.

==Risk Factors==

TBD

==Examples==

TBD

==Related [[Attacks]]==

* [[Attack 1]]
* [[Attack 2]]

==Related [[Vulnerabilities]]==

* [[Discrepancy Information Leaks]]

==Related [[Controls]]==

* [[:Category:Error Handling]]

==Related [[Technical Impacts]]==

* [[Technical Impact 1]]
* [[Technical Impact 2]]

==References==
TBD

[[Category:FIXME|add links

In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>

Availability Vulnerability

Authorization Vulnerability

Authentication Vulnerability

Concurrency Vulnerability

Configuration Vulnerability

Cryptographic Vulnerability

Encoding Vulnerability

Error Handling Vulnerability

Input Validation Vulnerability

Logging and Auditing Vulnerability

Session Management Vulnerability]]

__NOTOC__

[[Category:OWASP ASDR Project]]
[[Category:Vulnerability]]

Working Session Winter of Code 2009

2008-11-01T22:24:25Z

Kcfredman: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">'''OWASP Winter of Code 2009'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|Aims to define the next OWASP Season of Code frame.
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
*[[:OWASP Summer of Code 2008|OWASP Summer of Code 2008]],
*[[:OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]],
*[[:OWASP Autumn Of Code 2006|OWASP Autumn Of Code 2006]].
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:dinis.cruz(at)owasp.org '''Dinis Cruz'''], [mailto:seba(at)owasp.org '''Sebastien Deleersnyder''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:paulo.coimbra(at)owasp.org '''Paulo Coimbra''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-winter-of-code-2009 '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">
* Define the operation model for the next OWASP Season of Code (the Winter of Code 08),
* Identify which areas should receive priority selection,
* Create 'virtual teams' from the attendees and allocate them to key projects,
* Discuss sponsoring models.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue'''<br>[[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time'''<br>November 4 & 7, 2008 <br>Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model'''<br>"Everybody is a Participant"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|Initiative
| style="width:46%; background:#C2C2C2" align="center"|OWASP Winter of Code 08 plan.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|Decision
| style="width:46%; background:#C2C2C2" align="center"|Set of projects for immediate approval (assuming the proposal is ready).
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"| Eduardo Vianna de Camargo Neves
| style="width:15%; background:#cccccc" align="center"| Conviso IT Security
| style="width:63%; background:#cccccc" align="center"| Understand how we can help the initiative and participate to continue the Positive Security project.
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|Leonardo Cavallari Militelli
| style="width:15%; background:#cccccc" align="center"|E-VAL Tecnologia
| style="width:63%; background:#cccccc" align="center"|Share feelings from other 2 season of code, discuss improvements for WoC and continue ASDR development.
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Matt Tesauro
| style="width:15%; background:#cccccc" align="center"|OWASP Live CD 2008 Project Lead
| style="width:63%; background:#cccccc" align="center"|Discuss what worked and didn't work with the SoC.<br> Give some input on how to spread the word about OWASP's XoC's
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"| Matteo Meucci
| style="width:15%; background:#cccccc" align="center"| Minded Security, OWASP Testing Guide
| style="width:63%; background:#cccccc" align="center"| Discuss new ideas about projects. Should OWASP says which projects develop?
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"| Carlo Pelliccioni
| style="width:15%; background:#cccccc" align="center"| Symantec, OWASP Backend Security Project
| style="width:63%; background:#cccccc" align="center"| Discuss about the next OWASP sponsorship to share new ideas.
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|Christian Martorella
| style="width:15%; background:#cccccc" align="center"|Edge-Security, WebSlayer Project
| style="width:63%; background:#cccccc" align="center"|Interested in the topic
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|Eoin Keary
| style="width:15%; background:#cccccc" align="center"|Code review guide lead
| style="width:63%; background:#cccccc" align="center"|What next for the sponsored prjoects?
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|Arturo 'Buanzo' Busleiman
| style="width:15%; background:#cccccc" align="center"|Independent
| style="width:63%; background:#cccccc" align="center"|Project Leader in 07 and 08, past experience.
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|Corsaire
| style="width:63%; background:#cccccc" align="center"|WebScarab lead, reviewer and past participant
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|Frederick Donovan
| style="width:15%; background:#cccccc" align="center"|Donovan Networks
| style="width:63%; background:#cccccc" align="center"|Participant
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP Working Session Enterprise Security API Project

2008-11-01T22:19:36Z

Kcfredman: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">'''OWASP Enterprise Security API Project '''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|In this working session we will consider all aspects of the Enterprise Security API project. The goal of the project is to simplify security for developers to make secure code more likely. To achieve this goal we define clean intuitive APIs for standard security functionality. Ideally, these APIs will cover common security controls across web applications, web services, and even rich client applications. This working session will review the state of the project, discuss technical issues, discuss "marketing" of the project, prioritize project work items, and browbeat attendees into joining the project and making the world a safer place.
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:jeff.williams(at)owasp.org '''Jeff Williams''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:arshan.dabirsiaghi(at)aspectsecurity.com '''Arshan Dabirsiaghi''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-esapi '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">
Introduce everyone to the idea and cost-benefits of an ESAPI.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue'''<br>[[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time'''<br>November 5, 2008 <br>1:00 PM
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model'''<br>"Participants + Attendees"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|A volunteer to lead the 'marketing' campaign for ESAPI.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Prioritized list of marketing ideas for the ESAPI concept.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Prioritized list of ideas for improving the API.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Matt Tesauro
| style="width:15%; background:#cccccc" align="center"|OWASP Live CD Project Lead
| style="width:63%; background:#cccccc" align="center"|Curious about how various "ports" should be handled (lang != Java) <br> Run them as separate projects or sub-projects. How are they synchronized, if at all? What state are they in? How bad will the browbeating be?
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|Andrea Cogliati
| style="width:15%; background:#cccccc" align="center"|OWASP Rochester, NY
| style="width:63%; background:#cccccc" align="center"|Interested in porting to other platforms (Ruby&Rails) and in integration issues with existing framework (Struts, Spring, ...)
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Alex Smolen
| style="width:15%; background:#cccccc" align="center"|Foundstone
| style="width:63%; background:#cccccc" align="center"|Author and Project Leader for .NET ESAPI
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"|Kuai Hinojosa
| style="width:15%; background:#cccccc" align="center"|New York University
| style="width:63%; background:#cccccc" align="center"|Interesting in ESAPI for PHP and How to best implement the ESAPI.
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|Fred Donovan
| style="width:15%; background:#cccccc" align="center"|Donovan Networks
| style="width:63%; background:#cccccc" align="center"|Interested in the structure and integrating this as a solution for Fortune 200 web development processes
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP Working Session Enterprise Security API Project

2008-11-01T22:16:46Z

Kcfredman: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">'''OWASP Enterprise Security API Project '''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|In this working session we will consider all aspects of the Enterprise Security API project. The goal of the project is to simplify security for developers to make secure code more likely. To achieve this goal we define clean intuitive APIs for standard security functionality. Ideally, these APIs will cover common security controls across web applications, web services, and even rich client applications. This working session will review the state of the project, discuss technical issues, discuss "marketing" of the project, prioritize project work items, and browbeat attendees into joining the project and making the world a safer place.
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:jeff.williams(at)owasp.org '''Jeff Williams''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:arshan.dabirsiaghi(at)aspectsecurity.com '''Arshan Dabirsiaghi''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-esapi '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">
Introduce everyone to the idea and cost-benefits of an ESAPI.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue'''<br>[[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time'''<br>November 5, 2008 <br>1:00 PM
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model'''<br>"Participants + Attendees"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Please add here, ASAP, any needed relevant resources, e.g. data-show, boards, laptops, etc.
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|A volunteer to lead the 'marketing' campaign for ESAPI.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Prioritized list of marketing ideas for the ESAPI concept.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Prioritized list of ideas for improving the API.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Matt Tesauro
| style="width:15%; background:#cccccc" align="center"|OWASP Live CD Project Lead
| style="width:63%; background:#cccccc" align="center"|Curious about how various "ports" should be handled (lang != Java) <br> Run them as separate projects or sub-projects. How are they synchronized, if at all? What state are they in? How bad will the browbeating be?
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|Andrea Cogliati
| style="width:15%; background:#cccccc" align="center"|OWASP Rochester, NY
| style="width:63%; background:#cccccc" align="center"|Interested in porting to other platforms (Ruby&Rails) and in integration issues with existing framework (Struts, Spring, ...)
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Alex Smolen
| style="width:15%; background:#cccccc" align="center"|Foundstone
| style="width:63%; background:#cccccc" align="center"|Author and Project Leader for .NET ESAPI
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"|Kuai Hinojosa
| style="width:15%; background:#cccccc" align="center"|New York University
| style="width:63%; background:#cccccc" align="center"|Interesting in ESAPI for PHP and How to best implement the ESAPI.
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|Fred Donovan
| style="width:15%; background:#cccccc" align="center"|Donovan Networks
| style="width:63%; background:#cccccc" align="center"|Interested in the structure and integrating this with Fortune 200 companies
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|
| style="width:15%; background:#cccccc" align="center"|
| style="width:63%; background:#cccccc" align="center"|
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP Working Session - Code Review Guide

2008-11-01T22:02:20Z

Kcfredman: /* Working Session Participants */

{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#b3b3b3; color:white"|<font color="black">'''Working Sessions Operational Rules''' - [[:Working Sessions Methodology|'''Please see here the general frame of rules''']].
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION IDENTIFICATION'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Work Session Name'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">'''Code Review Guide'''
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Short Work Session Description'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|TBD
|-
| style="width:15%; background:#7B8ABD" align="center"| '''Related Projects (if any)'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|
[[:Category:OWASP Code Review Project|OWASP Code Review Project]]
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Email Contacts & Roles'''
| style="width:25%; background:#cccccc" align="center"|'''Chair'''<br>[mailto:eoin.keary(at)owasp.org '''Eoin Keary''']
| style="width:25%; background:#cccccc" align="center"|'''Secretary'''<br>[mailto:name(at)name '''TBD''']
| style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>[https://lists.owasp.org/mailman/listinfo/owasp-codereview '''Subscription Page''']
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION SPECIFICS'''
|-
| style="width:15%; background:#7B8ABD" align="center"|'''Objectives'''
| colspan="6" style="width:85%; background:#cccccc" align="left"|<font color="black">
* Discuss next version of code review guide.
* Discuss industry requirements for code review.
* Discuss academic versus practical ramifications of guide.
* Brainstorm: Ideas for integration with other projects and tools.
|-
| style="width:25%; background:#7B8ABD" align="center"|'''Venue/Date&Time/Model'''
| style="width:25%; background:#cccccc" align="center"|'''Venue'''<br>[[:OWASP EU Summit 2008|OWASP EU Summit Portugal 2008]]
| style="width:25%; background:#cccccc" align="center"|'''Date&Time'''<br>November 5 & 6, 2008 <br>Time TBD
| style="width:25%; background:#cccccc" align="center"|'''Discussion Model'''<br>"Everybody is a Participant"
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}

{|style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION OPERATIONAL RESOURCES'''
|-
| style="width:100%; background:#cccccc" align="center"|Whteboard and Pens, Projector, Coffee :)
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:white; color:white"|<font color="black">
|}
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION ADDITIONAL DETAILS'''
|-
| style="width:100%; background:#cccccc" align="left"|
Please add here, any additional notes, links, ideas, guidelines, etc... The objective is to help the working sessions participants and attendees to prepare their participation/contribution.
|}
{| style="width:100%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white"|'''WORKING SESSION OUTCOMES'''
|-
| style="width:7%; background:#6C82B5" align="center"|Statements, Initiatives or Decisions
| style="width:46%; background:#b3b3b3" align="center"|'''Proposed by Working Group'''
| style="width:47%; background:#b3b3b3" align="center"|'''Approved by OWASP Board'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Develop a roadmap for the code review guide: Technologies, approaches.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:46%; background:#C2C2C2" align="center"|Fill in here.
| style="width:47%; background:#C2C2C2" align="center"|After the Board Meeting - fill in here.
|}
== Working Session Participants ==
(Add you name by editing this table. On your the right, just above the this frame, you have the option to edit)
{| style="width:100%" border="0" align="center"
! colspan="7" align="center" style="background:#4058A0; color:white"|<font color="white">'''WORKING SESSION PARTICIPANTS'''
|-
| style="width:7%; background:#7B8ABD" align="center"|
| style="width:15%; background:#cccccc" align="center"|'''Name'''
| style="width:15%; background:#cccccc" align="center"|'''Company'''
| style="width:63%; background:#cccccc" align="center"|'''Notes & reason for participating, issues to be discussed/addressed'''
|-
| style="width:7%; background:#7B8ABD" align="center"|1
| style="width:15%; background:#cccccc" align="center"|Paolo Perego (aka thesp0nge)
| style="width:15%; background:#cccccc" align="center"|Spike Reply
| style="width:63%; background:#cccccc" align="center"|Owasp Orizon - Project Leader
|-
| style="width:7%; background:#7B8ABD" align="center"|2
| style="width:15%; background:#cccccc" align="center"|David Rook
| style="width:15%; background:#cccccc" align="center"|Realex Payments
| style="width:63%; background:#cccccc" align="center"|Contributor to Code Review Guide
|-
| style="width:7%; background:#7B8ABD" align="center"|3
| style="width:15%; background:#cccccc" align="center"|Giorgio Fedon
| style="width:15%; background:#cccccc" align="center"|Minded Security
| style="width:63%; background:#cccccc" align="center"|Very interested in the topic
|-
| style="width:7%; background:#7B8ABD" align="center"|4
| style="width:15%; background:#cccccc" align="center"| Matteo Meucci
| style="width:15%; background:#cccccc" align="center"| Minded Security
| style="width:63%; background:#cccccc" align="center"| Interested in integrating OWASP big 4: Dev, Code Review, Testing, ADSR
|-
| style="width:7%; background:#7B8ABD" align="center"|5
| style="width:15%; background:#cccccc" align="center"|Kuai Hinojosa
| style="width:15%; background:#cccccc" align="center"|OWASP (MSP) Chapter Leader
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|6
| style="width:15%; background:#cccccc" align="center"|James Walden
| style="width:15%; background:#cccccc" align="center"|NKU
| style="width:63%; background:#cccccc" align="center"|OWASP Source Code Analysis Project
|-
| style="width:7%; background:#7B8ABD" align="center"|7
| style="width:15%; background:#cccccc" align="center"|Wagner Elias
| style="width:15%; background:#cccccc" align="center"|Conviso IT Security
| style="width:63%; background:#cccccc" align="center"|
|-
| style="width:7%; background:#7B8ABD" align="center"|8
| style="width:15%; background:#cccccc" align="center"|Arturo 'Buanzo' Busleiman
| style="width:15%; background:#cccccc" align="center"|Independent
| style="width:63%; background:#cccccc" align="center"|Eoin looks passionate about the subject. I want to be near! :)
|-
| style="width:7%; background:#7B8ABD" align="center"|9
| style="width:15%; background:#cccccc" align="center"|Rogan Dawes
| style="width:15%; background:#cccccc" align="center"|Corsaire
| style="width:63%; background:#cccccc" align="center"|Have experience, would like to contribute where possible
|-
| style="width:7%; background:#7B8ABD" align="center"|10
| style="width:15%; background:#cccccc" align="center"|Frederick Donovan
| style="width:15%; background:#cccccc" align="center"|Donovan Networks
| style="width:63%; background:#cccccc" align="center"|Would like to see language specific guidelines
|}
If needed add here more lines.

[[Category:OWASP_Working_Session]]

OWASP EU Summit 2008

2008-07-10T22:12:11Z

Kcfredman:

(WORK IN PROGRESS /UNDER DISCUSSION)
== UPDATES ==
*[[OWASP EU Summit 2008 - updates|'''OWASP EU Summit 2008 - updates''']]

== What: OWASP Summit, a conference about OWASP and for OWASP's community ==
=== When: 4 to 7 Nov 2008 (4 & 5: Meetings and Training, 6 & 7: Conference) ===
=== Where: Portugal ===
Faro or Lisbon
=== Organization===
Paulo Coimbra and Dinis Cruz
== Agenda ==
Theme: Present OWASP's projects, community and activities ..... '....Connecting the dots.... "

'''Day 1 & 2'''
*Training sessions (similar to what happens at the moment at the other OWASP conferences)
*OWASP Working Group sessions (1/2 day each) on:
** OWASP Governance, "What is OWASP's position on ...." & Action Plan for 2009
** ESAPI
** Browser Security
** OWASP Top 10 2009

'''Day 3 & 4 Agenda:'''
* Presentations from AoC, SpoC and SoC Participants
* Presentations from 'Release' Quality OWASP projects (not included in the list above) or Key OWASP projects (like ESAPI)
* Presentations about OWASP : How it works, Financial reports, OotM (OWASP on the Move), new project management guidelines, local chapter finances, OWASP governance
* Presentation from Chapter leaders on the activities developed on their project
* Discussion on next steps for OWASP and focus of next OWASP financial investment plans

Other ideas:

* vote on 6th OWASP board member (Candidates to Apply)

== other details==

'''Projected Attendees:450 '''
* 200 with some (or all) expenses covered by OWASP
** 33 SoC participants
** 70 SoC reviewers
** 10 SoC Collaborators
** 15 AoC & SpoC participants
** 15 Chapter Leaders
** 8 OWASP Board & Employees
** 49 OWASP non-individual members (2x per 9k Corporate? 1x for the others?)

=== Financial details ===
'''Expenses'''
* Accommodation & meals: 80,000 USD = 400 USD per person (200x) for 3 nights accommodation and 5 meals (3 dinners and 2 lunches)
* Flights & Trains : 70,000 USD

'''Revenue sources'''
* Tickets (for the 250 non 'OWASP invited' attendees)
* Training Sessions
* Conference sponsors

== Participants ==
=== OWASP Board members & employees ===
* Jeff Williams
* Dave Wichers
* Dinis Cruz
* Tom Brennan
* Sebastien Deleersnyder
* Paulo Coimbra
* Kate Hartmann (to be confirmed)
* Alison McNamee (to be confirmed)
* Larry Casey (to be confirmed)

=== Summer of Code 08 Participants & Reviewers ===
* (please add your name in the following format)
* OWASP Classic ASP Security Project
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Internationalization Guidelines
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Spanish Project Reviewer Esteban Ribicic
**Reviewer Esteban Ribicic Argentina -living in Croatia/Wien-
**Project Lead - Juan Carlos Calderon - Mexico
* OWASP Ruby on Rails Security Project Leader Heiko Webers from Germany
* OWASP Code Review Guide Lead - Eoin Keary - Ireland
* OWASP Enigform and mod_Openpgp - Arturo Alberto Busleiman (a.k.a Buanzo) - Argentina
* OWASP AppSensor - Michael Coates - United States
* OWASP ASDR - Leonardo Cavallari Militelli - Brazil
**Reviewer - Frederick Donovan - United States
*OWASP Corporate Application security guide- Parvathy Iyer- USA
* OWASP Positive Security - Eduardo Vianna de Camargo Neves - Brazil
* OWASP Backend Security Project - Carlo Pelliccioni - Italy
* OWASP Source Code Review OWASP Projects - Marco M. Morana (2nd reviewer) - United States
* OWASP Access Control Rules Tester Project
**Project leader - Andrew Petukhov - Russia, Moscow
* OWASP Live CD 2008
** Project Leader - Matt Tesauro - Austin, USA
* OWASP OpenSign Server Project
** Reviewer Pierre Parrend - France
** SoC's Reviewer Kevin Fuller - ?

=== Spring of Code 07 Participants (Completed Projects) ===
* Refresh Attacks list - Przemyslaw Skowron - Poland

* (please add your name)
* {Project} {Name} {Origin Country}

=== Autumn of Code 06 Participants ===
* (please add your name)
* {Project} {Name} {Origin Country}

* WebScarab-NG, Rogan Dawes, South Africa
* OWASP Pantera, Simon Roses Femerling, Spain

=== Active Chapter Leaders ===
* (please add your name in the following format)
* {Chapter} {Role} {Name} {Origin Country}
* Helsinki chapter leader - Antti Laulajainen, Finland
* NY/NJ Metro Board Member - Steve Antoniewicz, USA
* Twin-Cities chapter leader - Kuai Hinojosa, MN, USA
* Hawaii chapter leader/founder - Jim Manico, Anahola, Island of Kauai, Hawaii, USA

=== Active Project Leaders (not currently participating on SoC 08)===
* (please add your name in the following format)
* {Project} {Role} {Name} {Origin Country}
.NET ESAPI - Project Leader - Alex Smolen - USA

=== Significant Past OWASP contributor (that is not already covered by one of the above categories) ===
* (please add your name in the following format)
* {Project/Chapter} {Role} {Name} {Origin Country}

=== Logistic and Support team ===
* Summit Graphic Design + Summit organization + on-site logistics support, Sarah Cruz, UK (London)