WIP Privacy Testing

dynamic_testing/MSTSG_STORAGE.md

@@ -50,7 +50,7 @@ All of the OWASP principles and checks that were static, e.g code review, were c
 
 ### Dynamic Review
 
-Secure Database - I wasn't able to gain access to the secure database, but a [process]() has since been identified so this can be conducted in future checks
+Secure Database - I wasn't able to gain access to the secure database, but a [process](https://gist.github.com/troach-sf/f257bb7b80e6dddd4f3bade81b7b1410) has since been identified so this can be conducted in future checks
 
 Legacy Databases - The RKStorage, logback.db and cordova_bg_geolocation.db SQL lite databases were examined.
 

dynamic_testing/SPL_PrivacyTesting/E2E_Privacy_Test_001.md

@@ -0,0 +1,79 @@
+# Safe Places Privacy Test
+
+## Data Minimization
+
+* The minimum amount of data possible shall be collected, for the purposes for which it is gathered. Data that is not used in the disclosure to healthcare authorities should not be collected unless it is essential to the purposes of the application
+
+__The data that enteres and leaves the SafePlaces system has been checked, and no data that might breach this principle was found__
+
+* Users can choose how much data to share from symptom surveys
+
+__Symptom surveys not in scope for this release__
+
+## Consent
+
+* A member of the public (MoP) shall be explicitly asked for consent to data being collected or transmitted. Consent should not be implied by usage, or mixed with any other consent requests
+
+__Consent is sought upon application install, and upon the disclosure of data.  It is explicit and not implied.__
+
+* A MoP shall provide informed consent, that is they must be able to understand what they are consenting to and the purposes for which each category of data is gathered
+
+__It is clear what they are consenting to__
+
+* Information about privacy shall be communicated in as simple language as possible while maintaining clarity. Specifically, legal or technical language should be avoided.
+
+__The app screens use simple, non-legal language__
+
+* Consent to collect data shall be separate from consent to disclose data, and include retention periods
+
+__The consent on app install does not specifically say that data will only be kept for 14 days - raised [SAF-720](https://pathcheck.atlassian.net/browse/SAF-720).  Otherwise the consent is separate from disclose and collection.  Disclosure refers to to the HA privacy policy for their retention period.__
+
+* Consent to collect each category of data (e.g. location, proximity) shall be separate
+
+__Only location data is gathered, and the consent is explicitly for that__
+
+* No communication initiated by 3rd parties shall be provided to a MoP, through the app, without their consent
+
+__No mechanism has been identified that would allow this__
+
+* The user of SafePaths shall be able to disable location tracking temporarily
+
+__This is only possible by disabling location tracking on the device__
+
+* Consent to disclose data to a HA shall be separate, at the time of disclosure, and contain a reference to the HA privacy policy
+
+__This is confirmed as separate, and technical support for a link to the HA privacy policy is in place__
+
+* SafePlaces shall support a technical process for users to sign-off on post-redacted data
+
+__This is not in place, there is a technical prompts for a process that needs to be put in place by healthcare authorities.  A better strategic solution would be for the redacted data to be retrieved by the device (it still has the access code) and review a copy.__
+
+## Transparency & Accountability
+
+* The privacy policy shall include the steps taken by the data collector to ensure the confidentiality, integrity, and quality of the data
+__The new PCI privacy policy does not cover this in a lot of detail, but work has started on a Data Protection Impact Assessment that will cover this__
+* The privacy policy shall identify clearly both the person who controls the data that is collected and how the data is stored and disclosed
+__The new PCI privacy policy does so__
+* No single person shall be able to both modify the source code and release the application to the public
+* All source code, models and technical documentation shall be publicly available, including all dependencies
+* An assessment of any residual privacy risks shall be made public in the form of a risk assessment
+__Work has started on a Data Protection Impact Assessment that will cover this__
+
+# Anonymization
+
+* Location, proximity, health, race/ethnicity, gender, and any data that allows the identification of a person, shall be considered sensitive unless it is sufficiently aggregated
+__Pass, only location data is currently stored from this list.  It is protected in it's unaggregated form, until aggregated as a public feed.  [This request](https://pathcheck.atlassian.net/browse/PLACES-42) is open to improve the enforcement of the aggregation process__
+* Paths followed by individuals between waypoints shall not be stored or published
+__This information is inherent to data of individuals location data over time, but importantly, it is not maintained on publishing, as it is aggregated with other data.__
+* No identifiers of nearby devices shall be recorded that can be used to identify a MoP
+__TODO: Need to get into the encrypted DB to check__
+* Healthcare authorities should have the ability to effectively redact data
+__This is confirmed through user interface testing__
+* Un-redacted data shall not be persisted by a Healthcare authority in the Safe Places web application or it’s supporting components
+__TODO:  Storage test__
+* Location or proximity data of less than N number of diagnosed people shall not able to be published, where N can be configured based on local legislation
+__Failed, see [This request](https://pathcheck.atlassian.net/browse/PLACES-42) to improve the enforcement of the aggregation process__
+* Precautions shall be taken to ensure that shared aggregate data may not be re-identified downstream, by ensuring that no data items are passed from SafePaths to SafePlaces that are not required (see Data Minimization)
+__The output published file includes hashes, but not publicly readable data, and not data except aggregated points and space in time.__
+* Users should have the ability to effectively redact data themselves
+__Failed this is not yet in place__

dynamic_testing/Util.java

@@ -0,0 +1,24 @@
+import java.nio.charset.StandardCharsets;
+
+public class Util {
+
+    private final static char[] hexArray = "0123456789ABCDEF".toCharArray();
+
+    //Original source: https://stackoverflow.com/a/9855338/1389357
+    public static String bytesToHex(byte[] bytes) {
+        char[] hexChars = new char[bytes.length * 2];
+        for ( int j = 0; j < bytes.length; j++ ) {
+            int v = bytes[j] & 0xFF;
+            hexChars[j * 2] = hexArray[v >>> 4];
+            hexChars[j * 2 + 1] = hexArray[v & 0x0F];
+        }
+        return new String(hexChars);
+    }
+
+    public static void main(String args[]){
+      byte[] b = args[0].getBytes(StandardCharsets.UTF_8);
+      System.out.println(Util.bytesToHex(b));
+
+    }
+
+}

principles/1_SecurityImplementation.md

@@ -1,6 +1,6 @@
 # Introduction
 
-This document makes heavy use of the OWASP (Open Web Application Security Project) project.  It is best read in conjuction with the OWASP deliverables that explain acronyms, reference test procedures, and provide a glossary.
+This document makes heavy use of the OWASP (Open Web Application Security Project) project.  It is best read in conjuction with the OWASP deliverables that explain acronyms, reference test procedures, and provide a glossary.  Where a test result is recorded against a principle, the icon links to a test or issue report.
 
 ## Safe Paths
 
@@ -90,8 +90,7 @@ necessary privileges needed
 * Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role.  Permissions should still be allocated using roles ![](../images/pass.oos?raw=true)
 
 #### 1.5 Input and Output Architectural Requirements
-* Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and other
-policy compliance
+* Verify that input and output requirements clearly define how to handle and process data based on type, content, and applicable laws, regulations, and otherpolicy compliance
 * Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection
 * Verify that input validation is enforced on a trusted service layer
 * Verify that output encoding occurs close to or by the interpreter for which it is intended.
@@ -108,7 +107,7 @@ policy compliance
 * Verify that all sensitive data is identified and classified into protection levels
 * Verify that all protection levels have an associated set of protection requirements, such as encryption requirements, integrity requirements, retention, privacy and other confidentiality requirements, and that these are applied in the architecture
 
-#### V1.9 Communications Architectural Requirements
+#### 1.9 Communications Architectural Requirements
 * Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or
 cloud providers
 * Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains
@@ -136,38 +135,33 @@ applications, especially when they are performing sensitive or dangerous actions
 * Verify the application does not use unsupported, insecure, or deprecated clientside technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets
 
 #### 2.10 Service Authentication Requirements
-* Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts.
-* Verify that if passwords are required, the credentials are not a default account.
-* Verify that passwords are stored with sufficient protection to prevent offline recovery attacks, including local system access.
-* Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware
-trusted platform module (TPM), or a hardware security module (L3) is recommended for password storage.
+* Verify that integration secrets do not rely on unchanging passwords, such as API keys or shared privileged accounts. [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that if passwords are required, the credentials are not a default account.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware trusted platform module (TPM), or a hardware security module (L3) is recommended for password storage.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
 
 #### 3.1 Fundamental Session Management Requirements
 
 * Verify the application never reveals session tokens in URL parameters or error messages.
 
 #### 3.2 Session Binding Requirements
 
-* Verify the application generates a new session token on user authentication.
-* Verify that session tokens possess at least 64 bits of entropy.
-* Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.
-* Verify that session token are generated using approved cryptographic algorithms.
+* Verify the application generates a new session token on user authentication.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that session tokens possess at least 64 bits of entropy.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.  [![FAIL](../images/fail.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that session token are generated using approved cryptographic algorithms.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
 
 #### 3.3 Session Logout and Timeout Requirements
-* Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties
-* If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period
-* Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties.
-* Verify that users are able to view and log out of any or all currently active sessions and device
-* Verify that users are able to view and log out of any or all currently active sessions and devices.
+* Verify that logout and expiration invalidate the session token, such that the back button or a downstream relying party does not resume an authenticated session, including across relying parties.  [![FAIL](../images/fail.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* If authenticators permit users to remain logged in, verify that re-authentication occurs periodically both when actively used or after an idle period.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that the application terminates all other active sessions after a successful password change, and that this is effective across the application, federated login (if present), and any relying parties.  [![FAIL](../images/fail.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that users are able to view and log out of any or all currently active sessions and device.  [![FAIL](../images/fail.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
 
 #### 3.5 Token Based Session Management
-* Verify the application does not treat OAuth and refresh tokens — on their own — as the presence of the subscriber and allows users to terminate trust relationships with linked applications.
-* Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.
-* Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.
+* Verify the application uses session tokens rather than static API secrets and keys, except with legacy implementations.  [![PASS](../images/pass.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
+* Verify that stateless session tokens use digital signatures, encryption, and other countermeasures to protect against tampering, enveloping, replay, null cipher, and key substitution attacks.  [![FAIL](../images/fail.png?raw=true)](../dynamic_testing/SPL_WebServicesTesting/SPLWebServices.md)
 
 #### 3.6 Re-authentication from a Federation or Assertion
-* Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a
-session within that period.
+* Verify that relying parties specify the maximum authentication time to CSPs and that CSPs re-authenticate the subscriber if they haven't used a session within that period.
 * Verify that CSPs inform relying parties of the last authentication event, to allow RPs to determine if they need to re-authenticate the user.
 
 #### 3.7 Defenses Against Session Management Exploits
@@ -208,9 +202,8 @@ line output encoding.
 * Verify that the application protects against XPath injection or XML injection attacks.
 
 #### 5.4 Memory, String, and Unmanaged Code Requirements
-* Verify that the application uses memory-safe string, safer memory copy and
-pointer arithmetic to detect or prevent stack, buffer, or heap overflows. ✓ ✓ 120
-* Verify that format strings do not take potentially hostile input, and are constant. ✓ ✓ 134
+* Verify that the application uses memory-safe string, safer memory copy and pointer arithmetic to detect or prevent stack, buffer, or heap overflows.
+* Verify that format strings do not take potentially hostile input, and are constant.
 * Verify that sign, range, and input validation techniques are used to prevent
 integer overflows.