[4.0.x] Fixed CVE-2022-36359 -- Escaped filename in Content-Disposition header.

carltongibson · carltongibson · commit b7d9529cbe0a · 2022-08-03T08:48:00.000+02:00
Thanks to Motoyasu Saburi for the report.
diff --git a/django/http/response.py b/django/http/response.py
@@ -520,7 +520,9 @@ def set_headers(self, filelike):
             disposition = "attachment" if self.as_attachment else "inline"
             try:
                 filename.encode("ascii")
-                file_expr = 'filename="{}"'.format(filename)
+                file_expr = 'filename="{}"'.format(
+                    filename.replace("\\", "\\\\").replace('"', r"\"")
+                )
             except UnicodeEncodeError:
                 file_expr = "filename*=utf-8''{}".format(quote(filename))
             self.headers["Content-Disposition"] = "{}; {}".format(
diff --git a/docs/releases/3.2.15.txt b/docs/releases/3.2.15.txt
@@ -6,4 +6,10 @@ Django 3.2.15 release notes
 
 Django 3.2.15 fixes a security issue with severity "high" in 3.2.14.
 
-...
+CVE-2022-36359: Potential reflected file download vulnerability in ``FileResponse``
+===================================================================================
+
+An application may have been vulnerable to a reflected file download (RFD)
+attack that sets the Content-Disposition header of a
+:class:`~django.http.FileResponse` when the ``filename`` was derived from
+user-supplied input. The ``filename`` is now escaped to avoid this possibility.
diff --git a/docs/releases/4.0.7.txt b/docs/releases/4.0.7.txt
@@ -6,4 +6,10 @@ Django 4.0.7 release notes
 
 Django 4.0.7 fixes a security issue with severity "high" in 4.0.6.
 
-...
+CVE-2022-36359: Potential reflected file download vulnerability in ``FileResponse``
+===================================================================================
+
+An application may have been vulnerable to a reflected file download (RFD)
+attack that sets the Content-Disposition header of a
+:class:`~django.http.FileResponse` when the ``filename`` was derived from
+user-supplied input. The ``filename`` is now escaped to avoid this possibility.
diff --git a/tests/responses/test_fileresponse.py b/tests/responses/test_fileresponse.py
@@ -101,3 +101,38 @@ def test_repr(self):
             repr(response),
             '<FileResponse status_code=200, "application/octet-stream">',
         )
+
+    def test_content_disposition_escaping(self):
+        # fmt: off
+        tests = [
+            (
+                'multi-part-one";\" dummy".txt',
+                r"multi-part-one\";\" dummy\".txt"
+            ),
+        ]
+        # fmt: on
+        # Non-escape sequence backslashes are path segments on Windows, and are
+        # eliminated by an os.path.basename() check in FileResponse.
+        if sys.platform != "win32":
+            # fmt: off
+            tests += [
+                (
+                    'multi-part-one\\";\" dummy".txt',
+                    r"multi-part-one\\\";\" dummy\".txt"
+                ),
+                (
+                    'multi-part-one\\";\\\" dummy".txt',
+                    r"multi-part-one\\\";\\\" dummy\".txt"
+                )
+            ]
+            # fmt: on
+        for filename, escaped in tests:
+            with self.subTest(filename=filename, escaped=escaped):
+                response = FileResponse(
+                    io.BytesIO(b"binary content"), filename=filename, as_attachment=True
+                )
+                response.close()
+                self.assertEqual(
+                    response.headers["Content-Disposition"],
+                    f'attachment; filename="{escaped}"',
+                )
