はじめに
Wemotionでは「スキル向上による給与UPの好循環サイクル」という持続的な給与UPを実現するため、全社的な取り組みとして学習支援を行っています。学習支援の一要素として定期的な社内勉強会を開催します。
そんな社内勉強会の第1回目として開催した「セキュアプログラミング」について、社外向けにも概要を公開します。
※ ページ下部に勉強会で使用した実際の資料（全ページ）を入手する方法も記載しています。
セキュアプログラミングの学習内容
セキュアプログラミングの勉強会では、まず脆弱性や攻撃手法について理解を深め、その上でセキュアな開発を行うために重要なことを学びました。それぞれ概要を紹介します。
攻撃手法について
今回扱った脆弱性や攻撃手法のトピックは以下になります。
- Webアプリケーションに依存しない攻撃
- パスワード攻撃
- 既知の脆弱性を突く攻撃
- 構成や設定の不備を突く攻撃
- 強制ブラウズ
- 意図しない情報流出
- バックドアやデバッグモードの残存
- 入出力チェックの不備を突く攻撃
- パラメータ改ざん
- SQL インジェクション
- OSコマンド インジェクション
- クロスサイトスクリプティング（XSS)
- HTTPヘッダー インジェクション
- ディレクトリ トラバーサル
- セッション管理の不備を突く攻撃
- セッション ハイジャック
- セッション 固定攻撃
- クロスサイト リクエスト フォージェリー（CSRF）
Webアプリケーションに依存しない攻撃
Webアプリケーションに依存しない攻撃の中に、「リスト型アカウト攻撃」「辞書攻撃」「総当たり攻撃（ブルートフォース攻撃）」があります。
リスト型アカウト攻撃では、攻撃者が事前に何らかの方法で取得したIDとパスワードの組み合わせを使用して攻撃を行うため、Webアプリケーション間でIDやパスワードを使い回すユーザーが多いことも相まって攻撃成功率が高いです。
パスワード攻撃へのサービス側の対策としては、「一定回数以上ログインが失敗した時のアカウトロック」「IPアドレスの制限」「多要素認証」などがあります。しかし、これらの対策を悪用し意図的にアカウトをロックすることで、サービスの提供を阻害されるケースについても想定する必要があります。
利用者向けの対策としては、「IDやパスワードを使いまわさないようアカウト画面での注意喚起」「パスワードインジケータの実装」などがあります。
総務省が提示しているリスト攻撃対策
https://www.soumu.go.jp/main_content/000274856.pdf
構成や設定の不備を突く攻撃
構成や設定の不備を突く攻撃の中に、「強制ブラウズ」「意図しない情報流出」「バックドアやデバッグモードの残存」があります。
本来は公開していないファイルやディレクトリにアクセス出来てしまう「強制ブラウズ」や、エラーメッセージからの「意図しない情報流出」、開発モードや管理者用の入り口である「バックドアやデバッグモードの残存」について、原因と対策を扱いましたがここでは詳細を割愛します。
入出力チェックの不備を突く攻撃
入出力チェックの不備を突く攻撃の中に、「パラメータ改ざん」「SQL インジェクション」「OSコマンド インジェクション」「クロスサイトスクリプティング（XSS)」「HTTPヘッダー インジェクション」などがあります。
クエリパラメータやフォーム値、Cookieを書き換える「パラメータ改ざん」、不正な入力によりOSコマンドを実行させる「OSコマンド インジェクション」、HTTPレスポンスに任意のヘッダーやボディを追加する「HTTPヘッダー インジェクション」について学びましたが、特に有名な攻撃手法である「SQL インジェクション」と「クロスサイトスクリプティング（XSS）」について詳しく紹介します。
SQL インジェクション
SQL インジェクションとは、不正な入力により任意のSQLを実行する攻撃であり脆弱性です。SQLに対してSELECT（情報の取得）だけではなく、設定によってはINSERT, UPDATE, DELETE（情報の改ざん、削除）、DROP（テーブルの破壊）が行えてしまうため、絶対に防ぎたい脆弱性となります。
クエリパラメータなどから取得した文字列を、そのままSQLに流す設計などが原因になり得ます。例として、”ECサイトの購入履歴一覧でクエリパラメータのuidを使用した場合”について考えてみます。
URL: https://shopping.wemotion.co.jp/history?uid=1%27OR%271%27=%271
上記のURLで購入履歴を表示する際にクエリパラメータをそのままSQLに流すと、「1%27OR%271%27=%271」はデコードすると「1’OR’1’=’1」となり、必ず真になってしまします。
SELECT order_date, price, item_id, ...
FROM orders
WHERE uid = '1'OR'1'='1'
;条件絞り込み部分が正常に機能せずに、ordersテーブルの中身を全て取得される懸念があることがわかるかと思います。
クロスサイトスクリプティング（XSS）
クロスサイトスクリプティングは、ブラウザ上で不正なHTMLタグやJavaScript等を実行する攻撃であり脆弱性です。
クエリパラメータなどから取得した文字列をそのままページ中に出力するケースを例に見ていきましょう。検索ページなどでユーザーが入力したキーワードをそれをそのままページ中に出力する実装になっている場合、以下のようなURLから任意のHTMLタグをクエリパラメータを介して挿入される可能性があります。
URL: https://search.wemotion.co.jp/?query=<from><input>ログイン</input></form>…
偽のログインフォームが表示されるURLを生成され、そのURLがSNSや掲示板などでシェアされた場合にログイン情報が盗まれる懸念があることがわかるかと思います。他にもscriptタグなどから任意のJavaScriptを実行される懸念もあります。
セッション管理の不備を突く攻撃
セッション管理の不備を突く攻撃の中に、「セッション ハイジャック」「セッション 固定攻撃」「クロスサイト リクエスト フォージェリー」があります。
セッションIDを推測や盗用することで別のユーザーになりすます「セッション ハイジャック」、正規ユーザーの権限を利用する「クロスサイト リクエスト フォージェリー」について、原因と対策を扱いましたがここでは詳細を割愛します。
ソフトウェア等の脆弱性関連情報に関する届出状況
独立行政法人 情報処理推進機構（IPA）が脆弱性に関する届出を集計したレポートを公開しています。「クロスサイトスクリプティング（XSS）」や「SQL インジェクション」が多いことがわかります。
https://www.ipa.go.jp/files/000097930.pdf
セキュアな開発を行うために
脆弱性や攻撃手法の理解を深めた上で、セキュアな開発を行うためにはどうすれば良いのかについて以下の内容を扱いました。
- 要件定義と設計が重要
- セキュリティはトレードオフ
- セキュリティの原則
用件定義と設計が重要
セキュアな開発を行うためには設計以前が最も重要で、最上流である用件定義からセキュリティに配慮する必要があります。また、セキュリティ要件は早い段階で対応する方が圧倒的にコストが低くなります。
Kevin Soo Hoo, “Tangible ROI through Secure Software Engineering.”Security Business Quarterly,. Vol.1, No.2, Fourth Quarter, 2001.
https://www.sbbit.jp/article/cont1/26731
用件定義の段階から適切な工数・スケジュールを確保し、異常系の考慮、自動テスト等を出来るだけ考慮した開発・実装を行うことが大切です。また、運用開始後に出現した新たな脅威に対応できる体制づくりも必要になります。
セキュリティはトレードオフ
セキュリティはコストと利便性のトレードオフです。セキュリティ向上のためのコスト増加は必ずしも容認されるとは限らず、同時に利便性を犠牲にすると利用者が不快に感じることがあります。
セキュリティに対するコストと利便性のトレードオフの関係でバランスを取ることも大切になってきます。
セキュリティの原則
セキュリティの重要な原則は以下です。
- 必要最低限の情報・機能だけにアクセスを許可
- 最小の情報のみ保有
- 個人情報・機密データは暗号化
- 安全な方に倒す
- 標準的な技術を使用する
必要最低限の情報・機能だけにアクセスを許可
ユーザーを識別しパスワード等を用いて認証し、情報や機能に対して最小限の権限のみを与える認可。全ての情報・機能は認証と認可で制御するようにします。
最小の情報のみ保有
保持しなくても良い情報は取得せず持たないようにし、1つにまとめて保存せず利用する単位で分割して保持するようにします。
個人情報・機密データは暗号化
万が一、盗まれた場合を想定して可能な限り暗号化し、個人情報・機密データを保持する場合には暗号化し、取得する際の通信は暗号化通信を用います。
安全な方に倒す
誤操作や誤動作による障害が発生した場合でも常に安全になるようにするフェールセーフ、知識を持たないユーザーが操作しても問題が起こらないようにするフールプルーフと、安全な方に倒れるようにします。
標準的な技術を使用する
広く受け入れられ確立した技術や解決法を無視して自前の暗号化やハッシュアルゴリズムを作らない。（車輪の再発明は不要）
最後に
脆弱性や攻撃手法、セキュアな開発を行う上で大切なことに対して理解を深めることが出来たでしょうか？
実装を行う業務だけではなく、報酬が高い傾向にある設計・要件定義の業務においても、セキュリティを意識し開発に取り入れることが出来れば周りに対して差別化することが出来ると思います。
セキュリティはここで扱った内容が全てではなく、日々のアップデートも必要になります。わからないことや気になったことは自分でもどんどん調べることも大切になります。
もし参考になりましたら今後の勉強会まとめ記事も読んでいただけると幸いです。また、SNSなどにシェアいただけると嬉しいです！
資料を入手する
以下のフォームを送信すると、入力いただいたメールアドレス宛に資料の共有リンクを自動でお送りします。
※ 資料の共有リンク以外に、WemotionのPRメールをお送りする場合があります。
