回答編集履歴

2

一部撤回

2023/11/26 00:23

投稿

ikedas
ikedas

スコア4443

test CHANGED
@@ -35,7 +35,7 @@
35
35
  public void addContentDisposition(HttpHeaders headers, String fileName)
36
36
  throws UnsupportedEncodingException {
37
37
  String headerValue = String.format(CONTENT_DISPOSITION_FORMAT,
38
- UriUtils.encode(fileName, StandardCharsets.UTF_8.name()).replace("\"", "%22"));
38
+ UriUtils.encode(fileName, StandardCharsets.UTF_8.name()));
39
39
  headers.add(HttpHeaders.CONTENT_DISPOSITION, headerValue);
40
40
  }
41
41
  }
@@ -44,5 +44,4 @@
44
44
  ```
45
45
  Content-Disposition: attachment; filename*=UTF-8''%E3%82%B5%E3%83%90%E3%82%A4%E3%83%96.csv
46
46
  ```
47
- なお、`UriUtils.encode()`の仕様がよくわからなかったのですが、ファイル名に`"`が含まれていてもエンコードされなかったりしないでしょうか。もしもそうならReflected file downloadという攻撃への脆弱性につながるため、念のためエンコードした形に置換しています (参考:「[Content-Disposition の filename という地雷](https://brutalgoblin.hatenablog.jp/entry/2023/01/05/190150)」([原文](https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md)))。
48
-
47
+ ~~なお、`UriUtils.encode()`の仕様がよくわからなかったのですが、ファイル名に`"`が含まれていてもエンコードされなかったりしないでしょうか。もしもそうならReflected file downloadという攻撃への脆弱性につながるため、念のためエンコードした形に置換しています (参考:「[Content-Disposition の filename という地雷](https://brutalgoblin.hatenablog.jp/entry/2023/01/05/190150)」([原文](https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md)))。~~ 考えすぎでした。`filename*`形式のみ使う場合は問題なさそうなのでこの点は撤回します。ただエンコードが適切かどうかは精査して再度手を加えるかもしれません。

1

typo, small fix

2023/11/25 06:32

投稿

ikedas
ikedas

スコア4443

test CHANGED
@@ -24,7 +24,7 @@
24
24
  Content-Disposition: attachment; filename="サバイブ.csv"; filename*=UTF-8''%E3%82%B5%E3%83%90%E3%82%A4%E3%83%96.csv
25
25
  ```
26
26
 
27
- 元々は、Content-Dispositionヘッダフィールドのfilenameパラメータを[RFC 62622](https://datatracker.ietf.org/doc/html/rfc6266)に準拠するようエンコードする意図があったはずです。ところが2015年当時、RFC 6266に非準拠だったユーザエージェントも救うために、filenameフィールドを重複させてエンコードなしとエンコード済みの両方を含めるというバッドノウハウを提案した人がいたようです (「[ねぎぶログ: ダウンロードファイル名、文字化けとの格闘](https://web.archive.org/web/20150718020406/http://www.negimiso.net/blog/2015/06/19/%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D%E3%80%81%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91%E3%81%A8%E3%81%AE%E6%A0%BC%E9%97%98/)」)。これがその後Qiitaやteratailで無批判にコピペされることが繰り返され、バッドノウハウであるという情報は抜け落ちたまま広まったと考えられます (コピペ例 [1](https://qiita.com/kazuki43zoo/items/36b4dc0f13f1434e490c) [2](https://qiita.com/t-iguchi/items/75c879fc9a3423c511cb ) [3](https://teratail.com/questions/222421))。
27
+ 元々は、Content-Dispositionヘッダフィールドのfilenameパラメータを[RFC 6266](https://datatracker.ietf.org/doc/html/rfc6266)に準拠するようエンコードする意図があったはずです。ところが2015年当時、RFC 6266に非準拠だったユーザエージェントも救うために、filenameフィールドを重複させてエンコードなしとエンコード済みの両方を含めるというバッドノウハウを提案した人がいたようです (「[ねぎぶログ: ダウンロードファイル名、文字化けとの格闘](https://web.archive.org/web/20150718020406/http://www.negimiso.net/blog/2015/06/19/%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%90%8D%E3%80%81%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91%E3%81%A8%E3%81%AE%E6%A0%BC%E9%97%98/)」)。これがその後Qiitaで紹介されてQiitaやteratailで無批判にコピペされることが繰り返され、バッドノウハウであるという情報は抜け落ちたまま広まったと考えられます (コピペ例 [1](https://qiita.com/kazuki43zoo/items/36b4dc0f13f1434e490c) [2](https://qiita.com/t-iguchi/items/75c879fc9a3423c511cb ) [3](https://teratail.com/questions/222421))。
28
28
 
29
29
  今では事実上全てのユーザエージェントがRFC 6266準拠の動作をするはずですから、今さら10年近く前に提案されたバッドノウハウに頼る必要はないでしょう。素直にRFC 6266通りのエンコードをすればいいです。
30
30
  ```java