You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+22-1Lines changed: 22 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -10,27 +10,44 @@ Second, before starting on a project that you intend to contribute to the unity-
10
10
### Document Style
11
11
#### Basics
12
12
- All contributions will be received as PRs - just read the recommendation below first please! 😁
13
+
<<<<<<< HEAD
13
14
- This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
14
15
- 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
15
20
- 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.
16
21
17
22
#### Article Updates
18
23
##### Spelling and Grammar changes
19
24
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.
20
25
21
26
##### New Content and Substantial Changes
27
+
<<<<<<< HEAD
22
28
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
23
32
24
33
If mutliple people contributed to the content, please include their names in the *Contributors* section at the end of the article.
25
34
26
35
#### New Articles and the Template
27
36
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
28
38
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
29
42
30
43
For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
31
44
32
45
### Attribution and Credit
46
+
<<<<<<< HEAD
33
47
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
34
51
- 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.
35
52
- 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.
36
53
- 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
49
66
---
50
67
51
68
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).
Copy file name to clipboardExpand all lines: Coding Practice/API-Best-Practices.md
+23Lines changed: 23 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,11 @@ This document covers general security guidelines for API endpoints within Unity.
17
17
API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
18
18
###### Why We Care
19
19
20
+
<<<<<<< HEAD
20
21
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
21
25
###### Example of Issue (Optional)
22
26
23
27
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.
48
52
Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
49
53
###### Why We Care
50
54
55
+
<<<<<<< HEAD
51
56
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
52
60
###### Example of Issue (Optional)
53
61
*TBD*
54
62
@@ -65,9 +73,13 @@ Restrict http methods
65
73
Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
66
74
###### Risk Rating
67
75
76
+
<<<<<<< HEAD
68
77
Input Validation issues could range from Low to High depending on what how the error can be leveraged.
69
78
###### References (Optional)
70
79
*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
71
83
72
84
---
73
85
### Request Integrity
@@ -86,7 +98,11 @@ An attacker sends a previous, genuine request to cause an action to happen again
86
98
Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
87
99
###### How to Fix?
88
100
101
+
<<<<<<< HEAD
89
102
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
90
106
###### Risk Rating
91
107
92
108
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
110
126
111
127
Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
112
128
129
+
<<<<<<< HEAD
113
130
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
114
134
115
135
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.
116
136
###### Risk Rating
117
137
118
138
Ranging from Low to High depending on context.
139
+
<<<<<<< HEAD
119
140
###### References (Optional)
120
141
121
142
*TBD - List external references for more detailed guidance*
Copy file name to clipboardExpand all lines: Coding Practice/AuthZ-AuthN-Guidelines.md
+35Lines changed: 35 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,9 @@
1
1
# Authorization and Authentication Guidelines [Coding Practice]
2
+
<<<<<<< HEAD
2
3
<fontsize="-1">_Author: Carlo Valentien - Dec. 2018_</font>
4
+
=======
5
+
<fontsize="-1">_Author: Carlo Valentin - Dec. 2018_</font>
6
+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
3
7
4
8
## Overview
5
9
@@ -15,6 +19,7 @@ This document provides guidelines for how to implement authentication and author
15
19
16
20
**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.
17
21
## Recommendations
22
+
<<<<<<< HEAD
18
23
### Use a Trusted Identity Provider
19
24
###### Description
20
25
@@ -32,6 +37,8 @@ Determine if your application is an internal or external application. If it is e
32
37
High
33
38
34
39
---
40
+
=======
41
+
>>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
35
42
### Require Multi-Factor Authentication for Sensitive Applications
36
43
###### Description
37
44
@@ -50,13 +57,23 @@ Medium
50
57
### Limit OAuth2 Scope by the Principle of Least Privilege
51
58
###### Description
52
59
60
+
<<<<<<< HEAD
53
61
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.
54
62
###### Why We Care
55
63
56
64
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).
57
65
###### How to Fix?
58
66
59
67
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
60
77
###### Risk Rating
61
78
62
79
Medium
@@ -68,10 +85,17 @@ Medium
68
85
### Limited Token Lifetimes
69
86
###### Description
70
87
88
+
<<<<<<< HEAD
71
89
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.
72
90
###### Why We Care
73
91
74
92
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
75
99
###### How to Fix?
76
100
77
101
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
83
107
### Validating OAuth2 Redirect URIs
84
108
###### Description
85
109
110
+
<<<<<<< HEAD
86
111
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
87
115
###### Why We Care
88
116
89
117
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
116
144
### Validating the OAuth2 State Parameter
117
145
###### Description
118
146
147
+
<<<<<<< HEAD
119
148
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.
120
149
###### Why We Care
121
150
122
151
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
123
158
###### How to Fix?
124
159
125
160
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