add checklist for access controls and data protection

draft/04-foundations/04-crypto-principles.md

@@ -238,7 +238,7 @@ These protocols prevent adversaries from learning the key or forcing their own k
 
 * OWASP Cheat Sheet series
   * [Authentication Cheat Sheet][ancs]
-  * [Authorization_Cheat_Sheet][azcs]
+  * [Authorization_Cheat_Sheet][csaz]
   * [Cryptographic Storage Cheat Sheet][cscs]
   * [Key Management Cheat Sheet][kmcs]
   * [SAML Security Cheat Sheet][sscs]
@@ -251,7 +251,7 @@ The OWASP Developer Guide is a community effort; if there is something that need
 then [submit an issue][issue0404] or a [pull request][pr] .
 
 [ancs]: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
-[azcs]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
+[csaz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
 [cheat]: https://owasp.org/www-project-cheat-sheets/
 [cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
 [issue0404]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/04-crypto-principles

draft/20-proactive-control-checklist/02-define-security-requirements.md

@@ -23,4 +23,84 @@ and submit your content for review.
 
 [contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
 
+## System configuration
+
+- [ ]   Ensure servers, frameworks and system components are running the latest approved version
+
+- [ ]   Ensure servers, frameworks and system components have all patches issued for the version in use
+
+- [ ]   Turn off directory listings
+
+- [ ]   Restrict the web server, process and service accounts to the least privileges possible
+
+- [ ]   When exceptions occur, fail securely
+
+- [ ]   Remove all unnecessary functionality and files
+
+- [ ]   Remove test code or any functionality not intended for production, prior to deployment
+
+- [ ]   Prevent disclosure of your directory structure in the robots.txt
+    file by placing directories not intended for public indexing into
+    an isolated parent directory
+
+- [ ]   Define which HTTP methods, Get or Post, the application will support
+    and whether it will be handled differently in different pages in
+    the application
+
+- [ ]   Disable unnecessary HTTP methods
+
+- [ ]   If the web server handles different versions of HTTP ensure that they
+    are configured in a similar manner and ensure any differences are understood
+
+- [ ]   Remove unnecessary information from HTTP response headers related to
+    the OS, web-server version and application frameworks
+
+- [ ]   The security configuration store for the application should be able
+    to be output in human readable form to support auditing
+
+- [ ]   Implement an asset management system and register system components
+    and software in it
+
+- [ ]   Isolate development environments from the production network and
+    provide access only to authorized development and test groups
+
+- [ ]   Implement a software change control system to manage and record
+    changes to the code both in development and production
+
+## File management
+
+- [ ]   Do not pass user supplied data directly to any dynamic include function
+
+- [ ]   Require authentication before allowing a file to be uploaded
+
+- [ ]   Limit the type of files that can be uploaded to only those types
+    that are needed for business purposes
+
+- [ ]   Validate uploaded files are the expected type by checking file
+    headers rather than by file extension
+
+- [ ]   Do not save files in the same web context as the application
+
+- [ ]   Prevent or restrict the uploading of any file that may be
+    interpreted by the web server.
+
+- [ ]   Turn off execution privileges on file upload directories
+
+- [ ]   Implement safe uploading in UNIX by mounting the targeted file
+    directory as a logical drive using the associated path or the
+    chrooted environment
+
+- [ ]   When referencing existing files, use an allow-list of allowed file names and types
+
+- [ ]   Do not pass user supplied data into a dynamic redirect
+
+- [ ]   Do not pass directory or file paths, use index values mapped to pre-defined list of paths
+
+- [ ]   Never send the absolute file path to the client
+
+- [ ]   Ensure application files and resources are read-only
+
+- [ ]   Scan user uploaded files for viruses and malware
+
+
 \newpage

draft/20-proactive-control-checklist/03-frameworks-libraries.md

@@ -23,4 +23,62 @@ and submit your content for review.
 
 [contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
 
+## Memory management
+
+- [ ]   Utilize input and output controls for untrusted data
+
+- [ ]   Check that the buffer is as large as specified
+
+- [ ]   When using functions that accept a number of bytes ensure that NULL terminatation is handled correctly
+
+- [ ]   Check buffer boundaries if calling the function in a loop and protect against overflow
+
+- [ ]   Truncate all input strings to a reasonable length before passing them to other functions
+
+- [ ]   Specifically close resources, don't rely on garbage collection
+
+- [ ]   Use non-executable stacks when available
+
+- [ ]   Avoid the use of known vulnerable functions
+
+- [ ]   Properly free allocated memory upon the completion of functions and at all exit points
+
+- [ ]   Overwrite any sensitive information stored in allocated memory at all exit points from the function
+
+## General coding practices
+
+- [ ]   Use tested and approved managed code rather than creating new unmanaged code for common tasks
+
+- [ ]   Utilize task specific built-in APIs to conduct operating system
+    tasks. Do not allow the application to issue commands directly to
+    the Operating System, especially through the use of application
+    initiated command shells
+
+- [ ]   Use checksums or hashes to verify the integrity of interpreted code,
+    libraries, executables, and configuration files
+
+- [ ]   Utilize locking to prevent multiple simultaneous requests or use a
+    synchronization mechanism to prevent race conditions
+
+- [ ]   Protect shared variables and resources from inappropriate concurrent
+    access
+
+- [ ]   Explicitly initialize all your variables and other data stores,
+    either during declaration or just before the first usage
+
+- [ ]   In cases where the application must run with elevated privileges,
+    raise privileges as late as possible, and drop them as soon as
+    possible
+
+- [ ]   Avoid calculation errors by understanding your programming language\'s underlying representation
+
+- [ ]   Do not pass user supplied data to any dynamic execution function
+
+- [ ]   Restrict users from generating new code or altering existing code
+
+- [ ]   Review all secondary applications, third party code and libraries to
+    determine business necessity and validate safe functionality
+
+- [ ]   Implement safe updating using encrypted channels
+
 \newpage

draft/20-proactive-control-checklist/04-secure-database-access.md

@@ -23,4 +23,39 @@ and submit your content for review.
 
 [contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
 
+## Database security
+
+- [ ]   Use strongly typed parameterized queries
+
+- [ ]   Utilize input validation and output encoding and be sure to address
+    meta characters. If these fail, do not run the database command
+
+- [ ]   Ensure that variables are strongly typed
+
+- [ ]   The application should use the lowest possible level of privilege
+    when accessing the database
+
+- [ ]   Use secure credentials for database access
+
+- [ ]   Connection strings should not be hard coded within the application.
+    Connection strings should be stored in a separate configuration
+    file on a trusted system and they should be encrypted.
+
+- [ ]   Use stored procedures to abstract data access and allow for the
+    removal of permissions to the base tables in the database
+
+- [ ]   Close the connection as soon as possible
+
+- [ ]   Remove or change all default database administrative passwords
+
+- [ ]   Turn off all unnecessary database functionality
+
+- [ ]   Remove unnecessary default vendor content (for example sample schemas)
+
+- [ ]   Disable any default accounts that are not required to support business requirements
+
+- [ ]   The application should connect to the database with different
+    credentials for every trust distinction (for example user, read-only
+    user, guest, administrators)
+
 \newpage

draft/20-proactive-control-checklist/07-digital-identity.md

@@ -24,8 +24,6 @@ for more context from the 'OWASP Top 10 Proactive Controls' project.
 
 * Design access control authentication thoroughly up-front
 * Force all requests to go through access control checks unless public
-* Deny by default; if a request is not specifically allowed then it is denied
-* Apply least privilege, all the least access as is necessary
 * Do not hard code access controls that are role based
 * Log all access control events
 * Use Multi-Factor Authentication for highly sensitive or high value transactional accounts

draft/20-proactive-control-checklist/08-access-controls.md

@@ -16,71 +16,45 @@ order: 2008
 Access Control (or Authorization) is the process of granting or denying specific requests
 from a user, program, or process.
 
-## Access control
-
-* Use only trusted system objects, e.g. server side session objects,
-    for making access authorization decisions
-
-* Use a single site-wide component to check access authorization. This
-    includes libraries that call external authorization services
+Refer to proactive control '[C8: Protect Data Everywhere][control7]'
+for more context from the 'OWASP Top 10 Proactive Controls' project.
 
-* Access controls should fail securely
+#### Authorization
 
-* Deny all access if the application cannot access its security
-    configuration information
+* Design access control / authorization thoroughly up-front
+* Force all requests to go through access control checks unless public
+* Deny by default; if a request is not specifically allowed then it is denied
+* Apply least privilege, providing the least access as is necessary
+* Log all authorization events
 
-* Enforce authorization controls on every request, including those made by server side scripts
+## Access control
 
+* Enforce authorization controls on every request
+* Use only trusted system objects for making access authorization decisions
+* Use a single site-wide component to check access authorization
+* Access controls should fail securely
+* Deny all access if the application cannot access its security configuration information
 * Segregate privileged logic from other application code
+* Limit the number of transactions a single user or device can perform in a given period of time,
+    low enough to deter automated attacks but above the actual business requirement
+* If long authenticated sessions are allowed, periodically re-validate a user's authorization
+* Implement account auditing and enforce the disabling of unused accounts
+* The application must support termination of sessions when authorization ceases
 
-* Restrict access to files or other resources, including those outside
-    the application\'s direct control, to only authorized users
-
-* Restrict access to protected URLs to only authorized users
-
-* Restrict access to protected functions to only authorized users
-
-* Restrict direct object references to only authorized users
-
-* Restrict access to services to only authorized users
-
-* Restrict access to application data to only authorized users
-
-* Restrict access to user and data attributes and policy information used by access controls
-
-* Restrict access security-relevant configuration information to only authorized users
-
-* Server side implementation and presentation layer representations of access control rules must match
-
-* If state data must be stored on the client, use encryption and integrity checking on the server side
-    to detect state tampering
-
-* Enforce application logic flows to comply with business rules
-
-* Limit the number of transactions a single user or device can perform
-    in a given period of time, low enough to deter automated attacks
-    but above the actual business requirement
-
-* Use the \"referer\" header as a supplemental check only, it should
-    never be the sole authorization check as it is can be spoofed
-
-* If long authenticated sessions are allowed, periodically re-validate
-    a user's authorization to ensure that their privileges have not
-    changed and if they have, log the user out and force them to
-    re-authenticate
+#### References
 
-* Implement account auditing and enforce the disabling of unused accounts
+* OWASP [Cheat Sheet: Authorization][csaz]
+* OWASP [Top 10 Proactive Controls][proactive10]
 
-* The application must support disabling of accounts
-    and terminating sessions when authorization ceases
+----
 
-* Service accounts or accounts supporting connections to or from
-    external systems should have the least privilege possible
+The OWASP Developer Guide is a community effort; if there is something that needs changing
+then [submit an issue][issue2008] or a [pull request][pr].
 
-* Create an Access Control Policy to document an application\'s
-    business rules, data types and access authorization criteria
-    and/or processes so that access can be properly provisioned and
-    controlled. This includes identifying access requirements for both
-    the data and system resources
+[control7]: https://owasp.org/www-project-proactive-controls/v3/en/c7-enforce-access-controls
+[csaz]: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
+[issue2008]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/08-access-controls
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/
 
 \newpage

draft/20-proactive-control-checklist/09-protect-data.md

@@ -13,14 +13,59 @@ order: 2009
 
 ### 20.9 Checklist: Protect Data Everywhere
 
-![Developer Guide](../assets/images/dg_wip.png "OWASP Developer Guide"){: height="220px" }
+Sensitive data such as passwords, credit card numbers, health records, personal information and business secrets
+require extra protection, particularly if that data falls under privacy laws (EU’s General Data Protection Regulation GDPR),
+financial data protection rules such as PCI Data Security Standard (PCI DSS) or other regulations.
 
-The OWASP Development Guide is being rewritten by the OWASP community,
-and the content has yet to be filled in for section 'C8: Protect Data Everywhere'.
+Refer to proactive control '[C8: Protect Data Everywhere][control8]'
+for more context from the 'OWASP Top 10 Proactive Controls' project.
 
-If you would like to contribute then follow the [contributing guidelines][contribute]
-and submit your content for review.
+#### Data Protection
 
-[contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
+* Classify data according to the level of sensitivity
+* Implement appropriate access controls for sensitive data
+* Encrypt data in transit
+* Ensure secure communication channels are properly configured
+* Avoid storing sensitive data when at all possible
+* Ensure sensitive data at rest is cryptographically protected to avoid unauthorized disclosure and modification
+* Purge sensitive data when that data is no longer required
+* Store application-level secrets in a secrets vault
+* Check that secrets are not stored in code, config files or environment variables
+* Implement least privilege, restricting access to functionality, data and system information
+* Protect all cached or temporary copies of sensitive data from unauthorized access
+* Purge those temporary copies of sensitive data as soon as they are no longer required
+
+#### Cryptographic practices
+
+* Use peer reviewed and open solution cryptographic modules
+* All cryptographic functions used to protect secrets from the application user must be implemented on a trusted system
+* Cryptographic modules must fail securely
+* Ensure all random numbers, random file names, random GUIDs, and random strings are generated
+    using the cryptographic module approved random number generator
+* Cryptographic modules used by the application are compliant to FIPS 140-2 or an equivalent standard
+* Establish and utilize a policy and process for how cryptographic keys will be managed
+* Ensure that any secret key is protected from unauthorized access
+* Store keys in a proper secrets vault as described below
+* Use independent keys when multiple keys are required
+* Build support for changing algorithms and keys when needed
+* Build application features to handle a key rotation
+
+#### References
+
+* OWASP [Cheat Sheet: Cryptographic Storage][cscs]
+* OWASP [Cheat Sheet: Secrets Management][cssm]
+* OWASP [Top 10 Proactive Controls][proactive10]
+
+----
+
+The OWASP Developer Guide is a community effort; if there is something that needs changing
+then [submit an issue][issue2009] or a [pull request][pr].
+
+[control8]: https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere
+[cscs]: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
+[cssm]: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_CheatSheet.html
+[issue2009]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/09-protect-data
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/
 
 \newpage