mistercrunch commented on PR #33550:
URL: https://github.com/apache/superset/pull/33550#issuecomment-2902440861

   I want to highlight some of the security concerns and mitigation mechanisms. 
   
   - Object metadata can be sensitive in some contexts: just noting that a 
dashboard can be titled `Next Earning Calls: Crushing it!!!!` and that's 
potentially sensitive, also paired with the fact that we use autonumber ids, an 
attacker could essentially fetch a list of dashboard / chart titles on a 
Superset instance
   - Public instances: if/when an instance is public, this is even more 
sensitive - thinking of Preset here or any internet-visible instance
   - Superset in-VPN: assuming the user is in some sort of VPN, Slack should be 
able to call and unfurl through that same VPN, maybe that's where this feature 
is "ok", where someone could decide that dashboard names are public within 
their network (?) Still somewhat dubious... Users might not know that while 
creating a new dashboard.
   - RBAC concerns: currently Superset only shows you charts/dashboards that 
are accessible by you, meaning `Next Earning Calls: Crushing IT!!!!` could be a 
hazard even internally: knowing about the existence of a specific dashboard 
title could be an issue within the VPN walled garden
   
   Given that:
   - Slack app + impersonation (solving for RBAC concerns) seems required for 
most environment
   - About creating a public/insecure endpoint that serves logged off metadata: 
maybe a feature flag could mitigate this configuration for instances that 
consider dashboard names public within their VPN. Flag should come as `false` 
by default and come with a clear disclaimer
   - About squeezing metadata in headers, totally fine by me, but Slack won't 
see them, though it's a pre-req building block for the Slack app to work. Say 
if you build your own Slack app, you'll need that and there's no arm in adding 
those meta tags today.
   
   About the Slack app:
   - probably needs to be aligned with your auth mechanism? so if you use 
oauth, or username/password or Okta or whatevs, the Slack app might be 
different, probably hard to build one that works for everyone
   - if anything, an open source implementation as a reference for the 
community would be great. Ideally lives outside of the main repo


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to