Security guide

README.md

@@ -10,7 +10,7 @@ If you're a visitor and want to use them, feel free to use them anywhere, but we
 
 We have decided to make this handbook publicly available so we can share as much as we can with other companies out there, potential candidates and prospective clients alike. Everyone is welcome!
 
-# Sections
+## Sections
 
 1. [First day at MarsBased](/sections/firstday.md)
 1. [Company culture](/sections/companyculture.md)
@@ -25,12 +25,12 @@ We have decided to make this handbook publicly available so we can share as much
 1. [Talks & Podcasts](/sections/talks.md)
 1. [Benefits & Perks](/sections/benefits.md)
 1. [Holidays, Time off & Paid leave](/sections/holidays.md)
-2. [Travel policy](/sections/travelpolicy.md)
-3. [Buddy System](/sections/buddy.md)
+1. [Travel policy](/sections/travelpolicy.md)
+1. [Buddy System](/sections/buddy.md)
 1. [Careers at MarsBased](/sections/careers.md)
-2. [Become a Martian](/sections/become-a-martian.md)
+1. [Become a Martian](/sections/become-a-martian.md)
 
-# Our guides
+## Our guides
 
 For now, we have the following resources available:
 
@@ -41,7 +41,7 @@ For now, we have the following resources available:
 1. [Our blogging guide](/guides/blogging-guide.md)
 1. [How to write a damn good blog post](/guides/how-to-blog.md)
 
-# Our development guides
+## Our development guides
 
 1. [Our Rails ActiveRecord guide](/guides/development/activerecord-guide.md)
 1. [Our Docker guides](/guides/development/docker-guide.md)
@@ -50,13 +50,14 @@ For now, we have the following resources available:
 1. [Angular guidelines](/guides/development/angular-guidelines.md)
 1. [Angular 17 guidelines](/guides/development/angular-17-guidelines.md)
 1. [React guidelines](/guides/development/react-guidelines.md)
-2. [Back-end guidelines](/guides/development/back-end-development-guidelines.md)
-3. [Code reviews guidelines](/guides/development/code-reviews-guidelines.md)
-4. [Coding guidelines](/guides/development/coding-guidelines.md)
-5. [Ruby & Rails guidelines](/guides/development/ruby-guidelines.md)
-6. [WIP: Testing guidelines](/guides/development/testing-guidelines.md)
+1. [Back-end guidelines](/guides/development/back-end-development-guidelines.md)
+1. [Code reviews guidelines](/guides/development/code-reviews-guidelines.md)
+1. [Coding guidelines](/guides/development/coding-guidelines.md)
+1. [Ruby & Rails guidelines](/guides/development/ruby-guidelines.md)
+1. [WIP: Testing guidelines](/guides/development/testing-guidelines.md)
+1. [WIP: Security guidelines](/guides/security/README.md)
 
-# Other useful resources
+## Other useful resources
 
 1. <a href="https://marsbased.com" title="MarsBased website" target="_blank">MarsBased website</a>
 1. <a href="https://marsbased.com/blog" title="MarsBased blog" target="_blank">MarsBased blog</a>
@@ -65,6 +66,6 @@ For now, we have the following resources available:
 1. <a href="https://marsbased.us7.list-manage.com/subscribe/post?u=1ab50c539712be36367b96b98&amp;id=89db0a6312" title="MarsBased newsletter" target="_blank">MarsBased newsletter</a>
 1. <a href="https://www.youtube.com/@MarsBased" title="MarsBased YouTube channel" target="_blank">MarsBased YouTube channel</a>
 
-# Contributing
+## Contributing
 
 We encourage you to contribute! Please check out the [Contributing guides](./CONTRIBUTING.md) for guidelines about how to proceed.

guides/security/3rd_party_software_integrations.md

@@ -0,0 +1,7 @@
+# 3rd Party Software Integrations
+
+We should regularly review integrations with 3rd party software and remove any unneeded services or integrations. In particular:
+
+- **Slack integrations**: Any Slack integration that is not needed anymore should be removed. This is particularly important for integrations with client projects. It is common to have error tracking or monitoring tools send alerts to a MarsBased Slack channel. When we stop working with a client or using a tool we should remove the corresponding integrations.
+- **Github integrations**: Similarly we might have Github integrations. A typical example is an integration with Netlify or Render to be able to deploy automatically from GitHub pull requests. Sometimes client projects are hosted in repositories in the MarsBased GitHub account. It is especially important to keep those clean because the client has no control over them.
+- **Linear integrations**: We usually connect Linear boards with GitHub or a similar service. Since Linear is a tool we used at the MarsBased level we should disconnect it once we stop working with a client or stop using the service. If we add additional integrations to Linear we should keep them clean in the same way.

guides/security/README.md

@@ -0,0 +1,28 @@
+# Security Guidelines
+
+## Personal Security
+
+Good security practices start on yourself and your own devices (laptop, mobile phone, etc.). Any device you use to do MarsBased work needs to be properly protected to minimize the chances of a bad actor accessing the device data.
+
+- [Protect Yourself](protect_yourself.md)
+- [Protect Your Devices](protect_your_devices.md)
+
+## Web Application Security
+
+It is crucial to keep the web applications we work on as secure as possible. Even the smallest vulnerability, if exploited in the right way, can be disastrous for a client. Therefore, applying good security practices to the web applications we develop for clients (and even internal applications for MarsBased) is of the utmost importance.
+
+- [Web Application Security Features](web_application_security_features.md)
+- [Common attack vectors](common_attack_vectors.md)
+- [Admin panel protection](admin_panel_protection.md)
+- [User accounts protection](user_accounts_protection.md)
+- [Cookies best practices](cookies_best_practices.md)
+- [Security related headers](security_related_headers.md)
+- [Periodical Maintenance Tasks](periodical_maintenance_tasks.md)
+- [Securing backups](securing_backups.md)
+
+## MarsBased security
+
+There are some cross-client aspects we need to take into account at company level to make sure we minimize the exposure of MarsBased or clients projects and data.
+
+- [3rd Party Software Integrations](3rd_party_software_integrations.md)
+- [Off-Boarding](off_boarding.md)

guides/security/admin_panel_protection.md

@@ -0,0 +1,11 @@
+# Admin panel protection
+
+Most applications have an administration panel. The administration panel is the most sensitive part of an application because it usually allows performing all sorts of actions and modifications that regular users can't do.
+
+It is critical to protect it properly:
+
+- It is strongly recommended to make Two-factor authentication mandatory for all admin users.
+- Consider hiding the admin panel behind a VPN. Only users connected to the VPN will be able to open the admin panel.
+- Consider hosting the admin panel in a subdomain different from the public application domain. This alone prevents some forms of attack, like stealing the cookies from the public site to log in to the admin panel.
+- Considering placing the admin panel in a hard-to-guess path different to /admin. And, of course, don't include any reference to it in the robots.txt or sitemap.xml files.
+- Consider adding roles to users with different permission levels. If a user account gets compromised but only has limited permissions, the harm will be reduced.

guides/security/common_attack_vectors.md

@@ -0,0 +1,69 @@
+# Common attack vectors
+
+There are multiple ways a web application can be exploited. These are some of the most common attack vectors your application should be protected from:
+
+## Protect against Cross-Site Scripting (XSS)
+
+Cross-Site Scripting, most commonly known as XSS, is one of the most prominent attack methods on web applications.
+
+It consists of injecting an arbitrary script on a page. When another user is browsing the page, it will execute the script. The script could do anything: modify the user cookies, trigger a request on the user's behalf, copy some sensitive data and send it elsewhere, redirect the user to another site, etc.
+
+Any element on a page that renders user input data is susceptible to being vulnerable to XSS attacks.
+Even SVG files can be a vector for XSS if not handled carefully. While using an SVG as an `<img src="...">` is generally safe (scripts inside won't execute), injecting raw SVG content into the DOM via `innerHTML` or `dangerouslySetInnerHTML` can execute embedded scripts or malicious elements like `<script>`, `<image onerror>`, or `<foreignObject>`. Always sanitize SVG content before injecting it into the DOM.
+### Mitigation
+
+There is no single technique to protect against XSS. Protection is achieved by following some best practices:
+
+- When showing plain text, HTML-escape all user input: replace the HTML input characters _&_, _"_, _<_, and _>_ by their uninterpreted representations in HTML (_\&amp;_, _\&quot_;, _\&lt;_, and _\&gt;_)
+
+- When showing HTML, sanitize all user input: Use a white-listing technique to only allow a handful of safe HTML tags: _&lt;p&gt;_, _&lt;span&gt;_, _&lt;b&gt;_ , _&lt;i&gt;_, etc. And equally important: sanitize all attributes on these tags. Only allow a handful of safe attributes: _class_, _id_, etc. If you need to allow style attributes for example, make sure to properly sanitize them. They can be used to perform [CSS injection attacks](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/05-Testing_for_CSS_Injection).
+
+- On the front-end, avoid rendering user input as HTML: avoid the usage of jQuery's _html()_ as much as possible. Use _text()_ instead. Similarly, avoid using _innerHTML =_  unless you are sure the content is properly sanitized.
+
+- [Implement a strict Content Security Policy (CSP)](web_application_security_features.md#implement-a-strict-content-security-policy-csp)
+
+⚠️ IMPORTANT: When sanitizing HTML avoid using a black-listing technique. It's impossible to list all possible tags that can be used for malicious purposes. An attacker will always know the one that you don't know about.
+
+## Protect against SQL Injection
+
+SQL injection is another common way of attacking a web application. It consists of exploiting a database query that interpolates user input data without sanitizing it. It gives an attacker the chance to execute any arbitrary query on the database.
+
+ℹ️ SQL injection used to be a very popular attack methodology and pretty easy to exploit, especially in the PHP days. Fortunately, frameworks have matured a lot since then and it's now very difficult to find SQL injection vulnerabilities.
+
+### Mitigation
+
+Make sure to always sanitize user-inputted data before using it in a query. The specific details of how to do it depend on each database engine. However, you will rarely need to do this manually. Most ORM frameworks protect against SQL injection by default when used in the right way. Check each framework-specific documentation to learn how to build safe queries.
+
+Another measure that can help lower the impact of an SQL injection attack, in the event of happening, is to restrict as much as possible the permissions of the database user being used by the application. Make sure the database user used by the web application has only the necessary permissions.
+
+## Protect against Headers injection
+
+When using the values of HTTP headers in your application, take into account that headers can be easily modified by an external party. Headers are just a part of an HTTP request and they can be changed in the same way as the query parameters or the body of the request can be changed.
+
+A common case is an application that uses the value of the _Host_ header to render URLs on the page or in e-mails. Since the _Host_ header can be manipulated to contain a malicious hostname, the application might be including links to the malicious site.
+
+Another less common but very dangerous scenario is when including a request parameter or other user-inputted data in a header. The user could introduce a carriage return to include any other malicious headers in the request or even two carriage returns to send an arbitrary response, hiding the real response from the server. [The Rails security guide](https://edgeguides.rubyonrails.org/security.html#header-injection) is a great resource to find more details on this type of attack.
+
+### Mitigation
+
+Always validate or sanitize the value of the headers before using them in a way that can be harmful to the application or the user.
+
+Most web application frameworks include a set of default measures to prevent header injection attacks. But you still need to be diligent when modifying the value of response headers or including your own headers.
+
+## Protect against Session Fixation
+
+Session Fixation is a type of attack that only affects applications that store the user session in the database.
+
+The common way to execute it is by exploiting an XSS vulnerability. The attacker injects a script that modifies the session ID stored in the cookies, by replacing it with the same session ID that the attacker is using.
+
+This forces the user to log in again. When done so, both the user and the attacker will be logged in as the user because they are both using the same session ID.
+
+### Mitigation
+
+When storing sessions in the database, always reset the session after every login. This will generate a new ID and invalidate the malicious ID that the attacker injected.
+
+### Implementation
+
+#### Rails
+
+Call the _reset_session_ method after login. When using [Devise](https://github.com/heartcombo/devise) this is done automatically.

guides/security/cookies_best_practices.md

@@ -0,0 +1,14 @@
+# Cookies best practices
+
+Cookies are stored in the browser. They are used to persist some state across page requests. Most commonly we store the user session in cookies, but there could also be some settings for the page like the theme, or other pieces of data.
+
+⚠️ Because cookies are stored in the browser, they are easily manipulated by the user.
+
+Take these precautions when working with cookies:
+
+- **Always add the Secure flag to cookies.** This instructs the browser to only send the cookies to the server when using an HTTPS connection. This avoids these cookies from being read by a third party sniffing the network.
+- **Add HttpOnly flag when access from Javascript is not needed.** This instructs the browser to disallow Javascript to read the contents of the cookie.
+- **Add the SameSite=Lax flag when possible.** This prevents some types of CSFR attacks and still allows cookies to be sent when users click on links.
+- **Encrypt the session cookie.** The session cookie is the most sensitive cookie because it authenticates the user. By encrypting it we prevent it from being read even if a malicious party is able to access it.
+- **Avoid storing sensitive data in cookies.** Use IDs of records stored in the database and fetch those records server-side.
+- Similarly, - **don't rely only on data in the cookies.** Always validate it server-side or retrieve it from the database using an ID.

guides/security/off_boarding.md

@@ -0,0 +1,20 @@
+# Off-Boarding
+
+When a team member stops working on a project and when we stop working with a client altogether we should take some clean-up steps. This is important to make sure we no longer have access to the client's code and data.
+
+## Martian off-boarding
+
+When off-boarding a martian from a project we should:
+
+- Remove all the user accounts from services used in the client's projects (Sentry, NewRelic, etc.). A good source to identify them is the client 1password vault.
+- Remove the user from the Github repository.
+- Remove the user from the 1password vault.
+
+## Client off-boarding
+
+When off-boarding a client we should make sure to:
+
+- Remove all the service accounts owned by MarsBased (Sentry, NewRelic, etc.). A good source to identify them is the client 1password vault.
+- Remove all martian accounts from services owned by the client.
+- Review all items in the client 1password vault. For each of the items, think if some other actions are required (remove an account, remove a certificate from a server, etc.)
+- Remove the client 1password vault.