Security best practices for browser PubSub

[ModalityZ]

When using PubSub in a browser with unauthenticated users, there is a higher risk of Denial of Service attacks and scripted abuse of the client in the browser. Does AWS have suggested practices to reduce these risks?

For example, putting API Gateway between the browser and the IoT endpoint would provide rate-limiting. But perhaps rate-limiting is already part of the endpoint?

To minimize scripted abuse, such as fuzzing, would a service like GuardDuty be able to detect some abuse?

[bretambrose]

That question is way beyond our expertise set here. My not-very-helpful response would boil down to: "if you're worried about unauthenticated user abuse, don't use an unauthenticated workflow." To the best of my undestanding, Cognito has plenty of support for various popular web authentication approaches.

[ModalityZ]

I appreciate your response, but I agree it's not viable for services that by design do not require users to create logins. For example, privacy laws like US HIPAA require that no more personally-identifiable information is to be collected than is necessary for the basic operation of the service. So I'm looking for ways of providing the user with good security while also respecting their privacy by not requiring their email address (which would be needed to reset a password if a login is required).

[ModalityZ]

Let me ask a narrower question: Is it possible to limit browser clients to subscribe to only one topic (that they create themselves, such as a page-generated UUID) while allowing a server to subscribe to all topics?

I have looked through all the policy examples starting at https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html#pub-sub-policy-cert but the policy syntax seems not to allow restricting in this way.

The reason one would want to restrict in this way is to prevent someone from greasemonkey'ing a browser client into subscribing to all topics and thereby eavesdropping on other sessions.

[bretambrose]

Assuming you mean the exact same code, just running in a different environment (but same identity pool) and requiring no way for a "browser" app to spoof a "server" app, then no, I'm not aware of any way to do that. The two different applications require fundamentally different permissions.

[ModalityZ]

Let's not assume it's the same code nor the same identity pool. What becomes possible as a solution?

…

On Fri, Feb 2, 2024, 8:32 PM Bret Ambrose ***@***.***> wrote: Assuming you mean the exact same code, just running in a different environment (but same identity pool) and requiring no way for a "browser" app to spoof a "server" app, then no, I'm not aware of any way to do that. The two different applications require fundamentally different permissions. — Reply to this email directly, view it on GitHub <#414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJXV3HXY2CYBGIEKHANZPTYRUWMXAVCNFSM6AAAAAA3MSEIYWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGNBZG4ZDG> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>

[bretambrose]

Well, in that case, it seems like you could give the server application a fixed identity with its own expanded set of permissions that would cover all that you needed. If we're talking an internal web app, you'd probably want an authenticated identity pool.

[ModalityZ]

This would be a public browser-based offering. I think authentication doesn't help because it would be easy to get a login in order to then eavesdrop on all other sessions by subscribing with a wildcard at an unwanted part of the topicfilter (using something like greasemonkey to override any restriction we put in our browser client). Is there any way to do custom authorization in our IoT Core endpoint to reject any browser-based attempt to subscribe using a topicfilter that doesn't match a regex?

…

On Mon, Feb 5, 2024, 8:15 PM Bret Ambrose ***@***.***> wrote: Well, in that case, it seems like you could give the server application a fixed identity with its own expanded set of permissions that would cover all that you needed. If we're talking an internal web app, you'd probably want an authenticated identity pool. — Reply to this email directly, view it on GitHub <#414 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJXV3FFN7E4NRC2BUSZVWLYSEOTBAVCNFSM6AAAAAA3MSEIYWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGNZTG42DO> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>