Fixing some table layout issues in the bug bar doc. Content is all the same.

Author: brandon-unity

CONTRIBUTING.md

@@ -10,44 +10,27 @@ Second, before starting on a project that you intend to contribute to the unity-
 ### Document Style
 #### Basics
 - All contributions will be received as PRs - just read the recommendation below first please! 😁
-<<<<<<< HEAD
-- This is intended to be a technical reference for other collegeaues in the security community, so the language and style should reflect that.
-- 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).
-=======
 - This is intended to be a technical reference for other colleagues in the security community, so the language and style should reflect that.
 - 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).
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - 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.
 
 #### Article Updates
 ##### Spelling and Grammar changes
 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.
 
 ##### New Content and Substantial Changes
-<<<<<<< HEAD
-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.
-=======
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 If mutliple people contributed to the content, please include their names in the *Contributors* section at the end of the article. 
 
 #### New Articles and the Template
 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. 
-<<<<<<< HEAD
-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.
-=======
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
 
 ### Attribution and Credit
-<<<<<<< HEAD
-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:
-=======
 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:
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 - 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.
 - 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.
 - Minor changes: Minor changes (spelling, grammar, etc.), will be accepted directly as PRs, with the contributors account logged in the changelog for that PR.
@@ -66,8 +49,4 @@ We'd love to see industry specific versions, or flavors, of this SSDLC being dev
 ---
 
 
-<<<<<<< HEAD
-## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
-=======
 ## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1

Coding Practice/API-Best-Practices.md

@@ -17,11 +17,7 @@ This document covers general security guidelines for API endpoints within Unity.
 API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
 ###### Why We Care
 
-<<<<<<< HEAD
-APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state changing actions on sensitive data.
-=======
 APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state-changing actions on sensitive data.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Example of Issue (Optional)
 
 A POST that allows the user to modify information on an account without checking if the user owns the account being modified.
@@ -52,11 +48,7 @@ Incorrect access controls can range from High to Low Severity.
 Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
 ###### Why We Care
 
-<<<<<<< HEAD
-Depending on how input is parsed, it is possible unvalidated input can contain command injections, or other harmful actions.
-=======
 Depending on how input is parsed, it is possible for unvalidated input to contain command injections, or other harmful actions.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Example of Issue (Optional)
 *TBD*
 
@@ -73,13 +65,7 @@ Restrict http methods
 Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
 ###### Risk Rating
 
-<<<<<<< HEAD
-Input Validation issues could range from Low to High depending on what how the error can be leveraged.
-###### References (Optional)
-*TBD - List external references for more detailed guidance*
-=======
 Input Validation issues could range from Low to High depending on how the error can be leveraged.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ---
 ### Request Integrity
@@ -98,11 +84,7 @@ An attacker sends a previous, genuine request to cause an action to happen again
 Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
 ###### How to Fix?
 
-<<<<<<< HEAD
-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.
-=======
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Depending on what actions the request can take, severity could range from High to Low.
@@ -126,19 +108,9 @@ Returning stack traces or other descriptive information of the service backend
 
 Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
 
-<<<<<<< HEAD
-Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
-=======
 Disable CORS (Cross-Origin Resource Sharing) if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 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.
 ###### Risk Rating
 
 Ranging from Low to High depending on context.
-<<<<<<< HEAD
-###### References (Optional)
-
-*TBD - List external references for more detailed guidance*
-=======
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1

Coding Practice/AuthZ-AuthN-Guidelines.md

@@ -1,9 +1,5 @@
 # Authorization and Authentication Guidelines [Coding Practice]
-<<<<<<< HEAD
-<font size="-1">_Author: Carlo Valentien - Dec. 2018_</font>
-=======
 <font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 
 ## Overview
 
@@ -19,26 +15,6 @@ This document provides guidelines for how to implement authentication and author
 
 **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.
 ## Recommendations
-<<<<<<< HEAD
-### Use a Trusted Identity Provider
-###### Description
-
-Most of our users will be accessing services related to Unity, and we should Unity ID to authenticate those users to any new services or publicly facing applications. Using a single, unified identity to authenticate a user will make it easy for the user to use a new service and application.
-
-When creating internal applications, validate users via their IT issued credentials. 
-###### Why We Care
-
-Many services will require authentication as a requirement. No authentication allows for anonymous access, which prevents proper logging and brings the risk of trivial information disclosure. However, designing an entire authentication service for you an application is also no trivial task, with many caveats that can lead to leaked/bypassed credentials, and a number of other issues. By using a trusted identity provider, the security team can work on securing a small number of authentication platforms to the benefit of a number of teams at Uniyt.
-###### How to Fix?
-
-Determine if your application is an internal or external application. If it is external, contact Genesis and Security to integrate your application with Unity ID. If it is internal, contact IT to integrate with out internal authentication system.
-###### Risk Rating
-
-High
-
----
-=======
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ### Require Multi-Factor Authentication for Sensitive Applications
 ###### Description
 
@@ -57,23 +33,13 @@ Medium
 ### Limit OAuth2 Scope by the Principle of Least Privilege
 ###### Description
 
-<<<<<<< HEAD
-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.
-###### Why We Care
-
-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).
-###### How to Fix?
-
-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. 
-=======
 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.
 ###### Why We Care
 
 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).
 ###### How to Fix?
 
 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. 
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Risk Rating
 
 Medium
@@ -85,17 +51,10 @@ Medium
 ### Limited Token Lifetimes
 ###### Description
 
-<<<<<<< HEAD
-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.
-###### Why We Care
-
-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.
-=======
 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.
 ###### Why We Care
 
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### How to Fix?
 
 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.
@@ -107,11 +66,7 @@ Medium
 ### Validating OAuth2 Redirect URIs
 ###### Description
 
-<<<<<<< HEAD
-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.
-=======
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### Why We Care
 
 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.
@@ -144,17 +99,10 @@ High
 ### Validating the OAuth2 State Parameter
 ###### Description
 
-<<<<<<< HEAD
-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.
-###### Why We Care
-
-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.
-=======
 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.
 ###### Why We Care
 
 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.
->>>>>>> 2910d0b35380405a483e2fd4eb9636ac62a937e1
 ###### How to Fix?
 
 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.