ライブコーディングとデモで理解するWebセキュリティの基礎
•
5 gostaram•1,944 visualizações
2013/01/26 の LOCAL DEVELOPER DAY ’13 / Infra & Security で使用したスライドです。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a ライブコーディングとデモで理解するWebセキュリティの基礎
Semelhante a ライブコーディングとデモで理解するWebセキュリティの基礎 (20)
Último
Último (12)
ライブコーディングとデモで理解するWebセキュリティの基礎
- 1. ライブコーディングと デモで理解する Webセキュリティの基礎 2013/01/26 LOCAL DEVELOPER DAY '13 / Infra & Security 岸谷隆久
- 2. 自己紹介 • 2006年〜 ネットサービスの会社でセキュ リティエンジニア • 現在はフリーランスでWebシステムを中心 にインフラ/アプリ/セキュリティと全般的 にやってます。仕事のご依頼大歓迎です。 • 半年ほど前に札幌に引っ越してきました。
- 3. セキュリティエンジニアの仕事 不正アクセス対策全般です。大まかには… • セキュリティ啓蒙活動・セキュア開発教育 • ポリシーやルールの策定・運用 • 仕様・設計・実装等のレビュー • セキュリティ監査 • 不正アクセス監視 • セキュリティ用途システム調達・構築・運用 • 脆弱性情報の入手・精査・対応管理 • インシデントレスポンス etc…
- 4. 本日のお話 • Webサイトの運営において守るべきもの • どう守るのか • 代表的な脆弱性のしくみと対策 – SQLインジェクション – OSコマンドインジェクション – クロスサイト・スクリプティング – クロスサイト・リクエスト・フォージェリ • 効率的にテストを行うには • まとめ
- 5. Webサイトの運営において 守るべきもの
- 6. 何を守らなくてはいけない？ • システムの稼動（による事業活動） • 情報資産（各種データ、システムそ のもの） • 顧客の信頼 など
- 7. 不正アクセスが発生すると？ • システム停止（による機会損失） • 情報漏洩や毀損等により損害が発生 すればその賠償 • 信用低下による損失 など、直接的/間接的損失の可能性
- 8. 攻撃されることはあるのか？ 残念ながらある （攻撃者にとって利益がある）
- 13. • 不正アクセス事件以後システム再開に長期 間を要し業績を大きく落とす企業も • Webサイトへの攻撃に限らなければJAXAや 農水省などの報道も記憶に新しい • 発覚していないものも（おそらく）多数
- 14. Webに関わる上で • 開発者はセキュリティについて知り 考慮する必要がある • 外注する場合もリスクを評価して検 収するために必要な知識 • ユーザーとして被害にあわないため にもセキュリティの知識は有用
- 15. 脆弱性とは • ○ぜいじゃくせい ×きじゃくせい ×ぼうじゃくせい • 攻撃に対して弱い点、誰かが悪用で きるバグ • 一般的なものは対策方法が確立され ており、対策は難しくない（設計時 から考慮しないと面倒なものも）
- 16. どう守るのか
- 18. データの入出力処理が適切でない • 例えばアプリケーションからデータ ベースへ、シェルへ、ブラウザへ等 のデータの受け渡し方が適切でない と脆弱性が生じることがある • 「○○インジェクション」系の脆弱 性が代表的
- 19. 設計上の考慮不足 • 動作自体は仕様通りだが、仕様に問 題がありセキュリティ問題をもたら すケース • 認可の不備やクロスサイト・リクエ スト・フォージェリなど
- 20. 代表的な脆弱性のしくみと対策
- 21. SQLインジェクション
- 22. 攻撃者 サーバ SQL • アプリケーションからデータベースに発 行するSQLの構文がユーザーによって変 更され、データベースを操作される • 影響：大規模な情報漏洩、データベース の改ざん、破壊ほか、DBユーザーの権限 で可能な操作全て
- 23. SQLインジェクション DEMO
- 24. 原因と対策 • 入力値に含まれるSQL上でのメタ文字 を無害化せず実行してしまうことが原 因 • DBMSが提供するバインド機構 （Prepared Statement、placeholder）を 使いましょう • 自前のエスケープ処理は非推奨
- 25. OSコマンドインジェクション
- 26. 攻撃者 サーバ Command • シェルを呼び出す機能等のコマンドラ イン構文をユーザーによって変更され 、任意のOS操作を実行される • 影響：Webサーバ実行権限での任意の OS操作（内部の脆弱性を攻撃できる ため、多くの場合は永続的にroot権限 を得られる）
- 27. OSコマンドインジェクション DEMO
- 28. 原因と対策 • 入力値に含まれるシェル上でのメタ文字を無害 化せず実行してしまうことが原因 • シェルに任意の文字列が渡る実装をまず避けま しょう • プラットフォームが目的に応じた安全なAPIを 提供していればそれを利用しましょう • 仕様が許す場合はホワイトリストからの選択、 [a-zA-Z0-9]のみ許可するなどの方法も
- 29. クロスサイト・スクリプティング
- 30. 攻撃者 被害者 サーバ 攻撃スクリプトを含む 誘導 リクエスト＆レスポンス • ユーザーが入力したデータを表示する 箇所でHTMLの文脈が変更され、任意の スクリプト等の要素が挿入される • 影響：ブラウザ上で動作するスクリプ トでできること全て。Cookieの取得&設 定、画面の見た目上の改ざん、キーロ ガー、ポートスキャンなど
- 31. クロスサイト・スクリプティング DEMO
- 32. 原因と対策 • 入力値に含まれるHTML上でのメタ文字 を無害化せずブラウザへレスポンスし てしまうことが原因 • 出力時に最低限「”」「’」「<」「>」 「&」をHTMLエスケープしましょう （属性値はクォートすること） • <script>要素やイベントハンドラなどの 中への出力時は追加の対策が必要です
- 34. 攻撃者 被害者 サーバ 誘導 意図しない操作 • ユーザーが別のユーザーに、本人の意 思によらない操作を実行させてしまう （最近は誤認逮捕事件でもおなじみ） • 影響：対象サイトに対する意図しない 投稿や設定変更などの各種操作
- 35. クロスサイト・リクエスト・フォージェリ DEMO
- 36. 原因と対策 • 機能を実行するためのパラメータを 第三者も知ることができるのが原因 • 第三者に知られない（ワンタイム） トークンを用いる対策方法を推奨
- 37. 効率的にテストを行うには
- 38. • テストパターンやチェックポイント を整理したものはインターネットな どから入手可能 • いかに手間を省くかが問題
- 39. 自動化？
- 40. 自動化？ • 多くの脆弱性はプログラム外との連 携結果として生じるため、ユニット テストで評価しにくいことが多い。 • セキュリティスキャナ製品は一定の 効果が見込めるものの、原理的に検 出できない問題が少なくない。また 、商用製品は一般的に高価。
- 41. • “Local proxy” “Intercepting proxy” などと呼 ばれるツール
- 42. • “Burp Suite”, “Fiddler”, “Zed Attack Proxy”, “WebScarab” などのHTTPデバッグツール • Webアプリケーションテストスイート • 基本的な機能はどれも似通っている – リクエスト/レスポンスメッセージのインター セプト・編集 – リプレイ – アクティブ/パッシブスキャン（自動テスト） – ブルートフォース – リンク自動抽出などのWebサイト探査機能
- 43. （時間に余裕があれば） DEMO
- 44. • 単体テスト等のポイントではなくリ リース前の段階でシステム全体として 行うのが効果的（な場合が多いと思わ れる） • hidden要素やCookieなどはもちろ ん、HTTPリクエストの全ては任意に操 作可能であることを前提にしましょう。 「想定外の値」は脆弱性のもとです。
- 45. Appendix
- 46. おすすめ教材（Base） 「Webを支える技術 HTTP、URI、HTML、そしてREST」 • まずは戦いの舞台を 知る • セキュリティのため に限らず全体像を把 握しておきましょう
- 47. おすすめ教材 IPAが公開している 「安全なウェブサイトの作り方」シリーズ http://www.ipa.go.jp/security/vuln/websecurity.html （図は http://www.ipa.go.jp/about/press/20121226.html より）
- 48. おすすめ教材 「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」 • いわゆる「徳丸本」 • 攻撃と対策を体験す るためのVM付きで 理解が深まる
- 49. おすすめ教材（Advanced） 「The Web Application Hacker‘s Handbook: Finding and Exploiting Security Flaws」 • より脆弱性を探す側 の視点に立った内容 • 洋書 • 徳丸本の倍近いペー ジ数
- 50. まとめ
- 51. • Webシステムの脆弱性とその影響を 知って、安全なシステムを開発しま しょう。 • 技術の進歩につれ攻撃と防御も変化 します。ときどき目を向けて、どう 向き合うか判断していきましょう。
- 52. Any Questions? 個別の質問・依頼・相談、 その他何かありましたらこちらへどうぞ twitter: @tkishiya mail: tkishiya@logicflaw.info
- 53. ありがとうございました。
Notas do Editor
- キーメッセージ：Webセキュリティの基礎を知り、リスクを適切に評価できる目を養おう
- 最近はグローバルな ベストプラクティスを実践するオポチュニティのある会社らしいですが
- ただし DBMSとコネクタごとに様々なので、使用するバインド機構に既知の脆弱性がないことは確認する必要あり 自前でエスケープ処理を行うのは不完全になりやすく変更にも弱いため非推奨
- SQLと同様、自前でエスケープ処理を行うのは不完全になりやすく変更にも弱いため非推奨
- Test Driven で Security Spec を意識してコーディングするのは当然ながら効果的。ただしそれだけでカバーできないことが多いということ。 利用者間の権限、セッション系、CSRF等
- 早く始めるなら、画面や機能等の単位で開発完了したものから随時行うのもよい。