search

splunk-soar-connectors / .github

Stores default community health files for the organization
Apache License 2.0
1 stars 7 forks source link

Threatstream API Authentication Deprecation #125

Open ed4wg opened 2 weeks ago

ed4wg commented 2 weeks ago

Name of the app Threatstream

Describe the bug The Threatstream connector is using a deprecated form for authenticating to the Threatstream API. It is passing the creds in the URL instead of in the headers.

Anomali Threatstream will no longer support auth through URL params as of July 15 2024. This will break the use of this connector without a fix.

See: https://github.com/splunk-soar-connectors/threatstream/blob/next/threatstream_connector.py#L408

Expected behavior Use headers to auth instead of passing the creds in the URL.

Splunk SOAR Version (please complete the following information):

alexa-phantom commented 1 week ago

Hi @ed4wg , thank you for letting us know. We will look into it.

ishans-crest commented 1 week ago

Hi @ed4wg

Thanks for helping us with this, do you have any link to deprecation note from Anomali?

ed4wg commented 1 week ago

Hi @ishans-crest

Here is what they shared.

As part of our ongoing commitment to maintaining the highest standards of security and privacy, we are writing to inform you of an important upcoming change that may affect your API integrations to the Anomali APIs. Effective July 15th, 2024, we will be removing support for passing API keys in the URL. This has been deprecated since February 2023, and will now no longer be supported.

Why Are We Making This Change? Passing API keys in URLs is generally considered a bad practice for several critical reasons:

  1. LessSecure: URLs can be logged in various places such as server logs, browser history, and intermediary proxies, potentially exposing the API key.
  2. Easier to Accidentally Expose: URLs can be shared accidentally, for example, in screenshots or by copying and pasting.
  3. Caching Risks: If the URL is cached by a browser or proxy, the API key can be inadvertently stored in the cache.

Best Practices for API Key Security To mitigate these risks, we will now only support passing API keys in the header, because: ● More Secure: Headers are less likely to be logged and are not exposed in browser history or server logs. ● Better Practices: Many security best practices and frameworks recommend using headers for authentication tokens because they are designed to be used for secure data transmission. ● Controlled Access: Headers can be managed more precisely, ensuring that the key is only sent where necessary and not exposed in client-side code. By adhering to these practices, you can significantly enhance the security of your API keys and protect your applications from unauthorized access and potential breaches.

What Do You Need to Do?

Please ensure that all your applications are updated to stop including API keys in URLs and start using HTTP headers or other secure methods by July 15th, 2024. ...