天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Security Study #1 「Webアプリケーションセキュリティ」 に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、Connpassのイベントページから引用です。

Forkwell はこれまで「つくり手と、未来を拓く。」というビジョンのもと、第一線を走るエンジニアから統合的な学びを得る勉強会を継続開催しています。

今回はセキュリティについて学ぶシリーズを開催致します。 不正アクセスや情報漏洩等のセキュリティインシデントは年々増加しており、セキュリティ意識はありとあらゆるサービスで求められるようになりました。

そこでForkwellではSRE Gapsシリーズでもお馴染みの3-shake社に協力いただき、セキュリティに関する勉強会を開催します。 セキュリティに関する思想や向き合い方、具体的な技術論まで幅広く学びを提供する場に致します。

会の様子

基調講演〜フレームワーク脆弱性対策されているのに現実のアプリケーションに脆弱性が減らないワケ〜

かつてのPHP入門書から考えるセキュリティの惨状

PHP入門書で紹介されている具体的なソースコードを幾つか示してくれた上で、脆弱性をつける事例(エスケープしているのにSQLインジェクションが発生する例...)を示してくれました。

アプリケーションフレームワークを活用しても脆弱性がつかれる理由

アプリケーションフレームワークでは、上記の例で挙げてくれたSQLインジェクションに加えてクロスサイトスクリプティングやクロスサイト・リクエストフォージェリの対策がされていたり、CORSをはじめとしたセキュリティ機能がありますが、なぜフレームワークを使っていても脆弱性をつかれるのか?という話を聞いていきました。

以下のような原因が考えられるということです。

  • (Ruby on Railsで)whereメソッドの引数に値を埋め込んでいる
  • (Ruby on Railsで)演算子として外部パラメータを埋め込んでいる
  • (Ruby on Railsで)orderメソッドに外部パラメータを指定している(最新版では対策がすでにされている)
  • (Laravelで)文字列連結による条件生成をwhereRawで使用する(プレイスフォルダを使っていない)
  • (CakePHPで)明示的にエクスケープをしていない
  • HTMLの中にJavaScriptがある二重構造の場合、¥などを含めてJavaScriptを動的生成する(JavaScriptを動的生成するのではなく、カスタムデータ属性を活用すれば考慮不要になる)
  • (Reactで)innerHTML相当の機能を使っていると、img要素がレンダリングされてクロスサイトスクリプティングが発生する。(innerHTMLは避けておくことを推奨)
  • 認可制御不備。task一覧をGETした時に、自身に権限がない情報を意図的に指定してしまった時など
  • CSRF対策を無効化している
  • GETで更新処理を有効にしている

結論として、セキュリティ機能が組み込まれたフレームワークを使用する際も、セキュリティに対して自覚的にならないと、上で紹介したように脆弱性をつかれる可能性も十分あるということです。

事例講演〜プロダクト開発の落とし穴?アジャイル開発に求められるセキュリティ〜

アジャイル開発におけるセキュリティ対策

セキュリティ対策の仕組み(ファイアウォールやWAF...)を導入することが世間一般的な対策になっている一方で、仕組みを超えてプロダクトに攻撃してくるセキュリティ攻撃もあるので、それに対してどのような対策をしていけばいいのか?というお話がありました。

以下、アプリケーション側での対策とシステム構成(インフラレイヤー)側での対策をそれぞれ書いていきます。(これらの対策をCI/CDに組み込んでおく)

・アプリケーション側での対策

セキュアコーディングやSAST、DAST、IAST...

・システム構成(インフラレイヤー)側での対策

SCA、コンテナイメージ脆弱性スキャン、脆弱設定のアセスメント、CSPM...

脆弱性診断の頻度

アジャイル開発をはじめとした頻繁なリリースが求められている背景もあり、リリース後に行っている脆弱性診断はどれくらいの頻度が良いのか?という問いの投げかけがまずありました。(年に一回くらいが多いが本当にそれで良いか?)

問いの回答として「もし高頻度で脆弱性対策をしたい」となるのであれば、SecurityScanを用いたりBug Bounty*1の運用がおすすめだということです。

QA&パネルトーク

以下、Q&Aの内容を常体で書いていきます。

最新のフレームワークのセキュリティ対策はどのように情報収集しているか?

簡単な答えはないが、開発元のサイト動向を注視したり(これはクロスサイトスクリプティング対策のことを言っているんだ、という意識を持つ)、IPAJPCERT/CCをチェックしておく。

手間を惜しまないなら、様々な調査結果をアラートで知らせてもらい、記事や調査結果を見る。Twitterコスパがいい。

他にも、Bug Bountyで挙がってくるレポートを見たりするなどといった方法もある。

開発や運用の利便性を崩さずにセキュリティを担保向上させていくために意識できることはあるか?

セキュリティは壁になるので、完全に速度を落とさないというのは難しいと思う。
セキュリティを守ることが重要だという意識を開発者それぞれが持つことが重要になっていくのではないかと思っている。
また、自動テストでもセキュリティテストを多くカバーできる*2のでそこに組み込むのは一つの手。

難度は高いが効果が高いもので言えば、セキュリティの専門家に「やらないこと」を決めてもらう範囲を頼むというのもある。(徳丸さんの会社でも非常に相談の件数としては多い)

セキュリティ関連の対策に時間が書く必要があることをビジネスサイドにどう伝えるか?

前提として、経営が知識はなくてもセキュリティに興味がある(セキュリティに問題意識があること)状態であることは必須。
その上で、然るべき予算をつけてもらうことが重要。

ビジネスサイドという意味だと、何かあった時に誰が責任を持つのかをルール化してしまうのは一つの手。

また、セキュリティ対策を公にすることで、(しっかりしている会社だと思われて)ビジネス的にもメリットがあることを示すのも手。

Webセキュリティ対策や脆弱性診断の5年後/10年後はどうなっていると思うか?
  • 「人じゃないとできない」という範囲が狭まっている状態になっていればいいなあと感じている。
  • 人間がプログラムを書いている限りは、脆弱性診断はなくならないと思う。新たにアプリケーションをプログラムで書かなくても良い時代がもし来れば、脆弱性診断はなくなるかもしれない。とはいえ、ここ数十年を見ているとまだまだ脆弱性診断が必要な時代は続くと思う。
アプリケーションのセキュリティを突破しようとしている人ってどんな人がいいのか?

ランサムウェアはチームであることが多い。ただ、逮捕できていないので素性はわからない。
日本人か海外人かはわからないが、日本に根ざした犯罪も多くある。(誰が攻撃しているかはあんまり重要ではないと思っている)

Bug Bountyに参加しているホワイトハッカーは韓国人など、海外の人が多い印象はある。(以前海外のハッカソンに参加した時は、ロシアの人のレベルが高かった)

なお、海外の人が多い理由としては、技術力を活かせる職にありつけずダークサイドに流れているというのはある。

アジャイル開発やSPAで開発するお客様がセキュリティ診断の相談に来る際は、どんな相談が多いか?
  • 脆弱性診断は定期的に年一度やればいいよね、と感じて話をしてくる人が多い。
  • 基本的には開発手法とか関係ない。できるだけ早く脆弱性診断をしたいよね、という話が多い。来て欲しいのは、セキュリティを自動テストでできる限り担保したいという相談。
セキュリティ関連のツールや脆弱性診断ベンダーを選択するときに気を付けるポイントは?

(ベンダーをやっている立場なので回答が難しいが)わかりやすい報告書をあげてくれることと、デメリットを素直に提示してくれること。

ツールという観点だと、運用しきれるものか?というのは重要。如何に簡単に始められるか?というのが大事だと思っている。

会全体を通した感想

セキュリティ関連の知識は浅いので、非常に学びが多いイベントでした。
ソースコードレベルの具体的な例と、現場での運用にまつわる実践的な知識のバランスが取れていたのも非常に良かったです。

徳丸先生の本は隅々まで読もうと思います。

*1:ホワイトハッカーを雇って攻撃してもらい、脆弱性が見つかった際に報奨金を支払う

*2:ユーザの権限を敢えて落とすなど