Update security modules #608
Conversation
Added descriptive identifiers and how to test
added descriptive identifiers & how to test
addid descriptive identifiers & how to test
| <div class="rule" id="api-52"> | ||
| <p class="rulelab"><strong>API-52</strong>: Use OAuth 2.0 for authorization with rights delegation</p> | ||
| **How to test** | ||
| Testing is conditional on a correct Open API Specification(OAS) being present as well as an access token being provided by the API provider to the test client. If this is the case an automated test client can test if the access control method works according to this rule and the method specified in the OAS spec is indeed implemented. Negative tests are out of scope as there are to many variables to account for when testing other (not allowed) methods for providing tokens. |
There was a problem hiding this comment.
... method specified in the OAS spec ...
Spec is dubbel.
| <div class="rule" id="api-52"> | ||
| <p class="rulelab"><strong>API-52</strong>: Use OAuth 2.0 for authorization with rights delegation</p> | ||
| **How to test** | ||
| Testing is conditional on a correct Open API Specification(OAS) being present as well as an access token being provided by the API provider to the test client. If this is the case an automated test client can test if the access control method works according to this rule and the method specified in the OAS spec is indeed implemented. Negative tests are out of scope as there are to many variables to account for when testing other (not allowed) methods for providing tokens. |
There was a problem hiding this comment.
Wellicht goed om te verduidelijken dat we het security object uit de OAS gebruikt wordt. Daarbij welke types toegestaan zijn: https://spec.openapis.org/oas/v3.0.0.html#fixed-fields-22
| <p>This is in line with the way the OAuth standard appears on the comply or explain list of Forum Standaardisatie.</p> | ||
| </div> | ||
|
|
||
| **How to test** | ||
| Any test is conditional upon the API provider informing the test client in some way that rights delegation is applicable. IF this is the case the test client can identify if the endpoints required by NL GOV Assurance profile for OAuth 2.0 are present and active. A full compliance test of this profile is out of scope for this module. |
There was a problem hiding this comment.
Vraag, als type: oauth2 in de OAS staat dan moet het voldoen aan NL GOV Assurance profile for OAuth 2.0? Of is dat optioneel?
Zo ja, dan zou voor het testen handig zijn dat het profiel actief gebruikt moet worden. Ook al valt testen nu buiten scope.
| <p>This is in line with the way the OAuth standard appears on the comply or explain list of Forum Standaardisatie.</p> | ||
| </div> | ||
|
|
||
| **How to test** | ||
| Any test is conditional upon the API provider informing the test client in some way that rights delegation is applicable. IF this is the case the test client can identify if the endpoints required by NL GOV Assurance profile for OAuth 2.0 are present and active. A full compliance test of this profile is out of scope for this module. |
| **How to test** | ||
| Sensitive information URIS is not machine testable and therfor not part of automated tests. It should be part of any security audit performed by human experts. | ||
|
|
||
| The usage of TLS is machine testable. The test is designed for maximum automation. To test, adherence to NCSC reccomendations should be tested. The serverside is what will be tested, only control over the server is assumed for testing. A testing client will be employed to test adherence of the server. Supporting any protocols, algorithms, key sizes, options or ciphers dat are deemed insufficient or phase out by NCSC will lead to failure on the automated test. Both positive and negative scenario's are part of the test. Testing that a subset of good and sufficient reccomendations are supported and testing that phase out and insufficient reccomendations are not. A manual exception to the automated test results can be made when phase out reccomendations are supported. The API provider will have to provide clear documentation for the phase out schedule. |
There was a problem hiding this comment.
Wat doen we wanneer het NCSC met nieuwe aanbevelingen komt>
Een regel gaat van good naar phase out. Denk dat het goed is om x-tijd te geven om daar aan te voldoen. Maw: wat is uitfaseren, hoeveel tijd mag dat kosten?
A manual exception to the automated test results can be made when phase out reccomendations are supported. The API provider will have to provide clear documentation for the phase out schedule.
Als we een tijdslimiet stellen aan uitfaseren is een handmatige uitzondering wellicht niet meer nodig.
Zo niet, dan moet z'n uitzondering wel kenbaar gemaakt worden aan de automatisch test. Een geschikte plaats is de OAS in een bepaald veld.
| @@ -67,17 +81,24 @@ The headers below are only intended to provide additional security when response | |||
|
|
|||
| In addition to the above listed HTTP security headers, web- and browser-based applications SHOULD apply Subresource Integrity [SRI](https://www.w3.org/TR/SRI/). When using third-party hosted contents, e.g. using a Content Delivery Network, this is even more relevant. While this is primarily a client implementation concern, it may affect the API when it is not strictly segregated or for example when shared supporting libraries are offered. | |||
|
|
|||
| **How to test** | |||
| The precense of the mandatory security headers can be tested in an automated way. A test client makes a call to the API root. The response is tested for the precense of mandatory headers. | |||
There was a problem hiding this comment.
Boven de table met headers wordt SHOULD gebruikt en geen MUST. Op zich logisch want Cache-Control: no-store is niet wenselijke voor niet gevoelige informatie.
Denk dat het goed om nog eens naar de lijst met headers en de waarde te kijken. Nu is het not te 'vrij' welke headers echt nodig zijn en welke waarde de moeten hebben of bevatten.
Strict-Transport-Security zou een losse regel kunnen worden. Je kan testen op max-age voldoende is. Als het domein preloaded is, dan is deze header niet nodig. Zoals bij .dev het geval is.
There was a problem hiding this comment.
Define preload, it's not formally defined (e.g. RFC 6797 § 12.3. HSTS Pre-Loaded List does not really have a definition, or how it works).
| <p>Use CORS to restrict access from other domains (if applicable).</p> | ||
| </div> | ||
|
|
||
| Modern web browsers use Cross-Origin Resource Sharing (CORS) to minimize the risk associated with cross-site HTTP-requests. By default browsers only allow 'same origin' access to resources. This means that responses on requests to another `[scheme]://[hostname]:[port]` than the `Origin` request header of the initial request will not be processed by the browser. To enable cross-site requests API's can return a `Access-Control-Allow-Origin` response header. It is RECOMMENDED to use a whitelist to determine the validity of different cross-site request. To do this check the `Origin` header of the incoming request and check if the domain in this header is on the whitelist. If this is the case, set the incoming `Origin` header in the `Access-Control-Allow-Origin` response header. | ||
|
|
||
| Using a wildcard `*` in the `Access-Control-Allow-Origin` response header is NOT RECOMMENDED, because it disables CORS-security measures. Only for an open API which has to be accessed by numerous other websites this is appropriate. | ||
|
|
||
| **How to test** | ||
| Tests of this design rule can only be performed when the intended client is known to the tester. A thest can be performed when this information is provided by the API provider. Otherwise no conclusive test result can be reached. |
I added descriptions on how to test API design rules in the acces-control en transport-security modules, as discussed in the workinggroup. I also updated the identifiers to have in descriptive names in line with other modules and the revised core. I made security headers into a new design rule as some of them are mandatory (HSTS even by law since 1-7-2023)