Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • funkwhale funkwhale
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 407
    • Issues 407
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 15
    • Merge requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • funkwhalefunkwhale
  • funkwhalefunkwhale
  • Issues
  • #678
Closed
Open
Issue created Jan 24, 2019 by Agate@agateMaintainer

Ensure we are not vulnerable to BREACH attack

My understanding is that we need all of the following conditions to be true for the attack to be an issue:

  1. Response body contains sensitive information an attacker may want to guess
  2. Response body contains a user given string (such as a search param)
  3. HTTP compression is on

Since Funkwhale is an SPA, most of the UI is made of static content. Item 1 is not checked for this resources and we should be able to keep HTTP compression on.

Now, Funkwhale API do contain sensitive data. However, I cannot think of any endpoint that includes sensitive data (1) and user input (such as a search param) in response body. I have to admit this could change in the future though.

Django's admin (/api/admin) is a much more traditionnal web app and may be vulnerable though, since it contains lots of sensitive data (although CSRF were secured with https://code.djangoproject.com/ticket/20869), and possible user input (via search params).

Suggested mitigation:

  • Disable HTTP compression for json content
  • Disable HTTP compression for admin urls

If anyone wants to give feedback advice on this, you're welcome :)

Links:

  • http://breachattack.com/
  • https://security.stackexchange.com/questions/172581/to-avoid-breach-can-we-use-gzip-on-non-token-responses
  • https://code.djangoproject.com/ticket/20869
  • https://github.com/YunoHost/yunohost/pull/356
Assignee
Assign to
Time tracking