脳log[20190714]

2019年07月14日 (日) Firefox 68 から、同じディレクトリにあるローカルファイル同士が同一オリジンだとは見なされなくなったらしい。「Local files can no longer access other files in the same directory.」たいへん困っている。file プロトコルでアクセスしていたディレクトリを wwwroot とするローカルHTTPサーバーを立てる、たいへんにばかばかしい対処しか思い付かない。なんで余計な仲介者を加えることで問題が問題でなくなるのかさっぱりわからない。■「なんだかんだ HTMLは孤立していて使えないし、IEはそれを補完して使えるやつだったし(TDCもそうだし src属性を持つ xmlタグもそう)、Firefoxも使える。Google Chromeはローカルリソースがまったく読み込めなくて使い道がない。」と書いていたわけだが、とうとう Firefox が Google Chrome の仲間入りをしたということだ。■Fx68の何が不都合かというと、XSLT に外部からパラメータを与えて可変性を持たせたくても URL を通してはできないから、JavaScript で XSLTProcessor を操作することでそれを行っていた。こんな感じ>`var XSLT = function(XML, XSL, Prm) { var GET = function(URL) { var Req = new XMLHttpRequest(); Req.open("GET", URL, false); Req.send(null); return Req.responseXML; }; var Proc = new XSLTProcessor(); Proc.importStylesheet(GET(XSL)); for (var p in Prm) { Proc.setParameter(null, p, Prm[p]); } return Proc.transformToDocument(GET(XML)); }; var Doc = XSLT("./a.xml", "./a.xsl", {FILTER:location.search.slice(1)});` こういうスクリプトが埋め込まれた HTML ファイルと、XML ファイルと XSL ファイルの３つが同じディレクトリにあったとしても、`GET(XSL)` と `GET(XML)` が失敗するようになった。http サーバーを経由して各ファイルにアクセスしなければいけなくなった。■たとえば IE がやったように、`<xml src="./a.xml" />` と書かせてくれるなら XMLHttpRequest でローカルファイルを読み出そうとすること(そして拒絶されること)はなかった。あるいは URL を通して XSL 変換にパラメータを渡せるなら HTML+JavaScript 自体が不要だった。不遇な規格である。

本日のツッコミ(全4件)

♭ beru 2019年07月21日 (日) 03:36 JST

https://lwn.net/Articles/793453/ https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730 という事で危険性はありそうな気はします。野良ファイルのスクリプトが勝手に外部に送信出来ちゃう事自体が危ない気がしますがこの思想を突き詰めるとアーミッシュのような生活を送る事に…。 about:config で security.fileuri.strict_origin_policy を false に変えれば対処出来るかもです（試してない）。

♭ ds14050 2019年07月21日 (日) 18:13 JST

ペンギンロゴのやりとりとCVEは読んでいました。Android か、と。 添付ファイルをダウンロードフォルダに保存して開いたならそれはユーザーの手の内のできごとだし、Firefox が保存場所を決めるなら一時ディレクトリに添付HTMLごとに個別のサブディレクトを掘ればいいわけで、Android でユーザーに安全な選択肢がなくてもそれは Android の問題だし、Firefox が進んで使用者を子供扱いする使えない道具になろうとしているようで残念なのです。 about:config は試してみる価値がありそうですが、個人PC一台のことではないので動作条件を狭めるようで気が進みません。そう考えるとローカルサーバーを立てる対策は Firefox 以外のブラウザに対応するコストとして自分を納得させられそうです。[[20190308]]の時点でローカルWebサーバーはもう立っているので、今はそこに寄生しています。

♭ beru 2019年07月25日 (木) 00:41 JST

セキュリティの事を深く考えずに保存したHTMLファイルを開くユーザーは無くならないと思います。 保存時に個別にサブディレクトリを自動生成する方法は自分も考えましたが、Androidの場合はそれで良いとしてもPCの場合にはファイルダイアログでファイル名を決めて保存する手順なので勝手にサブフォルダを作ってそこに保存する動きをするとユーザーから変なアプリだと思われそうです。 思いついた案としてはデフォルトでは禁止しておいて、ユーザーが設定画面で設定したローカルのファイルにだけ許可するというのはどうだろうか？と思いましたが、多分面倒な事は回避してとにかく安全側に倒して禁止にしたんでしょうかね。。 Google Chrome だとコマンドラインで --allow-file-access-from-files 付きで起動すればXHRでローカルのファイルを読めますが、事前に起動済みのChromeのインスタンス(プロセス)を閉じておかないと駄目だったりします。あとこのやり方も結局セキュリティを下げてしまうので運用に注意が必要で…。 まぁローカルWebサーバーを素直に使うのが良いんでしょうね。 任意のHTMLファイルをお手軽にElectronアプリのexeに変換するソフトとか探せばあるかもしれないですが…。

♭ ds14050 2019年07月25日 (木) 08:29 JST

IE でははるか昔から「インターネットオプション」を通してマイコンピュータやイントラネットなどのゾーン別にスクリプトを禁止したりのセキュリティを設定できますね。 それをやらないで明らかになるのが想定ユーザーの変化・食い違いであって、==馬鹿==すべてのあり得るユーザーを想定するにしても、禁止ではなく誘導でなんとかしてほしいものです。