provide input and output checklist

.wordlist.txt

@@ -275,3 +275,7 @@ JWTs
 PKIX
 JWA
 JWKS
+deserialize
+deserialization
+unicode
+deserializes

draft/04-foundations/05-top-ten.md

@@ -21,6 +21,13 @@ and the content has yet to be filled in for section 'Top Ten Web Application Sec
 If you would like to contribute then follow the [contributing guidelines][contribute]
 and submit your content for review.
 
+----
+
+The OWASP Developer Guide is a community effort; if you see something that needs changing
+then [submit an issue][issue0405] or a [pull request][pr] .
+
 [contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
+[issue0405]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2004-foundations/05-top-ten
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
 
 \newpage

draft/05-security-requirements/02-threat-modeling.md

@@ -118,34 +118,35 @@ To provide some structure it is useful to start with Shostack's [Four Question F
 
 **1 What are we building**?
 
-As a starting point you need to define the scope of the Threat Model.
-To do that you need to understand the application you are building, examples of helpful techniques are:
+As a starting point the scope of the Threat Model should be defined.
+This will require an understanding of the application that is being built,
+and some examples of inputs for the threat model could be:
 
 * Architecture diagrams
 * Dataflow transitions
 * Data classifications
 
-You will also need to gather people from different roles with sufficient technical and risk awareness
-to agree on the framework to be used during the Threat modeling exercise.
+It is best to gather people from different roles with sufficient technical and risk awareness
+so that they can agree on the framework to be used during the threat modeling exercise.
 
 **2 What can go wrong**?
 
-This is a research activity in which you want to find the main threats that apply to your application.
+This is a research activity to find the main threats that apply to your application.
 There are many ways to approach the question, including open discussion or using a structure to help think it through.
 Techniques that can help include [CIA][cia], [STRIDE][stride], [LINDDUN][linddun],
 [cyber kill chains][chains], [PASTA][pasta], common attack patterns ([CAPEC][capec]) and others.
 
 **3 What are we going to do about that**?
 
-In this phase you turn your findings into specific actions.
+In this phase turn the threat model findings into specific actions.
 Consider the appropriate [remediation](#remediation) for each threat identified.
 
 **4 Did we do a good enough job**?
 
-Finally, carry out a retrospective activity over the work you have done to check
+Finally, carry out a retrospective activity over the work identified to check
 quality, feasibility, progress, or planning.
 
-The OWASP [Threat Modeling Playbook][OTMP] goes into these practicalities in more detail
+The OWASP [Threat Modeling Playbook][tmpb] goes into these practicalities in more detail
 and provides strategies for maintaining threat modeling within an organisation.
 
 #### How to do it
@@ -154,7 +155,7 @@ There is no one process for threat modeling.
 How it is done in practice will vary according to the organisation's culture,
 according to what type of system / application is being modeled
 and according to preferences of the development team itself.
-The various techniques and concepts are discussed in the [Threat Modeling Cheat Sheet][OTMCS]
+The various techniques and concepts are discussed in the [Threat Modeling Cheat Sheet][tmcs]
 and can be summarised:
 
 1. Terminology: try to use standard terms such as actors, trust boundaries, etc as this will help convey these concepts
@@ -216,9 +217,9 @@ then that is a perfectly good choice.
 
 * [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)
 * OWASP [Threat Model project](https://owasp.org/www-project-threat-model/)
-* OWASP [Threat Modeling Cheat Sheet][OTMCS]
-* OWASP [Threat Modeling Playbook (OTMP)][OTMP]
-* OWASP [Attack Surface Analysis Cheat Sheet][ASACS]
+* OWASP [Threat Modeling Cheat Sheet][tmcs]
+* OWASP [Threat Modeling Playbook (OTMP)][tmpb]
+* OWASP [Attack Surface Analysis Cheat Sheet][asacs]
 * OWASP community pages on [Threat Modeling][TM] and the [Threat Modeling Process][TMP]
 * [The Four Question Framework For Threat Modeling](https://youtu.be/Yt0PhyEdZXU) 60 second video
 * Lockheed's [Cyber Kill Chain][chains]
@@ -241,16 +242,16 @@ The OWASP Developer Guide is a community effort; if you see something that needs
 then [submit an issue][issue0502] or a [pull request][pr] .
 
 [4QFW]: https://github.com/adamshostack/4QuestionFrame
-[ASACS]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
+[asacs]: https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html
 [capec]: https://capec.mitre.org/
 [chains]: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
 [cia]: https://www.nccoe.nist.gov/publication/1800-25/VolA/index.html
 [issue0502]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2005-security-requirements/02-threat-modeling
 [linddun]: https://www.linddun.org/
 [nist-cvss]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator
 [otm]: https://owasp.org/www-project-threat-model/
-[OTMCS]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
-[OTMP]: https://owasp.org/www-project-threat-modeling-playbook/
+[tmcs]: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
+[tmpb]: https://owasp.org/www-project-threat-modeling-playbook/
 [pasta]: https://versprite.com/blog/what-is-pasta-threat-modeling/
 [pr]: https://github.com/OWASP/www-project-developer-guide/pulls
 [PYTM]: https://owasp.org/www-project-pytm/

draft/20-proactive-control-checklist/05-encode-escape-data.md

@@ -13,14 +13,48 @@ order: 2005
 
 ### 20.5 C4: Encode and Escape Data
 
-![Developer Guide](../assets/images/dg_wip.png "OWASP Developer Guide"){: height="220px" }
+Encoding and escaping of output data are defensive techniques meant to stop injection attacks
+on a target system or application which is receiving the output data.
+Refer to proactive control '[Encode and Escape Data][control4]' in the 'OWASP Top 10 Proactive Controls' project.
 
-The OWASP Development Guide is being rewritten by the OWASP community,
-and the content has yet to be filled in for section 'C4: Encode and Escape Data'.
+The target system may be another software component or it may be reflected back to the initial system,
+such as operating system commands,
+so encoding and escaping output data helps to provide defense in depth for the system as a whole.
 
-If you would like to contribute then follow the [contributing guidelines][contribute]
-and submit your content for review.
+#### Character Encoding and Canonicalization
 
-[contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
+* Apply output encoding just before the content is passed to the target system
+* Conduct all output encoding on a trusted system
+* Utilize a standard, tested routine for each type of outbound encoding
+* Specify character sets, such as UTF-8, for all outputs
+* Apply canonicalization to convert unicode data into a standard form
+* Ensure the output encoding is safe for all target systems
+* In particular sanitize all output used for operating system commands
+
+#### Contextual Output Encoding
+
+Contextual output encoding of data is based on how it will be utilized by the target.
+The specific methods vary depending on the way the output data is used, such as HTML entity encoding.
+
+* Contextually encode all data returned to the client from untrusted sources
+* Contextually encode all output of untrusted data to queries for SQL, XML, and LDAP
+
+#### References
+
+* OWASP [Cheat Sheet: Injection Prevention][ipcs]
+* OWASP [Java Encoder Project][encoder]
+* OWASP [Top 10 Proactive Controls][proactive10]
+
+----
+
+The OWASP Developer Guide is a community effort; if you see something that needs changing
+then [submit an issue][issue2005] or a [pull request][pr].
+
+[control4]: https://owasp.org/www-project-proactive-controls/v3/en/c4-encode-escape-data
+[encoder]: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
+[ipcs]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
+[issue2005]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/05-encode-escape-data
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs
 
 \newpage

draft/20-proactive-control-checklist/06-validate-inputs.md

@@ -13,14 +13,61 @@ order: 2006
 
 ### 20.6 C5: Validate All Inputs
 
-![Developer Guide](../assets/images/dg_wip.png "OWASP Developer Guide"){: height="220px" }
+Input validation is a collection of techniques that ensure only properly formatted data
+may enter a software application or system component.
+Refer to proactive control '[Validate All Inputs][control5]' in the 'OWASP Top 10 Proactive Controls' project.
 
-The OWASP Development Guide is being rewritten by the OWASP community,
-and the content has yet to be filled in for section 'C5: Validate All Inputs'.
+It is vital that input validation is performed to provide the starting point for a secure application or system.
+Without input validation the software application/system will continue to be vulnerable to new and varied attacks.
 
-If you would like to contribute then follow the [contributing guidelines][contribute]
-and submit your content for review.
+#### Syntax and Semantic Validity
 
-[contribute]: https://github.com/OWASP/www-project-developer-guide/blob/main/contributing.md
+* Identify all data sources and classify them into trusted and untrusted
+* Validate all input data from untrusted sources such as client provided data
+* Encode input to a common character set before validating
+* Specify character sets, such as UTF-8, for all input sources
+* If the system supports UTF-8 extended character sets then validate after UTF-8 decoding is completed
+* Verify that protocol header values in both requests and responses contain only ASCII characters
+* Validate data from redirects
+* Validate data range and also data length
+* Utilize canonicalization to address obfuscation attacks
+* All validation failures should result in input rejection
+
+#### Validate using Libraries and Frameworks
+
+* Conduct all input validation on a trusted system
+* Use a centralized input validation library or framework for the whole application
+* If the standard validation routine cannot address some inputs then use extra discrete checks
+* If any potentially hazardous input _must_ be allowed then implement additional controls
+* Validate for expected data types using an allow-list rather than a deny-list
+
+#### Validate Serialized Data
+
+* Implement integrity checks or encryption of the serialized objects
+    to prevent hostile object creation or data tampering
+* Enforce strict type constraints during deserialization before object creation;
+    typically a definable set of classes is expected
+* Isolate features that deserialize so that they run in very low privilege environments such as temporary containers
+* Log security deserialization exceptions and failures
+* Restrict or monitor incoming and outgoing network connectivity from containers or servers that deserialize
+* Monitor deserialization, for example alerting if a user agent constantly deserializes
+
+#### References
+
+* OWASP [Cheat Sheet: Input Validation][ivcs]
+* OWASP [Java HTML Sanitizer Project][sanitizer]
+* OWASP [Top 10 Proactive Controls][proactive10]
+
+----
+
+The OWASP Developer Guide is a community effort; if you see something that needs changing
+then [submit an issue][issue2006] or a [pull request][pr].
+
+[control5]: https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs
+[ivcs]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
+[issue2006]: https://github.com/OWASP/www-project-developer-guide/issues/new?labels=enhancement&template=request.md&title=Update:%2020-proactive-control-checklist/06-validate-inputs
+[pr]: https://github.com/OWASP/www-project-developer-guide/pulls
+[proactive10]: https://owasp.org/www-project-proactive-controls/v3/en/c5-validate-inputs
+[sanitizer]: https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer
 
 \newpage