ghsa-94mf-xfg5-r247
Vulnerability from github
Published
2019-07-16 00:52
Modified
2024-09-23 16:00
Summary
Invenio-App vulnerable to host header injection attack
Details

APP_ALLOWED_HOSTS not always preventing host header injection

Impact

A possible host header injection attack have been identified in Invenio-App. For an attack to be possible, all conditions below must be met:

  1. Your webserver must have been configured to route all requests to your application.
  2. You must have relied on APP_ALLOWED_HOSTS configuration variable to whitelist allowed host headers.
  3. Flask's request.host must not have been evaluated during request handling.

An example of a view which does not evalute request.host is a simple view using just url_for to generate an external URL (similar is possible when rendering just a Jinja template):

python @app.route('/') def index(): return url_for('index_url', _external=True)

This happens, because Werkzeug's trusted host feature, which APP_ALLOWED_HOSTS rely on, does not check the the list of trusted hosts in it's routing system that url_for is relying on.

Patches

Invenio-App v1.0.6 and v1.1.1 fully fix the issue.

Note, we strongly recommend (see Securing your instance) that you never route requests to your application with a wrong host header. The APP_ALLOWED_HOSTS configuration variable exists as an extra protective measure because it is easy to misconfigure your web server to allow requests with any host header.

Workaround 1 - Configure your webserver

You should ensure that you never route requests with a wrong host header to your application. The workaround depends on which web server you are using to proxy requests to your application. In general it involves ensuring that the web server has two virtual hosts defined:

  1. Default virtual host: a dummy default virtual host that by default is used unless the webserver can match the host header to another virtual host (i.e. a catch-all).
  2. Application virtual host: the application virtual host responsible for proxing requests to the application, and configured to only reply to a whitelist of host headers.

Note, for instance in Nginx if you only configure the application virtual host, by default, it will also act as the default virtual host despite you having configured a whitelist of host headers.

Below is an example for Nginx. Note for clarity we have only included the virtual host for port 443, but this also extends to virtual hosts running on any other port. ```

etc/nginx/nginx.conf

http { # ... include /etc/nginx/conf.d/*.conf; } ```

Default virtual host

Notice, the server_name is _ and the listen directive has it marked as default_server.

```

etc/nginx/conf.d/default.conf

server { listen 443 default_server; listen [::]:443 default_server; server_name _;

# ...

return 301 https://www.example.com; } ```

Application virtual host

Notice, the server_name is set to the host header whitelist.

```

etc/nginx/conf.d/app.conf

server { listen 443; listen [::]:443; server_name www.example.com;

# ... } ```

Workaround 2 - Include application snippet

We strongly recommend that you use the method described in Workaround 1.

If you are not able to upgrade to the patched versions of Invenio-App, you can include the following code snippet in your application to force evaluation of request.hosts.

python @app.before_request def before_request(): request.host

For more information

If you have any questions or comments about this advisory: * Email us at info@inveniosoftware.org

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "invenio-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "1.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.1.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2019-1020006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:27:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## APP_ALLOWED_HOSTS not always preventing host header injection\n\n### Impact\nA possible host header injection attack have been identified in Invenio-App.  For an attack to be possible, all conditions below must be met:\n\n1. Your webserver must have been configured to route all requests to your application. \n2. You must have relied on ``APP_ALLOWED_HOSTS`` configuration variable to whitelist allowed host headers.\n3. Flask\u0027s ``request.host`` must not have been evaluated during request handling.\n\nAn example of a view which does not evalute ``request.host`` is a simple view using just ``url_for`` to generate an external URL (similar is possible when rendering just a Jinja template):\n\n```python\n@app.route(\u0027/\u0027)\ndef index():\n    return url_for(\u0027index_url\u0027, _external=True)\n```\n\nThis happens, because Werkzeug\u0027s trusted host feature, which ``APP_ALLOWED_HOSTS`` rely on, does not check the the list of trusted hosts in it\u0027s routing system that ``url_for`` is relying on.\n\n### Patches\nInvenio-App v1.0.6 and v1.1.1 fully fix the issue. \n\nNote, we strongly recommend (see [Securing your instance](https://invenio.readthedocs.io/en/latest/deployment/securing-your-instance.html#allowed-hosts)) that you never route requests to your application with a wrong host header.  The ``APP_ALLOWED_HOSTS`` configuration variable exists as an extra protective measure because it is easy to misconfigure your web server to allow requests with any host header. \n\n### Workaround 1 - Configure your webserver\n\nYou should ensure that you never route requests with a wrong host header to your application. The workaround depends on which web server you are using to proxy requests to your application. In general it involves ensuring that the web server has two virtual hosts defined:\n\n1. **Default virtual host**: a dummy default virtual host that by default is used unless the webserver can match the host header to another virtual host (i.e. a catch-all).\n2. **Application virtual host**: the application virtual host responsible for proxing requests to the application, and configured to only reply to a whitelist of host headers.\n\nNote, for instance in Nginx if you only configure the application virtual host, by default, it will also act as the default virtual host despite you having configured a whitelist of host headers.\n\nBelow is an example for Nginx. Note for clarity we have only included the virtual host for port 443, but this also extends to virtual hosts running on any other port.\n```\n# etc/nginx/nginx.conf\nhttp {\n  # ...\n  include /etc/nginx/conf.d/*.conf;\n}\n```\n\n**Default virtual host**\n\nNotice, the ``server_name`` is ``_`` and the ``listen`` directive has it marked as ``default_server``.\n\n```\n# etc/nginx/conf.d/default.conf\nserver {\n  listen 443 default_server;\n  listen [::]:443 default_server;\n  server_name _;\n\n  # ... \n\n  return 301 https://www.example.com;\n}\n```\n\n**Application virtual host**\n\nNotice, the ``server_name`` is set to the host header whitelist.\n\n```\n# etc/nginx/conf.d/app.conf\nserver {\n  listen 443;\n  listen [::]:443;\n  server_name www.example.com;\n\n  # ...\n}\n```\n\n### Workaround 2 - Include application snippet\n\nWe strongly recommend that you use the method described in Workaround 1.\n\nIf you are not able to upgrade to the patched versions of Invenio-App, you can include the following code snippet in your application to force evaluation of ``request.hosts``.\n\n```python\n@app.before_request\ndef before_request():\n    request.host\n```\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [info@inveniosoftware.org](mailto:info@inveniosoftware.org)",
  "id": "GHSA-94mf-xfg5-r247",
  "modified": "2024-09-23T16:00:53Z",
  "published": "2019-07-16T00:52:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/inveniosoftware/invenio-app/security/advisories/GHSA-94mf-xfg5-r247"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1020006"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-94mf-xfg5-r247"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/inveniosoftware/invenio-app"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/invenio-app/PYSEC-2019-24.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Invenio-App vulnerable to host header injection attack"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…