集中力がいい加減切れてきた午後II、、とりあえず問1のオレオレ解答を晒しておく。
問2はシングルサインオンの見るからに「知るかボケ」な感じだったので、迷うことなく1を選択。
問1は社会人やってソフトウェア開発のプロセスに乗っかって作ってみてこそ解けた感じがする。学生さんたちは「レビュー？なにそれ？」という人もいたんじゃないかなーと予想する。
設問1 a:ア b:イ
解説：
Java？そんなのしらんよ。勘だよ勘！ってのがホンネ（笑）
とりあえず
・stmtを宣言しているのがa
・bでSQLを実行しているんだろうな
くらいはさすがにわかる。
そんで、
・sqlという変数に「？」が入ってて、ここをstmt.setString(1,param)で置換してる？のかな？
・ということはstmtの宣言時には内部にsqlを取りこむものでないといけない。
・ということはSQL実行のbでは引数にsql入れる意味がない。
ってことで、なんとなくbはイと想像できた。
aはホントに勘なのだが、とりあえず明らかにフィルター（絞り込み）とかしてないからdoFilterなんてありえない。
バインド機構だからってbindって、あまりにも短絡的過ぎじゃないか。だいいち、JavaってStatementとかいういかにもベースクラス的なものに「？をsetStringで置換する」とかいう気の利いた機能盛り込むような言語じゃないだろ。お利口さんに派生クラスで実装を追加するもんじゃないか？ってことでPreparedStatementっぽい。よし。アだ。
Google検索してみたら、正解っぽかった。ふぅ。
設問2
（１）脆弱性が発見された場合に出戻りが発生し、修正により長い期間を要するため。
（２）設計する各コンポーネントに既知の脆弱性を含んでいないかを調査・確認する。
（３）セキュアなコードで書かれているか、既知の攻撃手法が適用できないかを有識者やツールを用いて確認する。
解説：
あまり自信はない。ただ、「修正は後の行程ほど大変」という一般法則があるし、「最後にちょちょっと脆弱性見てそれをリリースまでの半月で修正できるの？それまで6か月かけてきたプロジェクトだよ？」という主任の声が天から聞こえてきた(笑)ので、そのまま書いてみた。
レビューで脆弱性を見るって言うのはあまり経験がないので、とりあえずてきとーに書いた。
「セキュアプログラミング」っていう定石があってそれにのっとっているか、もう少し言うと、既知の「ありがちなミス」をしていないか、っていうのがポイントなんだろうな、ということでこういう解答に至った。
設問3
（１）利用者IDのパラメータに任意の利用者IDを取得するSQL条件文を含ませたHTTPリクエスト
（２）想定外の文字が含まれていないか、従業員テーブルに存在するIDか、を確認する。
解説：
午後1午後2を通して、もっとも自信がない。(1)の55文字制限が本当に微妙で何を書いて何を書かないかがホントに悩ましかった。
(1)について
とりあえずどこにインジェクションするかについては、顧客IDについては何の情報もなかったので、クッキーとかに書かれているとすると、それ勝手に書き換えたらログインできなくなるんじゃないか、ということで、利用者IDのほうに着目した。
利用者IDベタ書きなので、とりあえず 「' OR 1=1'」という常とう手段は使えそう。でも、問題文の「データの型チェック」というのはどこまでさしているんだ？単純にStringの型チェック？それとも特殊記号のサニタイズとかも含めてる？ うぎゃあああ意味わからん。IPAの試験問題作ったやつ出てこい！
ってわけで、都合よくStringの型チェックしかしてないんだろうと仮定して、ベタな解答に仕上げた。これ推敲だけで30分以上かけた気がする。
(2)について
SQLインジェクションの対策っていうベタすぎる問題。ここでも「データの型をチェック」の意味する範囲がわからなかったので、上記のStringであることしか確認してないと仮定。まずは従業員IDでクオテーションとかスペースとか使うことはないだろっていうのをチェック。でもこれじゃ字数が余るぞ？念のため、従業員IDリストに含まれるかどうかも確認しとくかー、ってことで上の解答に至る。
設問4
（１） 顧客ごとにテーブルあるいはデータベースを分けて、アクセス権も顧客ごとに設定する。
（２） ガイドラインに基づくチェックリスト付きのレビュー報告を委託先に義務付け、X社が確認・承認を行う。
いい加減集中力が切れてきたところ。
(1)について
ありえんやろ！なんで全部の顧客の情報が一つのテーブルに入っとるんよ！？
素人でもここまでやらんだろー。
ってことで、テーブル単位かDB単位で顧客を管理するように変更すべきだと。あとは、念のため顧客ごとにアクセス権（OSとかDBシステム提供の機能で）を設定したら、WebApp経由で特定のアクセス権で実行されても他のはPermission Deniedでしょ、って感じで。
(2)について
レビュー記録というシステムがないと、「レビューしましたー」だけで済ませられるとどこまで信用していいのか分からないんじゃないだろうか？ということで、コーディングガイドラインを守っていますだとか、そういう報告を含めた記録を委託先に提出してもらうようにせんとダメでしょう。うん。きっとそうだ。
知らん。
設問5
（１） c:ア
（２） FWのアクセス制御ルールでインターネット側からのTCP8080番ポートへのアクセスを拒否している。
（３） 設計に含まれる各コンポーネントの脆弱性に関する情報を定期的にチェックすること。
解説：
どういうわけか、最後に一気に楽なのが来た感じ。
(1)について・・・省略。当たり前やろ。
(2)について
この脆弱性がTCPの8080番にインターネット側からのなんとかかんとか、、、って書いてあるので、「え？そもそもインターネット側から8080番ポートとかって開けてたっけ？」ということを思い出す。ファイアウォールで遮断してるので、この攻撃のパケットはRejectされるはず。
(3)について
ミドルウェアでパッケージものだからって安心してるからこういうことになる。エンドユーザーはミドルウェアのことなんか知らないわけで、作ったもの全部に脆弱性がないかどうかが心配なはず。
また、設計途中に脆弱性が発見されるということもこのご時世だと珍しくはなさそう。使用しているコンポーネントについては定期的にチェックするに越したことはないはずだ。おれはやりたくないけど（笑）ってことでこういう解答に至る。
あああ、、どうか合格していてほしい
