[BUG] Turn twitter cards off by default to avoid security issues

[shankari]

• replace the result of pip list | grep dash below

dash                      2.9.3
dash-auth                 2.0.0
dash-bootstrap-components 1.4.1
dash-core-components      2.0.0
dash-extensions           0.1.13
dash-html-components      2.0.0
dash-table                5.0.0

• if frontend related, tell us your Browser, Version and OS

  • OS: OSX
  • Browser Firefox
  • Version 102.10

Describe the bug

Deploying a dash app with pages allows attackers to embed code into the webapp. This is a potential security vulnerability since it allows attackers to execute arbitrary code in the context of the dash sandbox.

Concretely, if use_pages is true, dash calls self._pages_meta_tags()

dash/dash/dash.py

Line 968 in a8b3ddb

if self.use_pages:

which always adds the twitter and og meta tags

dash/dash/dash.py

Line 906 in a8b3ddb

<meta property="twitter:card" content="summary_large_image">

The twitter meta tag includes the URL

            <!-- Twitter Card data -->
            <meta property="twitter:card" content="summary_large_image">
            <meta property="twitter:url" content="{flask.request.url}">
            <meta property="twitter:title" content="{title}">
            <meta property="twitter:description" content="{description}">
            <meta property="twitter:image" content="{image_url}">

So if the dash app is involved with a URL that includes a <script> tag, the script specified in the tag will be executed.

Example URL

[dash_app_base_url]/?'"--></style></scRipt><scRipt>netsparker(0x000F45)</scRipt>

This causes our dash app to fail cyber security/pen testing scans.

A workaround is to a custom index_string which removes all meta tags, but that has the disadvantage of not including any meta tags, even the ones that we might want.

A better option would be to make the twitter and og meta tags opt-in; it is not clear that specifying a twitter card is necessary for all deployers.

I am happy to submit a PR (include_card_configs property) if that would help

Screenshots

---

Vulnerability report

---

Page source includes the embedded script

---

Example of an embedded alert in firefox

[alexcjohnson]

Thanks @shankari! I think we can address the security concern by calling html.escape on the url - and in fact seems like we should do that on everything that goes into any of the <meta> tag attributes. So that would be here and in format_tag

If we can address this security flaw and you still want the ability to skip these meta tags I'd rather make them opt-out rather than opt-in, as they're fairly low overhead and they're a nice touch in various places you might post links to your app.

[shankari]

@alexcjohnson I have a workaround for this now, so I will see if one of my summer interns can work on this when they get started in a month or so. If not, I will see if I can spend a Friday working on it.

[alexcjohnson]

@shankari we believe #2540 will remove any possibility of this vulnerability, however even before that we've been unable to reproduce the problem. In every flavor we've tried flask.request.url is already url-encoded when it gets to us. Can you say more about your environment that might help us figure out what's going on? Flask/Werkzeug versions, are you running anything in front of this like gunicorn, are you doing anything else unusual like setting up your own Flask app and giving it to Dash?

[shankari]

@alexcjohnson we are also an open source project, so you should be able to clone https://github.com/e-mission/op-admin-dashboard and use the docker-compose files to reproduce.

I just re-tried and was able to reproduce with the following steps:

$ git checkout da9d8f8ba71f44a3eb081862a2eefae2dab04a66
$ docker-compose -f docker-compose-dev.yml build
$ docker-compose -f docker-compose-dev.yml up -d

Then, copy-paste ?'"--></style></scRipt><scRipt>alert(0x000F45)</scRipt> after the http://localhost:8050
I can't put in the link directly because GitHub URL encodes it

An alert pops up (see screenshot below)

To answer your specific questions:

• as you can see from https://github.com/e-mission/op-admin-dashboard/blob/master/requirements.txt, flask==2.2.5
• Nothing in front of it - we install gunicorn but don't actually use it since we have an ngnix reverse proxy in front on production. But we can reproduce this on dev as well.
• no fancy flask stuff (see https://github.com/e-mission/op-admin-dashboard/blob/master/app_sidebar_collapsible.py)