4.0.1 update

Replace 4.0 PDF, Word, csv with minor changes:
- Added Jason Axley as reviewer
- Fixed #619 in 5.3
- Remove temporary PPTX

4.0/OWASP Application Security Verification Standard 4.0-en.csv

@@ -134,7 +134,7 @@ V5,Validation,5.1.3,"Verify that all input (HTML form fields, REST requests, URL
 V5,Validation,5.1.4,"Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers or telephone, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match). ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering))",X,X,X,20,
 V5,Validation,5.1.5,"Verify that URL redirects and forwards only allow whitelisted destinations, or show a warning when redirecting to potentially untrusted content.",X,X,X,601,
 V5,Validation,5.2.1,Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)),X,X,X,116,
-V5,Validation,5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,,X,X,138,
+V5,Validation,5.2.2,Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.,X,X,X,138,
 V5,Validation,5.2.3,Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.,X,X,X,147,
 V5,Validation,5.2.4,"Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.",X,X,X,95,
 V5,Validation,5.2.5,Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.,X,X,X,94,

4.0/en/0x01-Frontispiece.md

@@ -9,7 +9,7 @@ The Application Security Verification Standard is a list of application security
 ![license](../images/license.png)
 Copyright © 2008-2019 The OWASP Foundation. This document is released under the [Creative Commons Attribution ShareAlike 3.0 license](https://creativecommons.org/licenses/by-sa/3.0/). For any reuse or distribution, you must make clear to others the license terms of this work.
 
-Version 4.0, March 2019
+Version 4.0.1, March 2019
 
 ## Project Leads
 
@@ -27,6 +27,7 @@ Version 4.0, March 2019
 - David Johansson
 - Tonimir Kisasondi
 - Ron Perris
+- Jason Axley
 - Abhay Bhargav
 - Benedikt Bauer
 - Elar Lang

4.0/en/0x13-V5-Validation-Sanitization-Encoding.md

@@ -29,7 +29,7 @@ Properly implemented input validation controls, using positive whitelisting and
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---:| :---: | :---: |
 | **5.2.1** | Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature. ([C5](https://www.owasp.org/index.php/OWASP_Proactive_Controls#tab=Formal_Numbering)) | ✓ | ✓ | ✓ | 116 |
-| **5.2.2** | Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length. |  | ✓ | ✓ | 138 |
+| **5.2.2** | Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length. | ✓ | ✓ | ✓ | 138 |
 | **5.2.3** | Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection. | ✓ | ✓ | ✓ | 147 |
 | **5.2.4** | Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed. | ✓ | ✓ | ✓ | 95 |
 | **5.2.5** | Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed. | ✓ | ✓ | ✓ | 94 |
@@ -39,7 +39,7 @@ Properly implemented input validation controls, using positive whitelisting and
 
 ## V5.3 Output encoding and Injection Prevention Requirements
 
-Many of these items are not directly penetration testable (L1), and so although they are critical to the security of any application, they are L2. For all other uses, consider output encoding essential for every application. Failing to output encode will result in an insecure, injectable, and unsafe application, which are testable in V5.2.
+Output encoding close or adjacent to the interpreter in use is critical to the security of any application. Typically, output encoding is not persisted, but used to render the output safe in the appropriate output context for immediate use. Failing to output encode will result in an insecure, injectable, and unsafe application.
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---:| :---: | :---: |