Protect celery-progress endpoint

Close #379 (closed)

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.

aleksis/core/migrations/0016_taskuserassignment.py

+# Generated by Django 3.2 on 2021-05-09 10:55
+
+from django.conf import settings
+import django.contrib.sites.managers
+from django.db import migrations, models
+import django.db.models.deletion
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('sites', '0002_alter_domain_unique'),
+        ('django_celery_results', '0008_chordcounter'),
+        migrations.swappable_dependency(settings.AUTH_USER_MODEL),
+        ('core', '0015_oauth_permissions'),
+    ]
+
+    operations = [
+        migrations.CreateModel(
+            name='TaskUserAssignment',
+            fields=[
+                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
+                ('extended_data', models.JSONField(default=dict, editable=False)),
+                ('site', models.ForeignKey(default=1, editable=False, on_delete=django.db.models.deletion.CASCADE, to='sites.site')),
+                ('task_result', models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to='django_celery_results.taskresult', verbose_name='Task result')),
+                ('user', models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to=settings.AUTH_USER_MODEL, verbose_name='Task user')),
+            ],
+            options={
+                'verbose_name': 'Task user assignment',
+                'verbose_name_plural': 'Task user assignments',
+            },
+            managers=[
+                ('objects', django.contrib.sites.managers.CurrentSiteManager()),
+            ],
+        ),
+    ]