Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://api.slack.com/authentication/best-practices below:

Best practices for security | Slack

Keeping credentials secure is important whether you're developing open source libraries and tools, internal integrations for your workspace, or Slack apps for distribution across workspaces.

Even if you're not working with OAuth 2.0 and user access tokens, consider the following recommendations when developing on the Slack platform.

As a Slack app developer, you'll be working with credentials issued to you from Slack, as well as token values representing members, workspaces, and specific features of your app.

1. Your Client ID is one piece of information used to identify your app, and frequently appears in OAuth negotiation URLs and other contexts. Your Client ID can be shared freely in code and email, and cannot be used alone to act on your app's behalf.

2. Your Client Secret should be treated delicately. It is how you securely identify your app's rights and identity when exchanging tokens with Slack. Do not distribute client secrets in email, distributed native apps, client-side javascript, or public code repositories.

These tokens represent specific access levels granted by the OAuth scopes you obtained.

Bot user tokens can connect to the Real Time Messaging (RTM) API and post messages on their own behalf. They can also access a subset of API methods to better understand the channels, members, and messages received as part of its activities.

User tokens, such as those received through the Add to Slack and Sign in with Slack flows are capable only of the permissions granted to it during the OAuth flow using scopes.

Store user and bot user tokens with care and never place them in a public code repository or client-side code such as Javascript.

Slack can limit use of your app’s OAuth tokens to a list of IP addresses and ranges you provide. Slack will then reject Web API method calls from unlisted IP addresses.

Restricting token use by IP address applies to token use against the Web API and the SCIM API for local or distributed apps. Allowed IP listing does not apply to incoming webhooks.

Once you provide a list of allowed IP addresses, Slack will ony accept a request to call Web API methods if it comes from one of those IP addresses. If the request matches your allowed list, Slack will execute the request and respond.

If the request originates from an IP address not listed in your allowed list, it will be rejected with the following response:

{
  "ok": false,
  "error": "invalid_auth"
}

To configure your allowed IP list:

1. Navigate to your application management and select the relevant app.
2. Select the OAuth & Permissions section from the left-hand navigation.
3. Find the Restrict API Token Usage section. This section lists all the Allowed IP Address Ranges you set up.
4. Click Add a new IP address range.
5. Enter the desired IP address range and click Add.
6. Select Save IP address ranges.

You can add up to 10 entries. Each entry specifies either a CIDR range of IP addresses or a single IP address. For example:

• Entering 101.101.101.106 will allow only that IP address, which we'll consider as 101.101.101.106/32.
• Entering a submask like 101.101.101.0/24 will allow all 256 IP address between 101.101.101.0 and 101.101.101.255.

"Local" IP addresses cannot be added to allowed lists, and IPv6 is not supported.

Slack also supports several ways to verify the authenticity of its requests to your app. Read more in the verifying requests from Slack documentation.

Read more about how to use token rotation for new and existing Slack apps.

Revoke tokens manually with the auth.revoke method.

Slack app-based incoming webhook URLs allow posting messages only to a specific channel configured by the approving member. Their identity is always tied to the app associated with the URLs, and cannot be used as arbitrary users or on unapproved channels.

Redirect URIs appear as URLs and are safe to be part of published code. However, ensure that the redirect URIs defined in a public app are limited only to domain names in your direct control.

We recommend that after you complete local development, you should remove localhost and related domains from your configuration list.

Storing authentication secrets is difficult, and how you do so depends on context, usage, and design requirements. While it would be great if all tokens were encrypted with individual keys controlled by the customers, most implementations do not allow that. Here are some things to consider when storing tokens to ensure we're doing everything we can to prevent accidental exposure or mix-up of usage.

• Do you need a token to make your functionality work? If not, err on the side of not storing any more customer secrets than you need to.
• Are you asking for a least-privilege token? Most apps need only perform a handful of actions with a token. Ensure you are requesting the most limited token authorization scopes possible to protect your customers in case of a breach.

The 7-Layer OSI model breaks out how apps and computers function over a network, and can provide a useful model for thinking about security at each layer.

The application layer is mostly focused on high-level APIs and how your app exposes itself to an end user. Here are some things to consider:

• Don't expose the token to the end user once it is stored in a database.
• Ensure there is no functionality that echoes back tokens (or any other customer secrets) to the user. Check error scenarios especially. Unless this is absolutely required, consider creating a middleware layer to facilitate the usage of a stored token without storing it within your app's code.
• Lock down the usage of your app itself to prevent misuse of the token.
• Think about OWASP Top 10 Web Vulnerabilities such as XSS, CSRF, and SQLi.
• Can an attacker abuse your app's functionality to gain access to a token, or trigger functionality that may be undesirable?
• Think about rate-limiting. Does your app utilize rate-limiting in a way that prevents misuse of a token? Spamming a token can potentially disable that token, leaving your integration in an erroneous state.
• Use a database to store tokens, and do not hard-code any tokens.
• Don't consume tokens via the query string of a URL via a GET request. Always use a POST request when transmitting secrets over HTTP.

• Store tokens in a way that directly links them to the owner (workspace and user).
• Ensure that if a user deletes their account, data, or integration, that you also delete that token from your production systems and backups.
• If you no longer have need for a customer's token, delete it immediately from all production systems and backups.
• Ensure that there is absolutely no way to expose one user's token (or the functionality of that token) to another user.
• Ensure that sessions on your app utilize best practices on session ID generation, and test for the ability of one session to know about or see the contents of another user's session. Ensure that any debug functionality for user impersonation does not exist in your app.

• Ensure you are using proper Transport Layer Security (TLS) to encrypt all traffic between you and the customer or you and the service you're using the token with to ensure the token is never transmitted unencrypted.
• Ensure you do not have any "Ignore SSL/TLS Errors" in your app's code.
• If you have a web-facing service, ensure that you do not have any mixed content, and that your certificate setup supports modern cryptographic standards. You can use Qualys' SSL Labs to help test for this.
• Once your app has knowledge of a user token, ensure that you are not logging it, or storing it in any way outside of your app's database.

These layers encompass most of the non-app-based internet plumbing, including protocols such as TCP, IPv4, MAC, and Ethernet. We're going to assume for safe token usage and storage that these layers are already secure; however, there are a few points to consider, especially if you are hosting in the cloud.

• If you are using a cloud provider to host your app, ensure that your account has Two-Factor Authentication (2FA) enabled, and that you are using strong passwords.
• Ensure that the only accounts with access to your production systems actually need that access.
• If you are backing up your data, ensure that you are storing it in a safe location. Unsecured backups are easy targets for attackers to steal most if not all of your app's data and secrets.
• If your app is not web-based, ensure that you are using recommendations for the platform it's running on for how to store secrets. You should never have an instance in which you are writing a token to disk in plaintext when there is a system keychain or other encryption mechanism available.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4