Skip to content

Commit db011b9

Browse files
committed
Syninc up
2 parents 8f6a133 + 2910d0b commit db011b9

16 files changed

+428
-1
lines changed

CONTRIBUTING.md

Lines changed: 22 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,27 +10,44 @@ Second, before starting on a project that you intend to contribute to the unity-
1010
### Document Style
1111
#### Basics
1212
- All contributions will be received as PRs - just read the recommendation below first please! 😁
13+
<<<<<<< HEAD
1314
- This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
1415
- You'll notice that our language if fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official [Code of Conduct](./CODE-OF-CONDUCT.md).
16+
=======
17+
- This is intended to be a technical reference for other colleagues in the security community, so the language and style should reflect that.
18+
- You'll notice that our language is fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official [Code of Conduct](./CODE-OF-CONDUCT.md).
19+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
1520
- Given the nature of this content, it's ultimately meant for developers writing the code, not just security folks looking at it - it's not productive to write an article that not everyone can understand. Keep things simple, but accurate.
1621

1722
#### Article Updates
1823
##### Spelling and Grammar changes
1924
Simply update the spelling of the article and do a PR. For simple changes like this, we won't be updating the Authorship or contributor section in the article itself, but your PR will be in the changelog.
2025

2126
##### New Content and Substantial Changes
27+
<<<<<<< HEAD
2228
If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaning the original articles style and template as closely as reasonable.
29+
=======
30+
If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaining the original articles style and template as closely as reasonable.
31+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
2332
2433
If mutliple people contributed to the content, please include their names in the *Contributors* section at the end of the article.
2534

2635
#### New Articles and the Template
2736
If creating a new article, we'd recommend taking a look at the [Contribution_Template](./Contribution_Template.md) that we have to help improve consistency in the article formatting.
37+
<<<<<<< HEAD
2838
We're open to article in differing format, but variance from the template will necessicate a review of the articles layout to ensure it's readable and logical.
39+
=======
40+
We're open to article in differing format, but variance from the template will necessitate a review of the articles layout to ensure it's readable and logical.
41+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
2942
3043
For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
3144

3245
### Attribution and Credit
46+
<<<<<<< HEAD
3347
An importact aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discused a bit, but we'll repeat it here for clarity:
48+
=======
49+
An important aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discussed a bit, but we'll repeat it here for clarity:
50+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
3451
- Authors: Original Authors of an article will be given credit at the top of the article. This will include the month and year the content was originally written.
3552
- Contributors: People who have provided new research or recommendations to an article will be added as a Contributor in the appropriate section at the bottom of the page, along with the month and year their contribution was made.
3653
- Minor changes: Minor changes (spelling, grammar, etc.), will be accepted directly as PRs, with the contributors account logged in the changelog for that PR.
@@ -49,4 +66,8 @@ We'd love to see industry specific versions, or flavors, of this SSDLC being dev
4966
---
5067

5168

52-
## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
69+
<<<<<<< HEAD
70+
## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
71+
=======
72+
## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
73+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1

Coding Practice/API-Best-Practices.md

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,7 +17,11 @@ This document covers general security guidelines for API endpoints within Unity.
1717
API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
1818
###### Why We Care
1919

20+
<<<<<<< HEAD
2021
APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state changing actions on sensitive data.
22+
=======
23+
APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state-changing actions on sensitive data.
24+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
2125
###### Example of Issue (Optional)
2226

2327
A POST that allows the user to modify information on an account without checking if the user owns the account being modified.
@@ -48,7 +52,11 @@ Incorrect access controls can range from High to Low Severity.
4852
Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
4953
###### Why We Care
5054

55+
<<<<<<< HEAD
5156
Depending on how input is parsed, it is possible unvalidated input can contain command injections, or other harmful actions.
57+
=======
58+
Depending on how input is parsed, it is possible for unvalidated input to contain command injections, or other harmful actions.
59+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
5260
###### Example of Issue (Optional)
5361
*TBD*
5462

@@ -65,9 +73,13 @@ Restrict http methods
6573
Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
6674
###### Risk Rating
6775

76+
<<<<<<< HEAD
6877
Input Validation issues could range from Low to High depending on what how the error can be leveraged.
6978
###### References (Optional)
7079
*TBD - List external references for more detailed guidance*
80+
=======
81+
Input Validation issues could range from Low to High depending on how the error can be leveraged.
82+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
7183
7284
---
7385
### Request Integrity
@@ -86,7 +98,11 @@ An attacker sends a previous, genuine request to cause an action to happen again
8698
Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
8799
###### How to Fix?
88100

101+
<<<<<<< HEAD
89102
Generate signatures or HMACs for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
103+
=======
104+
Generate signatures or HMACs (Hashed Message Authentication Codes) for each request containing sensitive data or actions. Check the signature of the request to determine if it is genuine. Sign requests that include timestamps, and deny all requests that are relatively too old.
105+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
90106
###### Risk Rating
91107

92108
Depending on what actions the request can take, severity could range from High to Low.
@@ -110,12 +126,19 @@ Returning stack traces or other descriptive information of the service backend
110126

111127
Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
112128

129+
<<<<<<< HEAD
113130
Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
131+
=======
132+
Disable CORS (Cross-Origin Resource Sharing) if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
133+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
114134
115135
Return vague error responses. Put as little information as possible when returning an error to the user. Do not return any information about the server environment or debug information like stack traces.
116136
###### Risk Rating
117137

118138
Ranging from Low to High depending on context.
139+
<<<<<<< HEAD
119140
###### References (Optional)
120141

121142
*TBD - List external references for more detailed guidance*
143+
=======
144+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1

Coding Practice/AuthZ-AuthN-Guidelines.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,9 @@
11
# Authorization and Authentication Guidelines [Coding Practice]
2+
<<<<<<< HEAD
23
<font size="-1">_Author: Carlo Valentien - Dec. 2018_</font>
4+
=======
5+
<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
6+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
37
48
## Overview
59

@@ -15,6 +19,7 @@ This document provides guidelines for how to implement authentication and author
1519

1620
**Authorization** is the process of ensuring a user can only access resources they are supposed to, usually based on some role or Risk Rating that is defined according to business logic.
1721
## Recommendations
22+
<<<<<<< HEAD
1823
### Use a Trusted Identity Provider
1924
###### Description
2025

@@ -32,6 +37,8 @@ Determine if your application is an internal or external application. If it is e
3237
High
3338

3439
---
40+
=======
41+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
3542
### Require Multi-Factor Authentication for Sensitive Applications
3643
###### Description
3744

@@ -50,13 +57,23 @@ Medium
5057
### Limit OAuth2 Scope by the Principle of Least Privilege
5158
###### Description
5259

60+
<<<<<<< HEAD
5361
When an OAuth2 client, a scope is defined for the the client. This scope determines which Genesis Backend APIs are accessible to the client after performing authentication. When setting up a new OAuth2 client, the team requesting the client should identify what APIs/data they need access to, and limit the scope to those specific APIs.
5462
###### Why We Care
5563

5664
Limiting the scope of our APIs is a best practice, that can limit the impact of a successful attack. Also, often it is a Unity ID user that is authenticating using the given scope, and with the given access token will give the user direct access to the APIs. Since this is publicly accessible, care should be taken that the user cannot access sensitive APIs, in particular APIs that handle personally identifiable information (PII).
5765
###### How to Fix?
5866

5967
During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with Genesis to build a custom scope that will limit access to wider APIs.
68+
=======
69+
When an OAuth2 client, a scope is defined for the the client. This scope determines which backend APIs are accessible to the client after performing authentication via the auth provider. When setting up a new OAuth2 client, the team requesting the client should identify what APIs/data they need access to, and limit the scope to those specific APIs.
70+
###### Why We Care
71+
72+
Limiting the scope of our APIs is a best practice that can limit the impact of a successful attack. Also, often it is a Unity ID user that is authenticating using the given scope, and with the given access token will give the user direct access to the APIs. Since this is publicly accessible, care should be taken that the user cannot access sensitive APIs, in particular, APIs that handle personally identifiable information (PII).
73+
###### How to Fix?
74+
75+
During the requirements phase, determine what information is needed for the OAuth2 client, and limit the APIs to only what is necessary. If possible, work with the auth provider to build a custom scope that will limit access to wider APIs.
76+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
6077
###### Risk Rating
6178

6279
Medium
@@ -68,10 +85,17 @@ Medium
6885
### Limited Token Lifetimes
6986
###### Description
7087

88+
<<<<<<< HEAD
7189
When authenticating, a variety of tokens are used to prove the identity of a user. This is typically through a session cookie, or an access token attached to a user’s account. These tokens should have the shortest lifetime that balances the needs to of the users with security. Tokens should not be valid for an infinite amount of time, and should expire within a reasonable timeframe.
7290
###### Why We Care
7391

7492
This is primarily a defense-in-depth measure, focusing on the case if these tokens are compromised, it will limit the impact of an attack. This also decreases the attack surface of a resulting application, reducing the number of valid tokens at any given time.
93+
=======
94+
When authenticating, a variety of tokens are used to prove the identity of a user. This is typically through a session cookie, or an access token attached to a user’s account. These tokens should have the shortest lifetime that balances the needs of the users with security. Tokens should not be valid for an infinite length of time, and should expire within a reasonable timeframe.
95+
###### Why We Care
96+
97+
This is primarily a defense-in-depth measure, focusing on limiting the impact of an attack if these tokens are compromised. This also decreases the attack surface of a resulting application, reducing the number of valid tokens at any given time.
98+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
7599
###### How to Fix?
76100

77101
Check all tokens related to authentication, and review their lifetimes. If you are unsure, contact security for recommendations on their lifetimes. When possible, use the shortest lifetime within a reasonable use.
@@ -83,7 +107,11 @@ Medium
83107
### Validating OAuth2 Redirect URIs
84108
###### Description
85109

110+
<<<<<<< HEAD
86111
When performing the OAuth2 login flow, a redirect URI is used to securely send the access token to the client web application, after it has authenticated with Genesis. This is provided by the client during the OAuth2 flow. This URI should be validated to ensure it is a known URI that is used by the OAuth2 client.
112+
=======
113+
When performing the OAuth2 login flow, a redirect URI is used to securely send the access token to the client web application, after it has authenticated with the auth provider. This is provided by the client during the OAuth2 flow. This URI should be validated to ensure it is a known URI that is used by the OAuth2 client.
114+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
87115
###### Why We Care
88116

89117
This prevents a potential information disclosure attack when there is an open redirect on a valid redirect URI. This results in a user’s OAuth token being potentially leaked, compromising their account.
@@ -116,10 +144,17 @@ High
116144
### Validating the OAuth2 State Parameter
117145
###### Description
118146

147+
<<<<<<< HEAD
119148
When starting the initial OAuth2 flow, the client has the option of providing a state parameter. This state parameter is then send back with the authorization to be validated by the client later in the flow. This state parameter should be generated upon the initial OAuth2 request, and stored to validate once the authorization from Genesis has occurred.
120149
###### Why We Care
121150

122151
This is to ensure that the OAuth2 flow is initiated by the user, and is not vulnerable to a potential CSRF. By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
152+
=======
153+
When starting the initial OAuth2 flow, the client has the option of providing a state parameter. This state parameter is then sent back with the authorization to be validated by the client later in the flow. This state parameter should be generated upon the initial OAuth2 request, and stored to validate once the authorization from the auth provider has occurred.
154+
###### Why We Care
155+
156+
This is to ensure that the OAuth2 flow is initiated by the user, and is not vulnerable to a potential CSRF (Cross-Site Request Forgery). By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
157+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
123158
###### How to Fix?
124159

125160
Generate a cryptographically-secure random state parameter when the OAuth2 flow is initialized. The client should validate this when it is returned through the redirect URI callback. The parameter should only be valid for the same OAuth2 flow that initiated it.

0 commit comments

Comments
 (0)