これからのWebセキュリティ フロントエンド編 #seccamp

Editor's Notes

• #5: ・ChatWork でWebフロントエンドを担当 ブラウザ上で動くScalaを書いてます。 基本的にセキュリティとの関わりは趣味の範疇。MixiさんからAmazonギフト券もらったくらいの経験 ・きっかけは「趣味と実益のスタック破壊」 これは「いかに対象のコード上でバッファオーバーフローやヒープオーバーフローを起こすか」という視点で書かれた文書。非常に面白かった すでにサイトからは消えていてWebArchivesでのみ読める 「セキュリティが趣味になる」ということを知ったのは衝撃だった ・セキュリティ関係での活動はApplicationCache poisoningが主 ApplicationCache poisoningはけっこう昔から一般的に言われていることなので取り立てて言う話ではない DNS関係も好き
• #7: 今までセキュリティとは開発とは別に考えられていた。 現在ではどういったアーキテクチャを採用するかによってセキュリティにかかるコストが大きく変わってしまっている。 セキュリティを無視して開発はできないし、開発を無視してセキュリティは語れない
• #8: 「これからの」話をするということは未来の話をすることになる 未来の話をするなら過去を知らなくてはいけない
• #11: まだこの頃は「フロントエンド」という分類どころか「Webセキュリティ」という分野すらなかった。 この頃の攻撃は各クライアントを直接攻撃し、ローカルにあるファイルを奪取するのが一般的だった。 実際JavaScriptを有効にしているだけで受ける攻撃も多かった。 「JavaScriptを有効にしたまま怪しいサイトを訪問する」のは危険な行為だった。
• #12: 現存していない技術も多い。 この時すでにOriginの詐称が攻撃の目標として認識されていたのが興味深い。
• #14: CSSもセキュリティの歴史とは無縁ではなかった。 Nimda、Klezと言ったウィルスはブラウザの脆弱性をついた攻撃も使っていた 行政系のサイトでは未だに「スクリプトによる貼り付け処理」を要求するサイトが存在している
• #15: office氏はそれより前から知っていたので事件は結構衝撃だった 当時XSSはそもそも存在や危険性自体を認識できている人のほうが少数派だった
• #17: この辺りから個別のWebサイトに対する攻撃が始まる。 逆にここまでWebサイトに対する標的型攻撃は少なかった。 Webサイトのドメインが価値を持ちだした時期。
• #19: 「安全なウェブサイトの作り方」が2006年。 そろそろ初版から10年が経つ。 「Wiki関係」はWikipediaの話ではないです
• #20: このへんで仕様レベルのセキュリティが指摘されるようになる。 「ログに残らない」、「サーバ側で対処できない」というところからDOM based XSSが単純なXSSと比べて特色があるとみなされるようになった。
• #22: 仕様上のセキュリティホールがかなり無理やり修正される。
• #24: セキュリティ上の問題がある場合、標準機能のサポートが切られるようになる 標準仕様の進化にともなって発生するセキュリティホールの出現 WebViewの問題は一部放置されつつ、OSの世代交代でうやむやに
• #26: Flash playerはちょいちょい出つつもswf経由のXSSは過去の脆弱な実装を改めて掘り返した点で影響が大きかった。 文字コードはある継続的に報告されているが、ここまできても依然安全な実装が難しいという点では興味深い 壊れた文字コードや文字コードの強制指定は対応が難しい Android WebViewはWebViewを使っているかなりの割合のアプリが一斉にアップデートするという自体に パスワードリストアタックは過去に流出したパスワードリストが流用されているため「攻撃側に蓄積された情報によって脅威が増える」点で興味深い パスワード自体の限界が指摘されるようになる
• #28: VirtualDOMに関しては後で詳しく説明します。
• #30: ここまでJavaはずっとセキュリティ情報に登場し続けてきた。 もちろん機能が豊富な点も原因だとは思うが、すでにブラウザベンダー以外で一般的にブラウザに要求されるレベルのセキュアな実装を実現することは困難になっているということなのかもしれない
• #31: ここまで過去の脆弱性をまとめてみました。 ここからは現在進んでいる話をしたいと思います。
• #32: 暗号化通信必須のWeb標準が登場 APIレベルではServiceWorker等の暗号化時のみ可能なAPIの登場 通信レベルでもhttp2は事実上暗号化前提になっている これは仕様上要求はされていないが、途中の通信機器の影響を考えると実際には必須と考えていい 暗号化前提は機能拡張においてセキュリティ以上に大きな意味を持っている
• #33: テンプレートの自動文脈解析での自動エスケープから、静的型解析からの事前検証に進みつつある。 TypeScript、flowなどからフロントエンドの静的型解析が一般化しつつある。 そこにVirtualDOMが加わることでDOMに抽象層が生まれてStrict Auto Escaping相当の事前検証が実現しつつある。 これが実現するとアプリケーション実装に起因するXSSを起こすのは非常に困難になる。 ClosureToolsは流れを牽引しているがあまり広まっていない。 使用シーンが限られており、ツールとして使いにくい。 セキュリティだけの技術、開発者を無視した技術は広まらない。
• #34: ここでは国内で有名なプリケーションベンダーをあげたが、すでにブラウザベンダーでは脆弱性報奨金制度は一般化している。 さらに、ブラウザベンダーを通じて仕様策定にも影響している。 仕様策定やブラウザの実装側でもバグハンターがいる前提の開発が行われている。
• #35: ここからはタイトルの話に戻って未来の話をしたいと思います。
• #36: ・Webのアプリ化とアプリのWeb化 Webの進化にともなって境界が曖昧になっていく。 セキュリティでも曖昧になっていくだろう。 Webのセキュリティ問題がアプリで再現され、アプリのセキュリティが再現されるだろう。 その中間では新しい攻撃方法が登場するだろう。 ・CSPの普及と進化 結構微妙な位置づけになっている。 現状のものでは柔軟性が低かったりブラウザ互換の問題が合って使われていない。 これも「開発者を無視したセキュリティ技術は広まらない」例。 ・機能追加とパーミッションモデル これまでの機能追加は既存のセキュリティモデルの上に可能な範囲だった。 これからは「ユーザの許可を得る」という新しいセキュリティモデルの上で、より大きな権限を得ることができるようになるだろう。
• #38: セキュリティモデルはこれまで端末やサービスによって変わってきた。 スマホのセキュリティモデルはPCのものと違う。 PCは共有されることを想定するが、スマホは共有されることを想定しない。 この前提がないと二段階認証を理解するのが難しい。 時計型端末でパスワードを入力させるのは難しいだろう。 リング型端末では指紋認証もできないかもしれない。 そもそも認証とはなにか？、権限とはなにか？を考える必要がある。 サービスや対象やユーザによって「何から何をどうするのか」は変わる。 今後、これを定義するのもセキュリティの範囲になるだろう。
• #40: 主にこの3つに収束していくのではないか ・バグハンター 主にフリーランスでバグを狩る 仕様やOS、ブラウザ、サイト等のバグを見つけて報奨金を得る 腕試、売名目的での参加も含まれる ブラウザ、OS等に対する純粋なセキュリティ技術が求められる ・セキュリティアーキテクト 開発側と連携して、開発工程にセキュリティ機構を組み込む 開発チーム内でセキュリティを主に担当しつつ開発自体にも参加する 開発スキルが求められる 現在のSWETに近いポジションになるだろう。 ・セキュリティマネージャー 企業内でインシデントコントロールや、外部のバグハンターと連携して報奨金制度の運営などを行う 外部の監査組織と内部の開発チームとの橋渡しや、継続的なセキュリティ監査等を行う マネージメントスキルが求められる
• #42: ・攻撃者視点 フロントエンドでの攻撃はログが残りづらいので攻撃が発見されづらい。試行錯誤に制限を受けない。 ソースが見えることも強い。圧縮がかかっていても大きな手がかりになる。 ・実装者視点 反射型XSSはどの入力経路から攻撃が可能かはっきりしないため値の扱いが難しい。referrerは要エスケープ？、location.hashはデコード必要？ 誰がどこまでエスケープするかがはっきりしていないためXSSの原因にもなる。jQueryのCSS Selectorとか ・解析者視点 location.hash経由のDOM based XSSの場合、そもそも攻撃されていることを検知することも困難。 攻撃されていることがわかったあとも「どういう攻撃を受けたのか？」「誰が攻撃を受けたのか？」がわからない可能性が高いので被害回復が困難になる可能性が高い。
• #43: すでにMozillaや仕様策定団体などはバグハンターがセキュリティリスクを見つけることを前提に開発や仕様策定を進めている 報奨金制度が広まることで、サイトの安全性を外部からある程度検証することが可能になる 「XSS一件5万」よりも「XSS一件10万」のサイトの方がXSSに関する検査が行われる頻度は高いはず (実際には「いつから運営しているのか？」、「開発速度はどのくらいか？」等に行って変わるので単純に比較はできないが) 「お金をかけて安全にする」ことができる。これまでは「機能数=検証期間=価格」だったのが、純粋に金額を積めば安全性が買えるようになった。 ただ、まだこれを運営できる人間が足りない。 実際企業で導入しようとした時に「検証ルールの策定」「金額換算」「重複申告の処理」「開発側への共有と修正までの追跡」「報告者とのコミュニケーション」等々ができる人が非常に少ない。
• #44: 技術的な問題点は少なくなっていくだろう これまでのような開発者個人の技術ではなく、フレームワークの選定や設計技術の割合が大きくなっていく セキュアなフレームワークや設計を採用しているかでセキュリティに圧倒的な差が出てしまう そして、アプリケーションレイヤーの問題が主題になっていく この問題は今後も継続するだろう ただ、それはセキュリティの問題なのか？ QA「品質管理」の文脈に取り込まれて行くのではないか セキュリティエンジニアの主流はバグハンターになるのではないか 実際にはセキュアな設計を採用できず、これまでのようなセキュリティエンジニアが必要な現場も多いだろう でも本来であれば一部の高スキルなバグハンターが基板部分を叩いてみんなそれに乗れる方がいい これは願望でしかないけど、「All or nothing」ではないはず
• #46: ・2000年くらいからのセキュリティ史 特にWebフロントエンドのセキュリティは一時期大きな問題気なったけど、現在は解決に向けて進んでてそろそろ大きな成果になりそう。 ・セキュリティの流れ 技術的なブレークスルー 潮流はどこに向かっているのか セキュリティの攻撃方法、防衛方法、業界潮流、それぞれが遅延して流れている。 だんだん加速する流れの中で、常に先に進まなければならない。 流れの先端は攻撃方法。だからセキュリティでは防衛側も攻撃方法が必須。 自分で攻撃してみることが推奨される。 ・歴史を学ぶ意味 正直そんなにない。昔はブラウザにバッファオーバーフローがあったことを知っててもほとんど意味はない。 ただ、業界視点では意味がある。専門家として歴史を知らないことは許されない。