XSSすればCookie内のSession IDを知らずとも攻撃できる
Session IDをCookieで取り扱うのは安全か？という話
XSSがある場合、Cookieに入れていても攻撃が可能になる
tl;dr
XSSがあった場合に、
ちゃんと指定すれば、Cookieの内容は攻撃者には伝わらない
しかし、Cookie内のSession Idなどを使ったrequestは実行できる
そもそもの攻撃者の意図は、
Session IDを取得すること、ではない
Session IDを取得することは、その先の別の目的のための手段に過ぎない
例えば、
userのpasswordを任意に変更する
userの個人情報を得る
etc.
Cookieのoptionなどを厳格にしている場合でも、XSSがあれば
たしかに、Cookie内のSession IDを取得することは防がれるが、
その先の目的は達成できてしまう
そのため、Session IDをCookieで取り扱うのは安全かという問いは、否、となる
Set-Cookie HeaderにはsecureにCookieを扱うために以下のような属性がある
指定したHost自身とそのsub domainに対してのrequestのみCookieを付与する
HTTPSなどのsecureな通信経路を使用した場合にのみCookieを付与する
JSからCookie内のデータにアクセスできなくする
requestの発行元と、宛先がSameSiteである場合にのみCookieを付与する
こういった属性を正しく使おうとも、XSSがある場合は攻撃できる
攻撃の例
userになりすまして、passwordを変更する攻撃を行う
この動画でも同じ例が使われている
登場人物と前提
攻撃対象サイトS
XSSできる脆弱性がある
Set-Cookieの属性は厳格になっている
被害者A
Sの利用者で、既にSにloginしている状態である
つまり、Session IDがCookie内に入っている状態である
攻撃者X
Aのpasswordを、例えば
hoge に変えたいXは、SにXSSを仕込んだサイトを用意し、Aに訪問させる
訪問した瞬間に、Sに対して、passwordを
hoge に変更するrequestが投げられる攻撃完了
Xは、Session IDの具体的な値を知らないが、Aがlogin状態であることを利用して攻撃ができた
XSSなので、「passwordを変更するreqeust」は、正規のサイトSからserverに送られる
これは、SameSite
これは、browserが勝手にCookieを付与する
Set-Cookie: HttpOnlyがあっても無意味
通信経路が、secureだとかは無関係
要は、XSS攻撃が可能な攻撃者はそもそもCookieの中身のSession IDを欲しがらない
Session Hijackingをしようとしない
具体的なSession IDを奪取することが、攻撃の割に合わない
Sessionが切れていたら使い物にならない
>The most obvious reason is that XSS attacks, although could be targeted, are not instant, like traditional buffer overflow attacks where the attacker point the exploit to a remote location and gain access right away. For an XSS attack to be successful, sometimes it is required a certain period of time to pass until the victim opens a link or do something else. ref
the attacker point the exploit to a remote location and gain access right away の部分の意味がわからない #??参考
HttpOnlyを指定してもXSSがあれば危険であることを知っておこうねという主張
実例があってわかりやすい