CSPを突破するnode-bitmap-proxyの原理を説明し
たいyuki_minoh.icon
node-bitmap-proxy
yuki_minoh.iconが実装しているサービス？の説明をします
と思ったが/public-minaph/node-bitmap-proxyの安全性についてですでに書いていたのでそっちをみてもらったほうが早いかも
全然明確な書き方になってなくて完全にメモなのでちょっとアレですyuki_minoh.icon
2021/10/9 17:42yuki_minoh.icon
/js-fetch-proxy/ScrapboxのUserScriptは、なぜ外部リソースを読み込めな（い/かった）のかでかなりわかりやすく説明できたっぽい
/js-fetch-proxy/node-bitmap-proxyとかもどうぞ
外部サーバーの準備は必要になりますが、送受信情報を全て画像に埋め込んでやり取りすることで、外部との通信がほぼなんでも可能になります
簡単にいうと、https://my.proxy.server/url/https://target.urlみたいなsrcを画像に設定して、返ってきた画像から通信情報を読み出します
ブラウザ→自前のサーバー→目的のサーバー→自前のサーバー（ここで画像にエンコード）→ブラウザ（画像から読み込み）
データを画像に変換して通信するとは……その発想はなかったtakker.icon
めちゃくちゃ強引だw
なんだかんだ他の形式でも通信できると思うんで、極言すればCSPのconnect-srcの制約は、CSPの各項目の「最小の制約」と一致するんだと思いますyuki_minoh.icon
今回は img-src がワイルドカード*指定なので、connect-srcも実質ワイルドカード制約
実際CSSのコメント欄に情報を書き込んで送付とか普通にできそうだし、真実っぽい
/public-minaph/CSPのconnect-srcは、セキュリティとしてはほとんど意味がないにちょっと書いた
現状、CSPの突破自体はすでに実行できていて、あとは利便性の向上のためにtodoがいくつか
API keyなどの秘匿情報をUserScriptに書けるようにする（事前に暗号化する仕組みを導入する）
一連の通信を関数に包んで、使いやすくする
長いpostメッセージにも対応できるようにする
従来のブラウザ拡張機能を使ったやり方と比べると、「誰かがサーバーをセットアップさえすればみんな使える」という点が長所です
例えば「井戸端からのアクセスは許可」とかでサーバーをセットアップすればOK
スマホユーザーも恩恵を受けられます
Scrapboxが画像のCSPを制限しない限りは、今後も有用なアプローチのはず。。。
ちなみに今僕yuki_minoh.iconがちょっと忙しいので、完成は少し先です
2021/10/06yuki_minoh.icon
仕様の決定で迷うところがあったので、発展させてjs-fetch-proxyというのを作り（提唱し？）ました
ブラウザでのリクエストを、プロキシサーバーで代理実行する、というコンセプトです
画像通信は脇役にしちゃいました