Security Study #1 「Webアプリケーションセキュリティ」という勉強会に参加してきました。
といっても、オンライン開催なのでYoutubeで動画視聴による参加になります。
勉強会に参加しても、聞くだけだとふーんで終わってしまうので、簡単にブログにアウトプットすることにしました。
大きく2つのテーマで講演がアリました
「フレームワークで脆弱性対策されているのに現実のアプリケーションに脆弱性が減らないワケ」
セキュリティの第一人者である徳丸氏の講演
ウェブフレームワークが数多く登場しているにも関わらず脆弱なアプリケーションが亡くならない理由を解説していた。
ざっくりまとめると以下の通り。
PHP参考書の惨状
過去発行されたPHP入門書は脆弱性を含んだ例を解説していることがあるため、そのままのコードを利用するのは危険な場合がある
SQLインジェクション
フレームワーク提供のO/Rマッパーを利用していればフレゲルことがほとんどである
フレームワーク提供のO/Rマッパーでは実現できないSQLが存在しており、そのSQLを実行するためにRaw(SQLをそのまま記述できるメソッド)を利用したときに脆弱性が発生することがある
SQLインジェクションを防ぐにはプレースホルダを利用するのが良い
XSS
テンプレートエンジンを利用していればHTMLエスケープが行われる・・・わけではなく、サニタイズを行うため別途ヘルパー関数を利用する必要がある
<img src=”/” onerror=”alert(1)” /> このような記述でXSSが実現できる
Laravelの場合であれば「Js::from()」のようなメソッドを利用する必要あり
認可不備
これは本来見れては行けない情報が見れてしまうということ
認可不備があると、URLパラメータとしてユーザーIDを利用している場合、ユーザーIDを変更することで他の人の情報が見れてしまう
そんな雑な作りにはなっていないだろうと考えがちだが、意外と多い
CSRF
これもフレームワークの機能を利用していれば防げる脆弱性である
が、まれにGETメソッドで更新処理を行っている場合があり、そのような場合にCSRFが成立する場合がある
まとめ
フレームワークを導入したからといって、すべての脆弱性に自動で対応されるわけではない
フレームワークの特性を理解し、脆弱性を作り込まないように開発者が意識することが大事である
逆にフレームワークのような便利なものが出てきたから、セキュリティに対する学習がおろそかになっているかもしれない
アジャイル開発に求められるセキュリティ
アプリケーションの開発サイクルは日に日に短くなっている
アマゾンでは１時間で1000デプロイしてやる みたいな勢いらしい
アプリケーションの開発サイクルは短くなる一方、セキュリティのチェック感覚は長いまま
セキュリティチェックもアジャイルのように短い間隔で回していく必要がある。どうするか？
自動化できるところは自動化する。脆弱性チェックを自動化するツールは存在しているため、そのようなツールを利用して脆弱性チェックを自動化する
BugBountyという仕組みがある。ホワイトハッカーに自社の脆弱性やバグを発見してもらい、報酬を払う仕組み。日本ではあまり普及していないが、任天堂にも導入事例があるそうだ。
以上
せっかく勉強会に参加したので、ひとまずアウトプットしてみました
資料がないとなかなか分かりづらい（自分も多分、後で読んでもわからない）と思うが、聞くだけで終わらず、今後は何かしらアウトプットしていきたい。
