情報処理安全確保支援士2018年(平成30年)春午後2問2(5,874 文字)

問題冊子、解答例、採点講評はこれ
またIPAがリダイレクト設定せずにURL変えたりしなければつながるはずです

本文(設問1)

本文要約(設問1)

[前提]
① A社は提供サービスごとにWebサイトを作って公開している。WebサイトではWebアプリが稼働している。開発(設計、実装、テスト工程)と運用はB社か外部業者が行う。
[現状のセキュリティ]
① WebセキュリティガイドラインとしてXSS, SQLインジェクションなどの対策やリリース前の(脆弱性)診断を実施することを定め、外部にも順守を義務づけている
[Webサイト運用]
① A社カスタマーサポート提供用WebサイトXはA社データセンタXに設置、B社が開発と運用を行う。WebサイトX上ではWebアプリXが稼働、Webアプリケーションフレームワーク(WF)の一つであるWF-Kを使用して開発された。
② WebサイトXとシステム構成が全く同じWebサイトYを別のデータセンタYで災害対策用として設置している。サイトX稼働時にはサイトYは非公開でホットスタンバイ待機としている。
③ サイトX,Yのバッチ(ソフトウェア脆弱性修正プログラム)は3カ月ごとの定期メンテ前日にB社が確認、バッチがあればYに適用し、問題なければXに適用している。コンテンツもYで更新して問題なければXも更新する。バッチ適用とコンテンツ更新はB社のPCLAN上のC(人名)のPCで行う。
④ B社では全従業員にPCが1台ずつあり、Webサイト閲覧やメール送受信を行う。
[セキュリティインシデント発生]
① WebサイトXの利用者がWebサイトXのダウンロードページでファイルをダウンロードしたらマルウェア対策ソフトの警告が出た。B社が確認するとファイルへのリンクが外部のURLに改ざんされていたのでWebサイトYに切り替えるか検討したが、サイトYも改ざんされる可能性があるのでメンテ表記に切り替えた。
[専門業者の調査]
① いろいろ調査した結果、他に外部のURLに変えられたものはなく、DBサーバX、DBそのもの、WebサイトYは改竄されていない。
② WebサイトXについてはWF-Kに脆弱性Kがあり、特定の文字列を含むHTTPリクエストを送るとWebアプリ実行ユーザ権限で任意のファイル読み出しと書き込みができる可能性がある(攻撃手法K)。脆弱性KはWF-Kのパッチ提供済。
③ WebサーバXのアクセスログを確認し、ダウンロードページ更新日である3日前に外部からのアクセスがあった。ただ、攻撃手法Kに使う文字列がWebサーバXの標準設定ではアクセスログに残らないので、脆弱性Kが原因であった可能性もあるが真相は不明。
④ 脆弱性K自体は改ざん3週間前に公表されていたが、定期メンテの時期を鑑みるとパッチ適用は来週月曜だったので改ざんされていたと思われる。
⑤ 外部URLに変えられたページは他になかったが、スクリプトを埋め込まれるなどの他の形の改ざん可能性は残っている。この確認はWebサイトXの残ファイルを[a]して確認すると漏れもないし効率も良い。
⑥ さらに調査を進めると実際に攻撃手法KでWebサイトXを改ざんできることが確認できた。
⑦ プラットフォーム(B社PC-LANからOS及びミドルウェア)について、メンテで使うSSHサービスに辞書攻撃が成功することが確認されたが、B社PC-LANからのみのアクセスなので問題がないと考えるが、B社PC-LANに侵入されたときを想定してSSHの認証方式をパスワード認証方式以外に設定すること、運用チームのみが利用できる専用PCを用意する方法で検討を進める。
⑧ WebアプリXについてはXSS脆弱性が5件見つかったので、これらを合わせて修正と復旧を行いWebサイトXが再稼働した。

問題文(設問1)

解説(設問1)

(1)はアクセスログに残らない文字列とは何か。HTTPについてGETは文字が残るからダメでPOSTは安全みたいな話を聞いたことがあるでしょうか。私は聞いたことはあるけどどこで使うのかわかってなかった人です。さて、GETはURLの後ろに入れた文字列がそのまま記載されますが、POSTでは記載されません。逆に言うとPOSTはアクセスログに残らないということです。
答え 攻撃に使われる文字列がPOSTデータ内に含まれている場合
(2)はどのように確認すればページ改ざんがないと言えるか。WebサイトYは健全な状態で同じ構成とのことなのでこちらと比較しましょう。
答え WebサイトYの全ファイルと比較
(3)はSSHのパスワード認証以外の認証について。知識問題ですがSSHの認証方式はパスワード認証方式と公開鍵認証方式の2つです。
答え 公開鍵認証方式

本文(設問2)

本文要約(設問2)

① 全社Webサイトの脆弱性対応状況を調べると対応漏れのあるWebサイトが5つあった。担当者はそもそも脆弱性が発表されていることを知らなかった。
② ①を受けて情報システム部が一括して脆弱性情報を収集、担当者に伝達することにした。
③ 効率的な情報収集ができるように担当者に[b]を報告させた。更改などで[b]が変わる場合も報告させることとした。パッチの適用は担当者が今後も行うが、適用期限はセキュリティガイドにのせることにした。

問題文(設問2)

解説(設問2)

迅速な対応のための下準備と言われたらそれは構成管理。要は何を使っていてそのバージョンが何かがわかれば対応できるでしょという話。
答え Webサイトで使用しているOS、ミドルウェア及びWFの名称並びにそれぞれのバージョン情報

本文(設問3)

本文要約(設問3)

[全社セキュリティ強化]
① セキュリティガイドにXSS対策としてWebページに出力する全要素に対してのえスケープ処理実施、SQLインジェクション対策としてSQL分組み立ては全てブレースホルダで実装、運用としてWebサイトメンテ用PCを準備してその担当者だけが利用できるようにする。また、脆弱性が発見されたときはリスクレベルに応じて対応起源を決めた。
② 担当者から「サイト開発スケジュールが短いのでセキュリティ診断を受けている暇がなく、未診断でリリースすることもある」旨の発言があったので、社内でWebアプリ診断が迅速にできる体制を作ることにした。
[自社診断実施検討]
① A社診断項目は「XSS」「SQLインジェクション」「OSコマンドインジェクション]「[c]トラバーサル」「[d]リクエストフォージェリ」「セッション管理不備」「アクセス制御不備や認可制御欠落」「[e]ヘッダインジェクション」「メールヘッダインジェクション」「クリック[f]」とする。

問題文(設問3)

解説(設問3)

有名な攻撃名を埋めようの回。せっかくなので中身も書きます。参考サイトはIPAだらけにしておきます。IPAの試験だし
XSS : サイトの脆弱性をついて侵入、スクリプトを埋め込んで情報を窃取する別サイトに誘導する攻撃 問題はこちら
SQLインジェクション : DBと連携したSQL文を組み立てるアプリケーションに攻撃を仕掛け、DBのデータの消去や改ざんを行う。
ディレクトリ(c)トラバーサル : ファイル名をパラメータにしているような場合に公開するつもりのないファイルを参照しにいくこと
クロスサイト(d)リクエストフォージェリ : ユーザに罠用ページを踏ませ、そのユーザがログインしているページなどの攻撃対象に、ユーザの意図しない攻撃リクエストを送信させる。
セッション管理不備 : セッションIDが推測可能であったり、URLに格納されていたり、HTTPSで利用するcookieにSecure属性がなかったり、ログイン成功後にセッションを継続利用していること(図4注記より)
アクセス制御不備や認可制御欠落 : 関係者以外がアクセスすべきでないフォルダなどにアクセス制限が適切になされていないこと。誰でも知りえる情報で個人認証をするなどの認可のレベルが低いこと。
HTTP(e)ヘッダインジェクション : WebブラウザがWebサーバに対して送信するHTTPリクエストに、改行コードを含む不正な文字列を紛れ込ませることで、WebサーバからのHTTPレスポンスを改ざんする。
メールヘッダインジェクション : アンケートなどの入力値がメールで指定の相手に飛ぶ仕組みにおいて、入力値をいじってメールの宛先を変更する攻撃
クリックジャッキング : サイト上に見えないリンクなどを置いてそれを踏ませることで意図しない行動をさせる攻撃
答え c : ディレクトリ, d : クロスサイト, e : HTTP, f : ジャッキング

本文(設問4)

本文要約(設問4)

図表が多くていまいち要約にならぬ
[全社セキュリティ強化(続き)]
① A社診断項目は自動診断ツールJ(ツール名)と手動の２方法を組み合わせて診断手順書を作成した。
[WebサイトZの診断]
① 新規にWebサイトZをリリースするため、専門業者と診断チームが診断を実施する。
② 画面遷移図は図6、画面仕様は表2の通り。
③ 結果として検索画面からの遷移時にSQLインジェクションの脆弱性をが検出された。keywordの値をbag' and '1'='1とした場合は該当商品数が[g]件で、bag' and '1'='2とした場合は[h]件、bagとした場合は30件であった。
④ また、カレンダについてXSSが見つかり、https://www.z-site.com/calender?inputfieldid=[i]とし、警告ダイアログに"NG"を表示させたときのレスポンスは図9のようになった。
⑤ アクセス制御の不備や認可制御の欠落として、一般会員アカウントでログインし、商品一覧画面のURLにアクセス後、商品一覧画面で[j]すると有料会員限定商品を購入できてしまうことが分かった。
⑥ ③～⑤とCSRFへの対策を合わせて診断手順書を改定する。

問題文(設問4)

解説(設問4)

(1)はSQLインジェクションについてですが、SQL文に関する詳しい知識がないのと、ここで全容解説は流石に長いので飛ばします。ただ応用情報かどこかで見た通り、1=1のように常に真になるような設定にするとバグって全部の値を吐き出してしまうようになります。というのがgでNo.3と同じ30になります。また、1=2のような成り立たないものを入れると普通に偽になるので該当なしで0になります。
答え g : 30, h : 0

(2)はXSSについて、HTMLの記述です。まあHTMLやったことないとわかるわけないのですが
getElementById(‘‘);alert(‘NG‘); という表記を完成させるためにイが必要となります。
答え イ

(3)はアクセス制御の不備と認可制御の欠落について、表2を見ながらどのようにしたら一般会員が有料会員限定アイテムを買えるようになるかを考える。(う)は通常商品、(え)は有料会員限定アイテムについての記述ですが、URLが同じでPOSTデータのcodeが違うだけです。つまりcodeの値を書き換えてしまえば一般会員でも有料会員限定アイテムを買えるようになります。どうやってそのcodeの値を知るのかはよくわかりませんが
答え (う)の操作を実行するときに、codeの値を限定商品の値に書き換える

(4)はこれらを受けた対策。kもlもアクセス制御がうまくいってるかどうかの話をしているので、アクセス制御を受ける側と受けないアクセスできる側の複数アカウントがあれば、何ができて何ができないのか試すことができます。この問題の正解率が低かったらしいけれどみんなどんな間違え方をしたのかしら
答え k : 権限が異なる複数の, l : 許可されている操作の違い

本文(設問5,6)

本文要約(設問5,6)

① 今までの診断等を受けて各工程後のレビューによる作業の妥当性確認を行うことを義務付け、A社のセキュリティポリシと想定される脅威へのセキュリティ要件が盛り込まれているか、セキュリティ要件が機能か運用で満足されるか、Webセキュリティガイドに基づいて実装されているか、セキュリティ機能と運用が設計通りかどうかをテストしているか、適切な診断がなされているか、検出された脆弱性が修正されているかを見ることにした。
② 開発が外部に委託される場合に①の確認をするため、契約の研修条件に追加すべき記載内容を検討した。

問題文(設問5,6)

解説(設問5,6)

設問5が外部委託先への順守をどのように「確認」するか。やらせるかどうかではなく確認する方法を聞いています。要は外部委託先に確認できるエビデンスを出せる必要があるという話です。「やったよ!」と口で言われても信用には値しません。
答え 作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること
設問6は個々の脆弱性を基にWebセキュリティガイドをどのように改善するか。すごく一般的な話になっていますが、何かトラブルが起きたらその原因を調べて対策しましょうという話です。
答え 脆弱性の作りこみ原因を調査して、注意すべきポイントを追加する。

終わりに

過去一(2017年と2018年春しかやってない)難しい気もする
安全なウェブサイトの作り方は一通り読むことにします。

主な参考サイト

HTTPメソッドによるログ検知の違いとSSH認証方式【情報処理安全確保支援士試験 平成30年度 春期 午後2 問2 設問1】
GET、POSTどちらを使うべきか?
安全なウェブサイトの作り方 - 1.1 SQLインジェクション
安全なウェブサイトの作り方 - 1.3 パス名パラメータの未チェック/ディレクトリ・トラバーサル
安全なウェブサイトの作り方 - 1.6 CSRF(クロスサイト・リクエスト・フォージェリ)
安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落
安全なウェブサイトの作り方 - 1.7 HTTPヘッダ・インジェクション
HTTPヘッダインジェクション
安全なウェブサイトの作り方 - 1.8 メールヘッダ・インジェクション
安全なウェブサイトの作り方 - 1.9 クリックジャッキング
脆弱性診断の具体的な手順【情報処理安全確保支援士試験 平成30年度 春期 午後2 問2 設問4】