Protect celery-progress endpoint #2240
No reviewers
Labels
No labels
Security
TeX
auto-update
board
done
board
ready
board
todo
check
delete-eslint-rc-js
check
update-builddeps-package-json
check
update-eslint-rc-js
check
update-gitignore
check
update-merge-request-template
check
update-prettier-ignore
check
update-pyproject-toml
check
update-renovate-json
check
update-tox-ini
part
backend
part
ci
part
docs
part
frontend
part
i18n
part
non-technical
part
packaging
prio
1
prio
2
prio
3
release-mr-5.x
size
large
size
medium
size
small
source
customer
source
customer::fsmw
source
customer::fss
source
customer::teckids
source
downstream
type
breaking
type
bug
type
feature
type
refactoring
workflow
blocked
workflow
confirmed
workflow
current-todo
workflow
discussing
workflow
new-app
workflow
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
aleksis/AlekSIS-Core!2240
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/protect-celery-progress"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Close #379
Security advisory
Summary
We use Celery to run tasks asynchronously in the background. Sometimes there are scenarios that users start tasks in the frontend (e. g. a data import) and want to track the progress. For this case, we use celery-progress. celery-progress provides an unprotected API endpoint to allow the frontend JavaScript to refresh the displayed progress bar. Every user, even such who are not logged in, could call this API endpoint for every task.
How could the issue be exploited?
To get information from the API endpoint, an attacker would need a valid task ID. He could get one from an authorized user or by guessing. Iterating is not possible because the task IDs are UUID-like.
What information can be leaked?
In general, status information about tasks like SUCCESS, FAILURE or RETRY don't contain any personal information. But there are sometimes scenarios that custom progress/error messages are also exposed through this API. These messages could include personal information like "Importing the user Jane Doe failed ...".
How does the change fix the issue?
The changed code will link the corresponding user to each task whose progress should be tracked. By wrapping the default endpoint, we check if the user is logged in, and if the currently logged-in user is linked to the provided task ID. If the user isn't permitted to see the status, the endpoint will return a 404. This will also prevent fetching data for tasks that shouldn't be tracked through the frontend.
Is there general advice on how to prevent such issues in the future?
Every team member should check newly added views from third-party libraries if they have a sufficient, integrated authentication mechanism. Generally, adding new apps to the URLconf should be considered carefully. Maintainers should ask the developers in the review if they checked these points.
mentioned in commit
1263e457c8