こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
- 会の概要
- 会の様子
- 徳丸さんの講演
- Q&A
- WebサイトでCookieを取得する際はポップアップで通知等しないと違法になるか？
- CORSはAPIを守るというよりはブラウザサイドのSame-origin policyを迂回する仕組みという認識でいいか？
- セッション管理をしている限りはトークンの対策を行うということだがどういう対策があるのか？
- dangerouslySetInnerHTMLを使えば必ず脆弱になるのか？
- 今日の説明は開発者が理解できていないことが多いのだが、Webアプリケーション脆弱診断で可視化できるのか？
- 今日デモで使っていたツールは？
- dangerouslySetInnerHTMLを防ぐ施策を知りたい
- セキュリティが楽しくなったきっかけは？
- 会全体を通した感想
会の概要
以下、イベントページから引用です。
不正アクセスや情報漏洩をはじめとしたセキュリティインシデントが増加し続けており、それらを防ぐために、企業だけではなく一開発者としてもセキュリティの知識が求められています。昨今では、開発の中でもDevSecOpsなど、SaaSやサードパーティ製品利用における脆弱性をつくケースも増えています。
本イベントでは、徳丸 浩（@ockeghem）さんをお招きし、多様化するサイバー攻撃の対策や抑止のために必要な知識について、お話しいただく予定です。
会の様子
徳丸さんの講演
Cookieを巡る状況
Cookieの仕様は日々変わるものであるため一面のみの紹介になるという前提で、まずはSameSite属性の話がありました。
SameSite=None(旧来のデフォルト)を設定している場合、POSTとGET両方とも許可するため攻撃対象サイトのCookieを送信してしまうことになるため、注意が必要だという話でした。
また、Googleがサードパーティークッキーを段階的に廃止することを発表したという話がありました。元々のサードパーティークッキーはトラッキングに利用できる問題点があったため、あるサイトでセットされたCookieが他サイトのiframeにあった場合は送信されないように仕様変更があったそうです。
サードパーティークッキーは開発者泣かせであるものの、セキュリティ上は必ず対応してほしいということでした。
CORS
CORSはフレームワーク任せでセキュリティ上問題ないという風潮がありますがこれが間違っているという話がありました。
まず、Cookieを使う場合は、Access-Control-Allow-Credentials=trueとAccess-Control-Allow-Originには*以外で設定する必要があるという話がありました。(開発者がうっかり脆弱性を入れ込まないように冗長な書き方をする必要がある)
次に、具体的なフレームワーク上の問題として、Express.jsでrequire('cors')を設定するとどんな条件でもサイトを動かせるようになる話がありました。この設定は便利な反面、情報漏洩に繋がる設定でもあるため、セキュリティ上は明らかに好ましくないということです。
XSS
ReactでinnerHTML相当の機能を使う場合を例に、改行をbrタグに変換する処理で起こる脆弱性の話がありました。
簡単に書けるという理由から改行からbrタグへの変換を1行(1つの処理)でやりがちですが、JSXを活用して文字列を配列にした後に配列のまま表示するのが重要だということでした。
Q&A
講演の後はQ&Aがありました。以下、質問と回答を常体かつ一問一答形式で記載していきます。
WebサイトでCookieを取得する際はポップアップで通知等しないと違法になるか？
法律の専門家ではないので断定まではできないが日本ではならないはず。EUの規制対策ではやったほうが良い。トラッキングのためならやったほうがいいと思うがセッション管理のために必要ならポップアップを出さなくてもよいのでは？
CORSはAPIを守るというよりはブラウザサイドのSame-origin policyを迂回する仕組みという認識でいいか？
その通り。
セッション管理をしている限りはトークンの対策を行うということだがどういう対策があるのか？
伝統的には、APIあるいはCookieで乱数文字列を渡してinputのjsonにつける方式が多い。
dangerouslySetInnerHTMLを使えば必ず脆弱になるのか？
そうではない。例えば基をユーザがいじれない(テンプレートを選択するだけ)場合や、サニタイズしている場合などは脆弱ではない。ただ、サニタイズにも人が絡むので、「安全」の基準が間違っている可能性もある。そのため、使うことは非推奨。
今日の説明は開発者が理解できていないことが多いのだが、Webアプリケーション脆弱診断で可視化できるのか？
脆弱性診断をする人次第。ツールだと見つからないような脆弱性も多いので、本当に腕前次第。
今日デモで使っていたツールは？
Burp Suite
dangerouslySetInnerHTMLを防ぐ施策を知りたい
開発ツールによっては危険だよ、と教えてくれるはず。また、SASTでも見分けられるはず。
セキュリティが楽しくなったきっかけは？
ややこしいので知的好奇心がそそられたという感じ。
会全体を通した感想
Cookie周りはなかなか仕様がややこしい上に頻繁にアップデートが入るので、一面であっても基礎的な部分をこのような形で整理していただけたのはすごくありがたかったです。
今日あった話の脆弱性をSAST等で以下に早期に見つけていくのか？は今後の課題になってくるだろうなと思いました。
