脳log[20221028]

2022年10月28日 (金) 「[B! security] フォーム入力支援やサイト最適化サービスの改ざんについてまとめてみた - piyolog」■ブコメで「サブリソース完全性」について知った。関連>20220520。だけどこれ活用が難しいよね。ハッシュ値が提示されていなくて検証できません、というケースがほとんどだろうから。もちろん正しくやりたいところが正しくやる手段が用意されているのはいいことだけど、閲覧者の視点から正しさや完全性を求めると、やっぱりアクセス先とは異なるドメインから来るリソースは基本的に拒否することになる。それができるのは偏屈な人間だけだから、あいだをとって、検証できない外部リソースは基本的に拒絶されますよ、という世界が訪れることがあるだろうか。あと別のブコメが、スクリプトが読み込むスクリプトが改ざんされたら integrity 属性も役に立たないだろうと書いている。まあ、そうだよね。それだけの自由と信用を Web ページは埋め込む外部スクリプトに付与しているということだ。というか形式から言っても連帯責任のごとく一体のものと見なすのが妥当だと思うので、外部スクリプトが仮になにか悪さや粗相をしたらすべての責任がまず Web ページをサーブした者に生じると考えていいのでは。これは理想世界での事後の話。現実世界で事前にできることは。無責任の連鎖に巻き込まれたくないので自分はスクリプトを許可しないわけです。それで壊れるサイトには近寄らないのです。いつでもそうできるといいね！■■■「オリジン間リソース共有 (CORS) - HTTP | MDN」を読んだ。いくつかシナリオがあるっぽい。一番単純なケースでは、リソースをホストしているサーバーが Access-Control-Allow-Origin ヘッダを使うことで外部からの使用可否をコントロールできるっぽい。しかし、しかしだね、そもそもの目的がリソースただ乗りの制御にあるのではなくて、同一オリジンへのリクエストだけを許されたスクリプトに抜け穴を提供するために用意されたように見える。ブラウザは img タグなどを含むすべての外部リソースについて Access-Control-Allow-Origin を確認しているのだろうか。Web はいつの間にかそのようなものになっていたのだろうか。もちろん違うはずで、抜け道に対して「オリジン間 HTTP リクエストのリスクの緩和に役立てています」とはどういう皮肉か。■きっかけはこのツイートだったんだけど、「@chokudai AtCoder の API に Access-Control-Allow-Origin など CORS 指定がないのにはなにか理由があるのでしょうか？ これがあれば、有志ウェブサイトが AtCoder の API を叩くためだけに Heroku などに依存する必要がなく、GitHub Pages などでの静的ホスティングが可能になると思うんですが…」、Heroku を利用することで何がどう可能になるのかがまだわかっていない。難しいね。Heroku の無料プランがなくなるんだっけ？ そうすると有志ウェブサイトは何ができる？