Clean commit.

CODE-OF-CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct/
+
+[homepage]: https://www.contributor-covenant.org

CONTRIBUTING.md

@@ -0,0 +1,52 @@
+# Contributing
+
+## If you are interested in contributing, here are some ground rules:
+
+### Communication
+First, please read through our code of conduct, as we expect all our contributors to follow it.
+
+Second, before starting on a project that you intend to contribute to the unity-ssldc, we strongly recommend posting on our Issues page and briefly outlining the changes you plan to make. This will enable us to provide some context that may be helpful for you. This could range from advice and feedback on how to optimally perform your changes or reasons for not doing it.
+
+### Document Style
+#### Basics
+- All contributions will be received as PRs - just read the recommendation below first please! 😁
+- 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).
+- 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
+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 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. 
+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.
+
+For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.
+
+### Attribution and Credit
+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:
+- 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.
+
+### Review Process
+Currently the review process will be ad-hoc within the Unity Security team. All approval decisions will be the responsibility of Unity. We'll do our best to adapt and adjust according to the rate and quality of contributions as we move forward.
+
+If you disagree with an editorial decision, we'll be open to the conversation. Ultimately, however, if an agreement can't be reached, then forking this into a new version may be the most appropriate option. 
+
+
+## Forking
+**Please fork!**
+We'd love to see industry specific versions, or flavors, of this SSDLC being developed. We know that some of the best practices here may be too specific, or not specific enough, in areas that are important to your business or industry. Assuming all this goes well, we'll likely have our own fork to more narrowly focus recommendations for game developers and studios.
+
+
+---
+
+
+## All contributions are governed by the [Apache 2.0 license](./LICENSE.md).

Coding Practice/API-Best-Practices.md

@@ -0,0 +1,116 @@
+# API Best Practices Guidelines [Coding Practice] 
+<font size="-1">_Author: Frank Arana - Dec. 2018_</font>
+
+## Overview
+
+This document covers general security guidelines for API endpoints within Unity. These guidelines will cover general points like:
+- [Access control best practices](#access-controls)
+- [Input validation](#input-validation)
+- [Request verification](#request-integrity)
+- [Replay attacks](#replay-attacks)
+- [General security practices relevant to, but not specific to APIs](#general)
+
+### Recommendations
+#### Access Controls
+###### Description
+
+API endpoints should follow the principle of least privilege. Services with protected information should serve to the smallest group possible.
+###### Why We Care
+
+APIs with misconfigured access controls can lead to unintentional information leaks, or unauthorized and malicious state changing actions on sensitive data.
+###### 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.
+
+A GET request that returns sensitive informative information without authentication.
+
+###### How to Fix?
+
+Determine which API actions should be considered sensitive or public.
+
+For Internal (to Unity) APIs: Limit network access as much as possible. Ideally, these endpoints should be restricted to a closed network, and require authentication stronger than a singular API key. For example, multi-factor authentication.
+
+For Public APIs with sensitive information: Require authentication before performing any action being requested. API keys should be both revocable and renewable.
+
+For Public APIs providing public information: Ensure no state changing actions are being performed through a public API without authentication. Consider rate limiting to prevent a single host making too many requests in a small amount of time.
+###### Risk Rating
+
+Incorrect access controls can range from High to Low Severity.
+###### References (Optional)
+
+- https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
+
+---
+
+#### Input Validation
+###### Description
+
+Incoming data can be malformed or crafted to cause unintended behavior when it is parsed.
+###### Why We Care
+
+Depending on how input is parsed, it is possible unvalidated input can contain command injections, or other harmful actions.
+###### Example of Issue (Optional)
+*TBD*
+
+###### How to Fix?
+
+Type checking - Ensure input is of the expected data type, reject anything else.
+
+Length and size checking - Input should be within an expected length or size. Reject anything larger or smaller than expected.
+
+Whitelist accepted content-types
+
+Restrict http methods
+
+Parsing - Third party parsers should be kept up to date, changes to internal parsers should be carefully reviewed.
+###### Risk Rating
+
+Input Validation issues could range from Low to High depending on what how the error can be leveraged.
+
+---
+### Request Integrity
+###### Description
+
+It is possible that a request could be modified in-transit between the original requestor and the API endpoint.
+###### Why We Care
+
+Modified requests may cause state changing actions to the original requestor’s data, or cause incorrect, modified, or unexpected data to be served.
+###### Example of Issue (Optional)
+
+---
+### Replay Attacks
+An attacker sends a previous, genuine request to cause an action to happen again at a later time.
+
+Modified requests in-transit: An attacker modifies data in the genuine request as it is sent.
+###### How to Fix?
+
+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.
+###### Risk Rating
+
+Depending on what actions the request can take, severity could range from High to Low.
+###### References (Optional)
+
+- https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html#why-requests-are-signed
+
+---
+### General
+###### Description
+Common security practices relevant, but not exclusive to APIs
+###### Why We Care
+
+Even by following best security practices for APIs, it is possible to miss other malicious activity.
+###### Example of Issue (Optional)
+
+No logging or monitoring missing security events
+
+Returning stack traces or other descriptive information of the service backend
+###### How to Fix?
+
+Log and monitor API activity. Detecting anomalies can assist in finding malicious activity that isn’t apparent anywhere else.
+
+Disable CORS if not needed, or scope it down as small as possible to prevent forged requests or data leakage.
+
+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.

Coding Practice/AuthZ-AuthN-Guidelines.md

@@ -0,0 +1,114 @@
+# Authorization and Authentication Guidelines [Coding Practice]
+<font size="-1">_Author: Carlo Valentin - Dec. 2018_</font>
+
+## Overview
+
+This document provides guidelines for how to implement authentication and authorization in Unity applications.These guidelines will cover general points like:
+- [Use a Trusted Identity Provider](#use-a-trusted-identity-provider)
+- [Require Multi-Factor Authentication for Sensitive Applications](#require-multi-factor-authentication-for-sensitive-applications)
+- [Limit OAuth2 Scope by the Principle of Least Privilege](#limit-oauth2-scope-by-the-principle-of-least-privilege)
+- [Limited Token Lifetimes](#limited-token-lifetimes)
+- [Validating OAuth2 Redirect URIs](#validating-oauth2-redirect-uris)
+- [Validating the OAuth2 State Parameter](#validating-the-oauth2-state-parameter)
+
+**Authentication** is the process of verifying the user’s identity typically through an initial login and subsequently by verifying a unique secret identifier on each HTTP request made by the user’s browser.
+
+**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
+### Require Multi-Factor Authentication for Sensitive Applications
+###### Description
+
+During login, the user should be prompted for at least one second factor of authentication for sensitive services. Sensitive services typically include, but are not limited to: administrative panels, services that handle PII or payment information, and flagship service.
+###### Why We Care
+
+By adding multiple layers of verification we can ensure that a user’s account is not compromised, especially for sensitive applications and services. This will ensure in the case where a password (the most common initial factor of authentication) is not enough to compromise a user’s account.
+###### How to Fix?
+
+Contact the appropriate identity provider to be used at Unity, and require 2FA if needed.
+###### Risk Rating
+
+Medium
+
+---
+### Limit OAuth2 Scope by the Principle of Least Privilege
+###### Description
+
+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. 
+###### Risk Rating
+
+Medium
+###### References
+
+- https://tools.ietf.org/html/rfc6819#section-3.1.1
+
+--- 
+### Limited Token Lifetimes
+###### Description
+
+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.
+###### 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.
+###### Risk Rating
+
+Medium
+
+---
+### Validating OAuth2 Redirect URIs
+###### Description
+
+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.
+###### 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.
+###### How to Fix?
+
+Validate the entire URI against a whitelist of known valid URIs. Avoid using regular expressions or substring matching.
+
+###### Examples:
+
+_Good Example:_
+
+    def validate_redirect_uri(redirect_uri):
+        if redirect_uri == "https://newservice.unity3d.com/validate_oauth" :
+            return True;
+        return False;
+
+_Bad Example_
+
+    def validate_redirect_uri(redirect_uri):
+        if "unity3d.com" in redirect_uri:
+            return True;
+        return False;
+
+
+###### Risk Rating
+
+High
+
+---
+### Validating the OAuth2 State Parameter
+###### Description
+
+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 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. By ensuring that the user has initiated the OAuth2 flow, they will be performing actions within their account with known permissions.
+###### 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.
+###### Risk Rating
+
+Low
+###### References
+
+- https://tools.ietf.org/html/rfc6819#section-3.6