Protect DSN behind a scope or app certificate to avoid events/releases from bots and reverse engineered apps

[marandaneto]

Related to https://github.com/getsentry/sentry-java/issues/2825 and https://getsentry.atlassian.net/browse/ISSUE-1628

1. The DSN could accept only events from a specific signature configured either when creating the project on sentry.io or later. 1.1 This is mobile-friendly but it won't work for non-Mobile apps most likely. 1.2 This won't be unified across other platforms.

2. The DSN has only the scope to report events but not really to create releases automatically. 2.1 This will force people to use sentry-cli and create releases via CI or plugins, which today is totally optional for some platforms. 2.2 This won't prevent events to be sent, noise is still there.

3. Add project setting on Sentry to opt-out of DSN/SDK-based on-demand release creation - https://github.com/getsentry/sentry/issues/49854 3.1 As a first quick win, can limit this to "opt out of on demand release creation when events are sent" 3.2 Later we can make this more fine-grained, e.g. control which actions (create release via CLI, upload source maps, send event, etc.) can create release on demand

There are probably more alternatives.

We already report if the app was installed from an official store or not, but this is not enough.

Not doing this means that:

• People can fire events to a specific DSN and mess up the release health data.
• Cause a lot of noise in the issues stream by automatically sending events (bots, reverse-engineered apps)
• Create a lot of weird releases by automatically sending events

[Dhrumil-Sentry]

I heard this feedback from another customer too- they were wondering why is Sentry creating releases for builds they don't care about and they don't create those releases via the CLI so it was our SDKs creating such releases automatically.

Having an opt-out of DSN/SDK-based release creation may be a good option here. I wonder if Sentry detects releases being created by CLI should we stop creating other releases automatically for the project?

[danielkhan]

Related: https://github.com/getsentry/sentry/issues/49854

Having an opt-out of DSN/SDK-based release creation may be a good option here.

I agree with @Dhrumil-Sentry - could we add an option "Disable automatic release creation for this DSN" to /settings/projects/<project>/keys/?

[marandaneto]

While the above suggestion is a good first step (Option 2), it does not solve the issue entirely.

[danielkhan]

While the above suggestion is a good first step (Option 2), it does not solve the issue entirely.

But we can do it as a first step?

[markushi]

Adding some bits from some recent internal discussion

Maybe it’s worth mentioning that the app developer could manually send along the app signature as e.g. a tag (via Sentry.setTag()) and then verify if the signature is the expected one (by manually checking a single event). Lot’s of manual steps, but maybe still worth mentioning.

Apart from that DSNs can be rotated via project settings (by creating a new DSN and disabling the old one). If they combine that with e.g. some remote config for their mobile apps they could change the DSN on the fly.

[marandaneto]

Please keep in mind that some signatures can be read by just downloading the APK file such as https://github.com/warren-bank/print-apk-signature so independently of which option you all do, be sure to use the one that only the signed app has access to (at runtime).

There's also the risk of this signature being intercepted via MAN attack when sending the data to the network, consider that as well.

[sepbehroozi]

In my opinion, the Sentry Android/iOS SDK needs to pull some information (such as signature, bundle ID, package name, etc.) from the host app and send it with each request. On the dashboard, we could then whitelist certain package names (or bundle identifiers) for a particular DSN key. With this approach, I believe the problem of seeing events from irrelevant and cloned apps (apps with modified package names or bundle identifiers) and seeing lots releases that haven't been created by our original app could be solved.

Apart from that DSNs can be rotated via project settings (by creating a new DSN and disabling the old one). If they combine that with e.g. some remote config for their mobile apps they could change the DSN on the fly.

@markushi I am not a big fan of this approach because, at least on mobile apps, we have to wait for the remote config to be fetched and then start the Sentry SDK. This could potentially miss crashes that might happen during the early stages of app launch. In our case, we start the Sentry SDK as early as possible within the lifecycle of our apps.

[markushi]

@sepbehroozi thanks for the feedback! I agree, swapping the DSN should be a last resort approach.