設問1
(1) 攻撃に使われる文字列がPOSTデータ内に含まれている場合
表1No.2に脆弱性Kの存在、攻撃手法Kのことが記載してあります。
この文からわかることは攻撃手法KはHTTPリクエストを用いた攻撃であることです。
その攻撃によるアクセスはサーバXが標準設定の場合ログに残らないとも記載があります。
ログが残らない攻撃として平成30年度春 午後2問1でもDOM型XSSが問題として上がりましたが、今回は攻撃者自身がHTTPリクエストを送信しているため違いそうです。
考えられるのはPOSTを利用した通信です。
GETの場合リクエストをURLの末尾に追記します。(ID、パスワードの入力なら、id=username&password=passのように)
そのため、URLのパラメータを黙視できます。Cookieも例外ではないため、セッションハイジャックの攻撃に繋がります。
しかし、POSTを利用したリクエストの場合、ボディ部(Cookieはhiddenフィールド)にリクエストを格納するため、URLを見ただけでは確認できず、ログにも残りません。
ログに残るのはアクセスしたURLのみです。
設問に関係ないですが注意したいのがPOSTを利用すると完全にデータが見えなくなるわけでは無い点。
通信の盗聴を行えば、普通に内容は見えます。
(2) WebサイトYの全ファイルとの比較
WebサイトXと同じシステム構成であるWebサイトYは表1No.5を確認すると外部からのアクセスは無く、改ざん痕跡もなかったとあるため、改ざんがあったかどうかはWebサイトYと比較すればよさそうです。
(3) 公開鍵認証方式
teratermでsshをするときはチャレンジレスポンス認証等もあるが、IPA的に？はSSHではパスワード認証方式と公開鍵認証方式の2種類がある、と認識しておけば良いのでしょうか。
基本情報技術者試験 平成26年度午後問1でも明言されている。
設問2
・Webサイトで利用しているOS、ミドルウェア及びWFの名称並びにそれぞれのバージョン情報
効率的に脆弱性情報の収集を行うため、Webサイト担当者に何を提供させるのか。
それはシステム情報です。組織が利用していないOSやミドルウェアの脆弱性情報を収集しても意味がなく、無駄ですよね。
それよりもサイトごとで利用しているOSやミドルウェアを管理しておけば、それに関する脆弱性情報をすることは効率的であると言えます。
設問3
c：ディレクトリ d：クロスサイト e：HTTP g：ジャッキング
・ディレクトリトラバーサル
「../]などを利用して、ユーザには公開されていないディレクトリにアクセスする攻撃。
対策はサーバでのアクセス権限の見直しや、「/」や「../」等の文字列が含まれていないかチェックし、エラー処理を行う設定にする。
・クロスサイトリクエストフォージュリ
利用者の意図しないリクエストがWebブラウザからWebサーバに送信され、ログイン中の利用者を装い、Webサイトの機能が勝手に実行されたりする攻撃
対策は長くなるので関連知識で紹介します。
・HTTPヘッダインジェクション
以下のサイトが非常に参考になりました。
HTTPヘッダ・インジェクションの対策まとめ
・クリックジャッキング
Webページのコンテンツ上に透明化した標的サイトのコンテンツを配置し、利用者が気づかないうちに標的サイト上で不正操作を実行する攻撃で、視覚的に利用者をだます。
対策はHTTPレスポンスヘッダにX-FRAME-OPTIONヘッダを出力すること。
設問4
(1) g：30 h：0
これはSQLインジェクションでどのような攻撃構文がわからない方でもわかった問題だと思います。(筆者もわかりません)
表4No.3のkeywordの値はbagで、該当商品数は30になっています。
bagしか指定されていないため、bagの出品合計数は30個で想像がつきます。
表4No.1の「g」はkeywordがbagであり(and)、1が1('1'='1')だった場合という条件ですが、条件的には揃っており、表4No.3と変わらないため、30です。
また、「h」はkeywordがbagであり(and)、**1が2('1'='2')**だった場合という条件になり、条件が揃わないため表示結果は0件になります。
SQLインジェクションの対策はエスケープ処理またはプレースホルダです。
・エスケープ処理：利用者の入力した値がプログラムとして意味を持つ文字列な場合、意味の無い文字列に変換する
・プレースホルダ：利用者の入力した値がプログラムとして意味を持つ文字列な場合、ただの文字列として処理する
(2) i：イ
飛ばします。
(3) j：(う)の操作を実行するときに、codeの値を限定商品の値に書き替える
(ウ)の脆弱性は、一般会員が有料会員限定の商品を購入できてしまうことです。
設問に「画面遷移を指定して」とあるため、(あ)~(え)のどれかを使用します。
まず、表3(ウ)の検出箇所は「商品画面一覧からの遷移」とあり、限定商品一覧も含め(う)か(え)に絞れます。
しかし、今回は一般会員が有料会員限定の商品を購入できるという脆弱性であるため、一般会員の見ている商品画面一覧である(う)だとわかります。
次に表2の(う)と(え)を確認すると、画面遷移のURLはどちらとも同じで、POSTデータで送信しているcodeだけが異なります。
そのため、codeを限定商品に書き換えさえしてしまえば一般会員でも限定商品が購入できてしまいます。
(4) k：権限が異なる複数の
** l：許可されている操作の違い**
「k」の直前に「アクセス制御の不備や認可制御の欠落を確認する」とあり、様々な権限をもったアカウントで、その権限通りの操作しかできないかを確認します。
設問5
・作業の妥当性を確認できる詳細なレビュー記録を委託先が提出していること
セキュリティガイドラインに沿って開発が行われているか確認するため、各工程でレビューを行っています。
これを確認するにはレビューで使用した資料や議事録等を提出してもらえればその妥当性というのは、わかると思います。
設問6
・脆弱性の作り込み原因を調査して、注意すべきポイントを追加する。
問題が漠然としています。
しかし、今回A社は問題が発生した都度、セキュリティガイドラインを更新しています。
(今回ガイドラインを更新することになった問題点は、ガイドライン第1版が抽象的でわかりづらいこと、P社の確認不足)
そのため、脆弱性が発見された都度、その原因の調査を行いセキュリティガイドラインへ追加、更新していけばいいと考えることもできます。