# KT#006-yokoi スーパーハカーになろう ###### tags: `security` ## 参考サイト * [安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity.html)：最低限抑えておきたい人向け * [AWASP TOP 10](https://owasp.org/www-pdf-archive/OWASP_Top_10-2017(ja).pdf)：グローバルでのセキュリティ基準に対応したい人向け * [体系的に学ぶ 安全なWebアプリケーションの作り方 第2版　脆弱性が生まれる原理と対策の実践 ](https://www.amazon.co.jp/dp/B07DVY4H3M/ref=cm_sw_em_r_mt_dp_U_Jn7XEbNRSXW6S)：さらに詳しく知りたい人向け --- ## セキュリティー対策 セキュリティ対策と一言で言っても、多様な観点での対策が必要。 ### 今日話すこと * WEBアプリケーションセキュリティ * SQLインジェクション * クロスサイトスクリプティング * セッション管理の不備 * などなど ### 今日話さないこと * ネットワークセキュリティ * ルータによる不要な通信の遮断 * Firewallによる通信のフィルタリング * IDS, IPS, WAFによる不正な通信の遮断 * サーバセキュリティ * セキュリティパッチ適用 * 不要なサービスやアプリケーションの削除 * 認証の強度を高める（SSH公開鍵認証・パスワード認証の無効化） 以降、セキュリティと書いた場合はWEBアプリケーションセキュリティを指すことにする。 --- ## セキュリティ対策がなぜ必要か 最低限のセキュリティ対策を講じなかった場合、開発側が法的に責任を問われるから。 ### 事例紹介 * セキュリティ要件が明示されていないシステム開発を、ある会社が受注 * ある会社は、セキュリティ対策に不備のあるシステムを納品 * 納品したシステムでセキュリティ事故が発生し、情報が漏洩 * 発注者は開発会社を相手取り損害賠償を請求 #### 判決概要 発注者はセキュリティ要件を明示していなかったものの、受注者は適切なセキュリティ対策が採られたシステムを提供すべき債務があり、それを怠ったとして、損害賠償が命じられた。 * [SQLインジェクション対策もれの責任を開発会社に問う判決](https://blog.tokumaru.org/2015/01/sql.html) --- ## セキュリティ対策としてどのレベルが求められるか 公的なガイドラインが制定されており、最低限のセキュリティ基準としてこのガイドラインを守ることが推奨される。 * 安全なウェブサイトの作り方 * https://www.ipa.go.jp/security/vuln/websecurity.html * 上記の判決において"適切なセキュリティ対策"の根拠として用いられたガイドライン * セキュリティチェックリストもあるので便利 * OWASP TOP 10 * https://owasp.org/www-pdf-archive/OWASP_Top_10-2017(ja).pdf * グローバル企業を中心に、近年は国内でも普及してきたガイドライン --- ## アプリケーション実装方針（個人的な意見） * HTTPSを使って通信の暗号化 * HTTPを使わない * WEBフレームワークやライブラリを活用する。 * 脆弱性の原因となりやすいので、できるだけ自前での実装を避ける。 * セキュリティのベストプラクティスに従う。 * ただしフレームワークやライブラリを過信しない。 * フレームワークやライブラリだけでは十分な対策にはならない。 * 上記のガイドラインと照らし合わせて**抜け漏れがないか確認**が必要。 ### プログラミング言語とWEBフレームワークの一例 * Python + Django * [Django におけるセキュリティ](https://docs.djangoproject.com/ja/3.0/topics/security/) * Python + Flask * [セキュリティの考慮点](https://msiz07-flask-docs-ja.readthedocs.io/ja/latest/security.html) * NodeJS + Express * [実稼働環境におけるベスト・プラクティス: セキュリティー](https://expressjs.com/ja/advanced/best-practice-security.html#avoid-other-known-vulnerabilities) * Java + Spring * [Spring Security リファレンス](https://spring.pleiades.io/spring-security/site/docs/5.3.3.BUILD-SNAPSHOT/reference/html5/) * [セキュリティ対策](http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/Security/index.html) --- ## 脆弱性 太字の項目をハンズオンします。 1. **SQL インジェクション** 2. OS コマンド・インジェクション 3. パス名パラメータの未チェック／ディレクトリ・トラバーサル 4. **セッション管理の不備** 5. **クロスサイト・スクリプティング** 6. CSRF（クロスサイト・リクエスト・フォージェリ） 7. HTTP ヘッダ・インジェクション 8. メールヘッダ・インジェクション 9. クリックジャッキング 10. バッファオーバーフロー 11. **アクセス制御や認可制御の欠落** ※ 「安全なウェブサイトの作り方」より抜粋 --- ## サイトへの攻撃シミュレーション https://github.com/k-yokoi/web-security-test ### シナリオ1 脆弱性たっぷりのある会員サイトが公開されました。攻撃を仕掛けましょう。 #### ミッション ~~http://54.186.9.198:5000/~~ * 他ユーザの会員ページへのアクセス * 管理者ページへのアクセス * ユーザー削除ページへのアクセス ### シナリオ2 管理者がバグに気づき、ある攻撃手法が封じられてしまいました。 また追加機能として、会員サイトに会員情報編集ページも追加されました。 再度攻撃を仕掛けましょう。 > 実際にこのバグは意図せず組み込まれていたもので、かねじゅんとトリスの攻撃により発覚したw #### ミッション ~~http://54.186.9.198:5001/~~ * ユーザー削除ページへのアクセス * Aliceの会員情報編集ページへのアクセス（Aliceのユーザーページからアクセスできる） ### シナリオ3 このサイトにアクセスした利用者が、フィッシングサイトに飛ばされるように攻撃を仕掛けましょう。 #### ミッション 非公開 * 会員情報一覧ページにアクセスした利用者が、Googleのホームページ（フィッシングサイトの代わり）に飛ばされるように改変 --- ## 埋め込まれてる脆弱性 ### SQLインジェクション SQLの呼び出し方に不備がある場合に発生する脆弱性 #### 発生しうる脅威 * データベース内の情報漏洩 * データベース内のデータ改竄 * ログイン認証の回避 ### セッション管理の不備 セッション ID と Cookie の管理方法に不備がある場合に発生する脆弱性 #### 発生しうる脅威 * 利用者のなりすまし ### クロスサイト・スクリプティング HTML動的生成の実装に不備がある場合に発生する脆弱性 #### 発生しうる脅威 * Webサイト利用者のブラウザ上で、勝手にJavaScriptを実行 * 偽情報の表示 ### アクセス制御や認可制御の欠落 本来アクセス制御をかけるべきページにかけていない脆弱性。 認可されていない（アクセス権限がない）ページにアクセスできる脆弱性。 #### 発生しうる脅威 * 利用者のなりすまし * 情報漏洩 ### 意図していなかったバグ --- ## 感想 Flask完全に理解した。マジ簡単便利