30歳からのプログラミングスマートフォン用の表示で見る30歳からのプログラミング30歳無職から独学でプログラミングを開始した人間の記録。対しては「属性」というものを設定することができる。生存期間を指定したり、送付先の制限を行ったりすることが可能になっている。属性のひとつであるSameSiteは、正しく使うことでセキュリティ対策やプライバシー保護に大きな効果を発揮する機能である。他の属性に比べると若干複雑で、しかも比較的新しい属性ということもあって、今のところそれほど普及していない。有用な機能であることは間違いないし、後述するように一部のブラウザベンダはSameSiteの利用を促す方針を明確にしている。今後はSameSite属性を積極的に活用していくべきだろう。どのように動作するのかを見ていき、その運用方法について考えていく。基本的な仕組みや機能については、こちらを参照。6265というドキュメントで定められているが、SameSite属性については記述されていない。SameSiteはまだドラフトで、仕様を策定している段階だからだ。6265bisの内容を参照しながら話を進めていく。6265の改訂版のドラフトで、SameSiteについても記述してある。リクエストに自動的に付与されることである。明示する必要なく、予めサーバから渡しておいたデータをリクエストに含めてくれる。これが大きな利便性を生む反面、問題も生み出してきた。不適切な投稿やパスワードの変更など)が行われたり、個人情報が不当に収集されたりしてきた。仕組みを悪用した攻撃に対してウェブアプリケーション側も当然対策を行っており、その知見がネットや書籍で共有されている。それらはどうしても、対症療法的なものにならざるを得なかった。送信」が発生することを前提とし、そのリクエストの正当性をチェックするというのが基本的なアプローチになる。具体的な方法はここでは説明しないが、トークンの付与やプリフライトリクエストの利用などがよく使われる。プリフライトリクエストによる対策については以前ブログに書いた。送信」をそもそも発生させないようにする、というのがSameSite属性の特徴である。SameSiteを設定するだけであらゆる攻撃を防げるわけではもちろんないが、適切に使えばそれだけで大きな効果を得ることができる。StrictLaxNone指定方法は他の属性と同様にSameSite=設定値なので、例えばStrictを指定する場合は以下のようになる。SameSite=StrictSameSite属性を設定しなかった場合、もしくはStrictかLax以外の値を指定した場合は、Noneとみなされる。明示的にNoneを指定することもできるし、可読性から考えてもそのほうがよいだろう。月にリリース予定のバージョン80から、この挙動が変わる。SameSite属性なし、もしくはStrictかNone以外の値を設定した場合は、Laxとして扱うようになる。明示的にNoneを指定した場合にのみNoneとして扱われるようになり、さらにNoneの使用に対して独自の制限を設ける。方針については、この記事の後半で詳しく説明する。SameSite属性に設定した値と、リクエストの種類。付与するかどうか判断するというのが、SameSite属性の機能である。付与しよう、という具合に判断していく。送信を行わない、より安全なウェブアプリケーションを構築することが可能になる。付与するかどうか判断しているか。ここからは、そのルールを理解するために重要となるいくつかの概念を説明していく。遠回りに思えるかもしれないが、まずはこれらの概念を理解しておくことで、実際のブラウザの挙動やコードが理解しやすくなる。cross-siteまず最初に理解しておきたいのは、same-siteとcross-siteという概念である。これはリクエストを、それがどこから発生したのかによってsame-siteもしくはcross-siteのいずれかに分類するというもの。ドメインが同じであればsame-siteであり、ドメインが異なればcross-siteとなる。http://a.com/topにあるリンクを踏んでhttp://a.com/menuに移動する場合、同じa.comというドメインからhttp://a.com/menuに対するリクエストが発生しているため、これはsame-siteである。http://b.com/topにあるリンクを踏んでhttp://a.com/menuに移動する場合は、b.comという異なるドメインからhttp://a.com/menuに対するリクエストが発生しているので、cross-siteとなる。オリジンではなくドメインで判断するので、注意する。http://a.com/からhttps://a.com/mypageにリクエストが発生する場合は、プロトコルが違うのでオリジンは異なるが、ドメインはどちらもa.comなので、これはsame-siteになる。入力することで発生したリクエストも、same-siteとなる。ブラウザ外からページを開いた場合も、same-siteである。https://a.com/mypageというコマンドを実行すると、ブラウザでhttps://a.com/mypageを開くが、このリクエストもsame-siteとして扱われる。基本的にはsame-siteからのリクエストは比較的安全であり、SameSite属性もそれを前提に設計されている。含めるかどうかが、論点となる。メソッドリクエストが安全なものであるかどうかは、メソッドによってもある程度は判断できる。GETは、対象となるリソースに変更を加えないため、POSTやDELETEに比べて安全と言える。つのメソッドをsafeなメソッドとして定義している。7231の内容に準拠して、これらのメソッドをsafeなものとして扱っている(5.3.7.1)。ルール上そうなっているという話であり、開発者がこのルールを守らずにGETでリソースの変更を行うようなウェブアプリケーションを作っていれば、そのアプリケーションにおいてはGETは安全とは言えなくなる。当たり前の話だが、SameSite属性の設定だけを頑張っても、他の部分が雑な作りになっていれば台無しになってしまう。Navigationであるかも、リクエストの安全性を測る基準のひとつになる。Navigationの明確な定義は見当たらなかった。siteとする」という記述はあった(5.2.1)。Navigationなのだと思われる。後述する検証結果も、それを裏付けるものだった。Navigationである。実行され、そのコードにfetch('http://b.com/')と書かれていた場合、http://b.com/へのリクエストは発生するが、アドレスバーの表示はhttp://a.com/のままである。Navigationではない。アドレスバーの表示を基準にするのは、多くのユーザーはアドレスバーに表示されている内容によって、今自分がどのサイトにいるか判断するためである。一般的なユーザーにとって、そのサイトを信頼するかどうかを判断するために使える唯一の材料が、アドレスバーなのだと言える。アドレスバーの表示が一致する動作は、一般的なユーザーの直感とも一致している。アドレスバーに反映されないような動作は、リクエストが行われたことにユーザーが気付かない可能性が高く、意図しない操作が行われてもそれを認識できない恐れがある。付与するかどうか判定している。具体的には以下の通り。Strictの場合、same-siteでは常に付与する。cross-siteでは常に付与しない。Laxの場合、same-siteでは常に付与する。Navigationかつメソッドがsafeのときにのみ、付与する。Noneの場合、same-siteでは常に付与する。cross-siteでも常に付与する。表にまとめると次のようになる。◯StrictとNoneはシンプルであり、分かりづらいのはcross-site時のLaxだけである。そのためここからは、cross-site時の実際の挙動を確認していく。つを使って、動作確認した。72.0.2どのブラウザでも同じように動き、ブラウザによる差異はないことを確認した。注意すべき事項もあるので、それについては適宜説明していく。ファイルなので、これに以下の内容を追加する。sub.localhostこれで、localhostの他にsub.localhostを使えるようになった。つのドメインを用意することにする。続いて、http://localhost:8080/のコードを書く。