fix: enhance disallowed SQL functions list for improved security

[sha174n]

SUMMARY

This PR expands the list of disallowed SQL functions in the DISALLOWED_SQL_FUNCTIONS configuration to improve security when using PostgreSQL, MySQL, SQLite, MS SQL Server and Clickhouse. It adds several functions that could potentially expose sensitive system information when used in SQL queries.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

• Set up a local instance of Superset with the modified code
• Manual testing in SQL Lab by attempting to execute queries using the newly disallowed functions
• Verify that the query is blocked and an error message appears

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[korbit-ai]

I've completed my review and didn't find any issues.

Files scanned

​

File Path	Reviewed
superset/config.py	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Need a new review? Comment /korbit-review on this PR and I'll review your latest changes.

Korbit Guide: Usage and Customization

Interacting with Korbit

• You can manually ask Korbit to review your PR using the /korbit-review command in a comment at the root of your PR.
• You can ask Korbit to generate a new PR description using the /korbit-generate-pr-description command in any comment on your PR.
• Too many Korbit comments? I can resolve all my comment threads if you use the /korbit-resolve command in any comment on your PR.
• On any given comment that Korbit raises on your pull request, you can have a discussion with Korbit by replying to the comment.
• Help train Korbit to improve your reviews by giving a 👍 or 👎 on the comments Korbit posts.

Customizing Korbit

• Check out our docs on how you can make Korbit work best for you and your team.
• Customize Korbit for your organization through the Korbit Console.

Current Korbit Configuration

General Settings

​

Setting	Value
Review Schedule	Automatic excluding drafts
Max Issue Count	10
Automatic PR Descriptions	❌

Issue Categories

​

Category	Enabled
Documentation	✅
Logging	✅
Error Handling	✅
Readability	✅
Design	✅
Performance	✅
Security	✅
Functionality	✅

Feedback and Support

• Tell us what you think of Korbit
• Schedule a call with our team
• Email us @ [email protected]

Note

Korbit Pro is free for open source projects 🎉

Looking to add Korbit to your team? Get started with a free 2 week trial here

[rusackas]

Glancing at the list (and the failing tests) I worry this might be too restrictive. CC @mistercrunch @dpgaspar

[michael-s-molina]

I think we need to be really careful about the potential of breaking things in this change. +1 to @rusackas's comment.

[dpgaspar]

Glancing at the list (and the failing tests) I worry this might be too restrictive. CC @mistercrunch @dpgaspar

don't think failing tests are related to this: https://github.com/apache/superset/pull/30134/files#r2038270948

[mistercrunch]

Guessing master was broken at the time of branch creation, please rebase.

About the feature, I'm not sure whether/how we should be in the business of disabling SQL functionality for security purposes. I think where I'd draw the line is in areas where a SQL feature can compromise the integrity of the OS and Superset instance itself. I don't see any issue with current_schema for instance, it's a useful feature AFAIC, not a security concern - unless I'm missing somehting.

Also noting that much of these database features can be disabled at the database user account level. Seems good DBA hygiene is key here, not BI tool stewardship.

Now. Here we're modifying a local config setting, so it's designed to be managed/altered at the environment level. You can do this on your envrionment today. It can certainly be good to prevent certain things that we know are bad. "secure by default" is great, though I wouldn't want to provide the impression that it's Superset's responsibility to secure your database or give the impression of a false sense of safety from it. It's not scalable for us (and I imagine for other BI tools) to be on top of all the potential security issues different database engines may expose.

In any case, whatever we decide here, those are breaking changes and would need an entry in UPDATING.md

[michael-s-molina]

In any case, whatever we decide here, those are breaking changes and would need an entry in UPDATING.md

If there are breaking changes, they need to go into 6.0.

[dpgaspar]

In any case, whatever we decide here, those are breaking changes and would need an entry in UPDATING.md

If there are breaking changes, they need to go into 6.0.

The problem here is that, many of these function simply can't be turned off at the database level, regarding Superset's responsibility I agree, but let's talk

[mistercrunch]

Fine with "setting up more secure defaults", especially given this is configurable locally, so if you want to enable pg_sleep in your instance you can.

One more thing, it'd be great to validate the error message / UX here, make sure we're clear that "Using the function {...} has been disabled in your environment for security reasons {...} see with your superset administrator for more details {...}". What do we currently surface to the user?

[sha174n]

Right now we're showing the following message:
"SQL statement contains disallowed function(s): {'inet_client_addr', 'query_to_xml', 'table_to_xml', 'table_to_xml_and_xmlschema', 'version', 'inet_server_addr', 'query_to_xml_and_xmlschema', 'database_to_xml'}".

I agree a more descriptive message would be a good idea, definitely.

[mistercrunch]

Definitely should only show the term used that is not allowed. Otherwise LGTM apart from the failing unit tests, maybe rebase would help here.

[michael-s-molina]

• Can we make the PR title more accurate? It's not only MySQL that is being affected.
• Can we add a note in UPDATING.md about the breaking changes?
• This can only be merged during a breaking window. I added this PR to the 6.0 project board.