D 社のネットワークでは静的に IP アドレスが付与され，各セグメント間の通信はステートフルパケットインスペクション型の FW で制限されている。FW のフィルタリングルールを表1に示す。
表1 FW のフィルタリングルール
従業員には，個人ごとに PC と利用者 ID が割り当てられており，自身の PC 上では，自身の利用者 ID に対して管理者権限が付与されている。利用者 ID は，LDAP サーバで一元管理されており，PC にログインする際，LDAP サーバで利用者認証が行われる。D 社の顧客情報は全て CRM サーバに保管されており，営業業務に携わる従業員は，PC から Web ブラウザで CRM サーバにアクセスして，顧客情報の登録・参照を行っている。
サーバ及び FW は，入退室管理されたサーバルーム内に設置されている。利用者 ID 作成などのサーバの運用は，サーバ管理者が，事前申請をした上で，管理用 PC から SSH でサーバにログインして行っている。SSH でログインする際も PC にログインする際と同様に，LDAP サーバで利用者認証が行われる。
D 社では，事前申請なしで CRM サーバへの SSH によるログインがあった場合，そのことを日次のバッチ処理によって顧客情報管理責任者である N 部長に電子メールで通知する仕組みを導入している。通知にはログイン時刻，SSH の接続元 IP アドレス及び利用者 ID が記載される。
〔セキュリティインシデントの発生〕
ある日，サーバ管理者の Y 主任の利用者 ID で，管理用 PC から CRM サーバにログインしたことを示す通知が N 部長に届いた。N 部長が，Y 主任に確認したところ，その時間帯にはログインしていないとのことであった。
Y 主任が CRM サーバの SSH 認証ログを確認すると，身に覚えがない自分のログイン（以下，不審ログインという）の記録が残っていた。Y 主任の報告を受けて，N 部長は，不正侵入のセキュリティインシデント（以下，インシデントという）が発生したと判断し，インターネット接続を遮断した上で，セキュリティ専門業者 Z 社に調査を依頼した。
Z 社の W 氏が，サーバへの不正侵入の有無，侵入手口及び顧客情報窃取の有無に関する調査を進めることになった。
〔サーバへの侵入手口の調査〕
W 氏は，まずサーバへの不正侵入の有無及び侵入手口の調査を行った。その調査結果を図2に示す。調査結果から，W 氏は図3に示す手順でサーバへの不正侵入が行われていたと推測した。
図2 W 氏の調査結果図3 W 氏が推測したサーバへの不正侵入手順（抜粋）
図3の2の通信が盗聴されている時点では，FW，管理用 PC 及び A さんの PC の ARP テーブルが，それぞれ表2～4に示すようになっていたと W 氏は推測した。
表2 盗聴されている時点の FW の ARP テーブル（抜粋）表3 盗聴されている時点の管理用 PC の ARP テーブル（抜粋）表4 盗聴されている時点の A さんの PC の ARP テーブル（抜粋）
図3の6の特定方法としては，管理用 PC の IP アドレスを総当たりで推測することも考えられるが，そのような方法が採られた場合に FW のフィルタリングルール d によって記録されるはずのログが残っていなかった。このことから，①通信の盗聴によって管理用 PC の IP アドレスが特定されたと W 氏は推測した。
二つ目は，A さんの PC から A さんが CRM サーバにアクセスした際の，A さんの PC 又は通信からの情報窃取である。調査した結果，A さんは CRM サーバにはアクセスしていないことが FW のログ及び聞き取りから確認できた。
三つ目は，その他の PC から CRM サーバにアクセスした際の通信からの情報窃取である。D 社内の Web ブラウザの設定は，②サーバ証明書の検証に失敗した場合は接続しない設定にしている。このことから，CRM サーバにアクセスした際の通信からの情報窃取はなかったと判断した。
W 氏は更に調査した結果，顧客情報の窃取はなかったと N 部長に報告した。
〔セキュリティ対策の実施〕
Y 主任は今回のインシデントを受けて，まず，マルウェアの駆除，ARP テーブルの初期化，全利用者 ID のパスワード変更などの暫定対応を行った。その後，W 氏の助言を受けながら，今回のように社内ネットワークに侵入された場合の被害拡大を防ぐために，社内ネットワークにおいて，二つのセキュリティ対策を実施することにした。
第一に，図3の8を防ぐために，図4のようにネットワーク構成を変更し，表5のように FW のフィルタリングルールを変更することにした。これらの変更によって，③図3の6が行われることも防ぐことができる。また，④仮に図3の6とは異なる方法で管理用 PC の IP アドレスが特定され，図3の8が試みられた場合でも，TCP コネクションの確立を防ぐことができる。
第二に，図3の4を防ぐために，LDAP サーバへの通信では LDAP over TLS を利用することにした。
図4 変更後の D 社のネットワーク構成表5 変更後の FW のフィルタリングルール
これらの対策は N 部長によって承認され，今回と同様のインシデントに対する社内ネットワークのセキュリティ耐性が高まることになった。
従業員 A さんの PC が遠隔操作型マルウェアに感染していたが，その他のサーバ及び PC のマルウェア感染は確認されなかった。
図3
2. A さんの PC 上で ARP ポイズニングを用いて，通信を盗聴する。
表2 では，FW の ARP テーブルが管理用 PC（192.168.0.1）も PC（192.168.0.200）も xx:xx:xx:aa:aa:02 に対応付けている。図1 でこの MAC アドレスは（カ）の 192.168.0.2 の PC で，マルウェアに感染していたのは A さんの PC だけなので，（カ）が A さんの PC である。FW は管理用 PC 宛ての通信を A さんの PC へ送っている。逆向きの通信も A さんの PC を通すには，管理用 PC の ARP テーブルで FW（192.168.0.254）を A さんの PC の MAC アドレスに書き換えればよい。よって a は（カ）である。
一方，A さんの PC は盗聴した通信を本来の宛先へ中継しなければ通信が途切れて気付かれる。そのため A さんの PC 自身の ARP テーブルは正しい対応のままで，192.168.0.1 は管理用 PC の本物の MAC アドレス（オ），192.168.0.254 は FW の PC セグメント側の本物の MAC アドレス（エ）になる。b はオ，c はエである。ARP は IP アドレスから MAC アドレスを求める仕組みで（RFC 826），受け取った ARP の内容で対応表を更新するため，偽の ARP を送り付けると書き換えられる。
字数制限の無い記号選択である。講評は a の正答率が b，c より低かったとしている。管理用 PC の ARP テーブルで書き換わるのは“通信相手（ゲートウェイである FW）”の行であり，管理用 PC 自身や攻撃者自身の対応は正しいままと考えると取り違えにくい。（ア）は FW のサーバセグメント側で，PC セグメントの機器の ARP テーブルには現れない。
管理用 PC の IP アドレスを総当たりで推測することも考えられるが，そのような方法が採られた場合に FW のフィルタリングルール d によって記録されるはずのログが残っていなかった。
表1 項番5
項番5：PC セグメント，サーバセグメント，全て，拒否，する。
表1 項番4
項番4：管理用 PC，サーバセグメント，SSH，許可，する。
総当たりでは，A さんの PC が送信元 IP アドレスを次々に変えながらサーバの SSH ポートへアクセスし，通る IP アドレスを探すことになる。管理用 PC 以外の IP アドレスを名乗った通信は，表1 の項番4 に一致せず，項番5（PC セグメントからサーバセグメントへの全ての通信を拒否，ログを記録する）で拒否される。外れの試行がたくさん出るので，項番5 のログが大量に残るはずである。d は 5 である。
ログが残っていなかったので，総当たりではなく通信の盗聴で管理用 PC の IP アドレスを知った，と W 氏は推測した（下線①）。項番1～3 は宛先やサービスが SSH の試行とは合わず，項番2 はそもそもログを記録しない。
本文中の下線①について，攻撃者が管理用 PC の IP アドレスを特定するために盗聴したのはどのような通信か。送信元，宛先及びサービスを，それぞれ解答群の中から選び，記号で答えよ。解答群 ア ARP イ A さんの PC ウ FW エ HTTP over TLS オ LDAP カ LDAP サーバ キ SSH ク インターネット ケ 管理用 PC
〔送信元〕解答例
ケ
〔宛先〕解答例
カ
〔サービス〕解答例
キ
解説
本文の根拠
表1 項番4
項番4：管理用 PC，サーバセグメント，SSH，許可，する。
本文
利用者 ID 作成などのサーバの運用は，サーバ管理者が，事前申請をした上で，管理用 PC から SSH でサーバにログインして行っている。
本文
利用者 ID は，LDAP サーバで一元管理されており
図3
6. A さんの PC 上で通信を盗聴して，管理用 PC の IP アドレスを特定する。
PC セグメントからサーバセグメントへの SSH は，表1 の項番4 で管理用 PC にだけ許されている。そのため，PC セグメントからサーバへ向かう SSH の通信を盗聴できれば，その送信元 IP アドレスが管理用 PC のものだと分かる。送信元は管理用 PC（ケ），サービスは SSH（キ）である。宛先は，利用者 ID を一元管理し，利用者 ID 作成などの運用で管理用 PC から SSH でログインされる LDAP サーバ（カ）である。
LDAP の通信は全ての PC から LDAP サーバへ流れる（表1 項番2）ので，それを盗聴しても管理用 PC とほかの PC の区別は付かない。区別の決め手は，管理用 PC だけが使うサービスの SSH である。ARP ポイズニングで管理用 PC と FW の間の通信が A さんの PC を経由していれば（設問1(1)），SSH の中身は暗号化されていても，IP ヘッダの送信元・宛先は見える。
字数制限の無い記号選択である。HTTP over TLS はどの PC からも CRM サーバへ流れ，インターネットや FW は SSH の宛先ではない。“盗聴したのはパスワードを得るための LDAP 通信”と考えるとオを選びがちだが，問われているのは IP アドレスを特定するための通信である。
設問2解答欄2つ
本文中の下線②について，このような設定にすることは，A さんの PC に侵入した攻撃者によって行われるどのような攻撃への対策になるか。攻撃名を 10 字以内で答えよ。また，攻撃に際して詐称される対象の機器名を図1中から選び，答えよ。
〔攻撃名〕解答例
中間者攻撃
〔機器名〕解答例
CRMサーバ
解説
本文の根拠
本文（下線②）
D 社内の Web ブラウザの設定は，②サーバ証明書の検証に失敗した場合は接続しない設定にしている。
本文
三つ目は，その他の PC から CRM サーバにアクセスした際の通信からの情報窃取である。
表1 項番3
項番3：PC セグメント，CRM サーバ，HTTP over TLS，許可，する。
A さんの PC は ARP ポイズニングで通信を中継できる位置にいる。そこで攻撃者が CRM サーバになりすまし，ほかの PC からの HTTP over TLS の通信をいったん自分で受けて復号し，改めて本物の CRM サーバへ暗号化して送れば，暗号化された通信でも中身を読める。これが中間者攻撃で，詐称される機器は CRM サーバである。
サーバ管理セグメント：FW から経路(B)で L2SW につながり，L2SW に管理用 PC がつながる。
図3
6. A さんの PC 上で通信を盗聴して，管理用 PC の IP アドレスを特定する。
図4 では管理用 PC がサーバ管理セグメントに移り，管理用 PC とサーバの間の通信は（B）と（A）を通る。PC セグメント（C）には流れなくなるので，PC セグメントにある A さんの PC は，その通信を盗聴できない。図3 の6（盗聴による管理用 PC の IP アドレスの特定）はできなくなる。
ARP はセグメントの中だけで使われる仕組みで，ARP ポイズニングで書き換えられるのは同じセグメントにある機器の ARP テーブルだけである。そのため，セグメントを分けると，ほかのセグメントの機器の通信は A さんの PC を経由させられない。講評も，対象の通信が PC セグメントを通過しなくなり盗聴を防げることがよく理解されていた，としている。
字数は 35 字以内で，解答例は 31 字。“PC セグメント内に”“管理用 PC とサーバ間の通信が”“流れなくなる”の三つをそろえる。“セグメントを分離したから”だけでは，下線③の理由として何が変わったかが伝わらない。
A さんの PC は PC セグメントにあるので，管理用 PC の IP アドレスを詐称した SYN パケットは（C）から FW に入り，（A）を通ってサーバに届く。サーバは SYN-ACK パケットを送信元 IP アドレス，つまり本物の管理用 PC 宛てに返すので，FW はそれをサーバ管理セグメントへ送る。SYN-ACK は（A）から（B）へ進み，A さんの PC には届かない。SYN パケットは“(C)→(A)”，SYN-ACK パケットは“(A)→(B)”である。
TCP のコネクションは SYN，SYN-ACK，ACK の3回のやり取りで確立する。攻撃者は SYN-ACK を受け取れないので，続きを正しく返せず，コネクションは確立しない。図1 の構成では管理用 PC も PC セグメントにあり，ARP ポイズニングで SYN-ACK を横取りできたが，図4 ではそれができなくなった。
字数制限は無く，経路を通過する順に記号で答える。SYN-ACK を“(A)→(C)”と答えるのは，サーバが送信元の実際の位置に返すと考える誤りである。返す先は IP アドレスで決まるので，管理用 PC のあるサーバ管理セグメントになる。
出典：平成29年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問1（表記を一部改変）
問2 Webサイトのセキュリティ対策
Web サイトのセキュリティ対策に関する次の記述を読んで，設問1～3に答えよ。
E 社は，従業員数 200 名の情報サービス事業者である。E 社は，3 年前から Web サイトα（以下，サイトαという）を利用して，次のような機能をもつ会員制の飲食店情報提供サービスを行っている。
飲食店情報の検索
飲食店情報に関する掲示板での投稿
新規登録情報の，会員への電子メール（以下，メールという）による通知
サイトαに対する脆弱性修正プログラムの適用や，コンテンツ作成などの日々の作業は，情報提供サービス担当チームが行っている。チームはリーダの Q さんと 5 名のメンバで構成されている。サイトαで稼働している Web アプリケーションソフトウェアは，情報提供サービス担当チームがベンダに開発と保守を委託している。サイトαの画面遷移図を図1に，画面遷移の仕様を表1に示す。
ある日，サイトαの利用者 L 氏から，“今朝 9 時にログインし，サイトαを利用していたら，10 時に急にログアウトさせられ，その後ログインできなくなった。パスワードを再設定しようとしたが，エラーが表示され，再設定できない。”という内容のメールが E 社宛てに届き，他にも同様の問合せが数件来た。
情報提供サービス担当チームの X さんがサイトαの会員情報データベースにアクセスし，L 氏の情報を確認したところ，退会処理が完了していた。X さんは，誰かが嫌がらせ目的で L 氏のアカウントで不正ログインし，退会処理を行った可能性を疑った。①X さんは，L 氏に詳細な利用状況を確認し，その確認内容とログイン記録を照合した結果から，L 氏のアカウントは少なくとも今日は不正ログインされていないとの結論に至った。
X さんが，ログインできなくなる前にどのような操作をしたかを L 氏に聞いたところ，サイトα内の掲示板に投稿していた人のプロフィール画面を見て，そこに記載されていたリンクをクリックしたとのことであった。リンク先は，別サイトの URL であり，かつ，X さんが確認した時点ではリンク先は既に削除されていた。
X さんは，今回の事象が起きたのはサイトαに脆弱性があるからかもしれないと考え，セキュリティ専門業者 J 社に Web アプリケーションソフトウェアの脆弱性検査（以下，WebAP 検査という）を依頼することにした。WebAP 検査の結果，脆弱性が二つ（以下，脆弱性1，脆弱性2という）検出された。
〔脆弱性1について〕
脆弱性1は a の脆弱性であった。脆弱性1を確認した手順を表2に示す。
表2 脆弱性1を確認した手順
次は，X さんが J 社の情報処理安全確保支援士 K 氏から，脆弱性1についての報告を受けた時の会話である。
X さん：開発委託時の要件に a の脆弱性への対策を含めていたので，脆弱性1の対策はできていると思っていました。
K 氏：対策を試みたけれど，プログラムの実装に不備があったようです。プロフィール確認画面についても脆弱性1が確認されています。
X さん：そうですか。退会処理が行われてしまった利用者がクリックしたリンク先はどのようなものだったのでしょうか。
K 氏：例えば，図2のような HTML です。この HTML は，表2中の項番 b のような動作を Web ブラウザにさせます。
X さん：変更操作がある画面のうち，パスワード変更画面は，そもそも a の脆弱性への対策をしていませんが，問題ありませんか。
K 氏：パスワード変更画面では表1にあるように，c を入力させる仕様です。c は攻撃者が d 情報であることを前提としてよいので，問題ありません。画面遷移(お)のような実装の不備もないようでした。
図2 退会処理が行われてしまう HTML
〔脆弱性2について〕
脆弱性2は“クロスサイトスクリプティング”であった。脆弱性2を確認したのはプロフィール入力・変更画面であった。次は K 氏と X さんとの会話である。
K 氏：プロフィール入力・変更画面は，利用者が入力できる HTML の要素が制限されています。しかし，例えば“<b>”タグ中に，②特定の属性を指定することによってスクリプトの実行が可能です。スクリプト実行の結果，Cookie の属性の設定によっては，Cookie の情報が盗まれます。これを用いて，g が行われ，勝手にプロフィールを閲覧されたり，変更されたりするおそれがあります。
X さん：そういうことですか。では，利用者が入力できる HTML の要素の制限は変えずに，h という仕様に変更したいと思います。
K 氏：それで問題ありません。
X さんは，二つの脆弱性について，対策をベンダに依頼した。対策後，J 社に WebAP 検査を依頼し，問題がないことを確認した。X さんは，リリース前の WebAP 検査の義務化を Q さんに提案し，採用された。
ログイン記録に残るのは利用者 ID と時刻だけである。L 氏の利用者 ID による今日のログインが何回記録されているかを数え，L 氏本人が今日ログインしたと言っている回数と一致すれば，L 氏以外の者によるログインは無かったことになる。L 氏に確認するのは“L氏が今日ログインしたと言っている回数”，ログイン記録から抜き出すのは“L氏の利用者IDを用いた今日のログイン回数”である。
L 氏は 9 時にログインし，10 時に急にログアウトさせられて，その後はログインできなくなったと言っている。本人の言う回数より記録が多ければ，誰かが L 氏のアカウントでログインしたことになる。下線①は“少なくとも今日は”と範囲を区切っているので，比べるのは今日のログインに限られる。講評も，何と何の値が一致すればよいかを本文から読み取ってほしかった，としている。
L 氏は別サイトのリンクをクリックしただけで，ログイン中の自分のアカウントの退会処理が行われてしまった。図2 の HTML は，別サイトから E 社の退会処理の URL へ POST を送らせるものである。利用者の意図しない処理要求を，ログイン済みの利用者の Web ブラウザから送らせる攻撃なので，脆弱性1 はクロスサイトリクエストフォージェリである。
サイトαのセッション ID（JSESSIONID）は Cookie に格納されている。スクリプトで Cookie を盗まれると，攻撃者はそのセッション ID を自分の Web ブラウザに設定して，利用者になりすませる。セッション ID を奪ってセッションを乗っ取る攻撃なので，g はセッションハイジャックである。
F 社は，従業員数 300 名のソフトウェア開発会社である。F 社では，社外のクラウドサービスを試行的に導入し始めており，交通費精算サービス，グループウェアサービス，オンラインストレージサービスの三つを現在利用している。これらのクラウドサービスには，各クラウドサービスの利用者 ID とパスワードを用いてログインする。これらのクラウドサービスは，社内からの利用に限定するという社内ルールを定めている。
ある日，交通費精算サービスで従業員の振込先口座が勝手に変更されたとの相談が，経理部から情報システム部の C 主任にあった。R さんの振込先口座が F 社指定の銀行以外の口座に変更されていたので，R さんに確認したところ，本人による変更ではないことが分かったとのことであった。
C 主任は，社外の攻撃者による不正アクセスの可能性を考え，交通費精算サービスに記録されているログイン記録を調査した。F 社で利用しているクラウドサービスではログイン記録として，アクセス日時，利用者 ID，接続元 IP アドレス，接続先 URL が記録されている。調査の結果，R さんの利用者 ID によるログイン記録には，接続元 IP アドレスとして，F 社の IP アドレス以外に，海外の IP アドレスが一つあった。R さんに話を聞いたところ，このログインには心当たりがないということであった。R さんに更に詳しく話を聞いたところ，4 月 9 日に交通費精算サービスから登録情報の確認を促す電子メール（以下，メールという）が 1 通，R さんの私用メールアドレスに届いており，R さんが 4 月 10 日にそのメールを自宅で読み，記載内容に従って自宅からログイン操作を行ったことが分かった。そのメールを R さんから転送してもらい，C 主任がメールに記載されていた URL を確認したところ，交通費精算サービスを模したフィッシングサイトであった。C 主任はこのフィッシングサイトから利用者 ID とパスワードが盗まれた可能性が高いと判断した。そこで，R さんがパスワードを使い回している可能性も考慮して，他のクラウドサービスに対する R さんのログイン記録も調査した。その結果，他のクラウドサービスに対する R さんの利用者 ID を用いたログインは，F 社からのものだけであることを確認した。
今回は金銭的な損害に至らなかったが，情報システム部の B 部長は早急な対策が必要と考え，C 主任に暫定対策の実施と根本的な対策の検討を指示した。
〔暫定対策の実施と根本的な対策の検討〕
C 主任はまず，暫定対策として三つの対策を行うことにした。第一に，フィッシングメールに注意するよう従業員に周知した。第二に，F 社で利用している各クラウドサービスに対するログイン記録を C 主任が調査して，①F 社以外からのログインがあった利用者 ID を特定し，その利用者 ID を利用する者にはパスワードを変更させることにした。第三に，F 社以外からのログインを検知できるよう，ログイン記録の監視を行うことにした。C 主任は暫定対策が完了したことを確認し，根本的な対策の検討を開始した。
C 主任は，今回の不正アクセスの原因の一つが，F 社の IP アドレス以外からクラウドサービスへのログインが可能になっていたことにあると考え，F 社の IP アドレス以外からのログインを制限することが可能か調査した。F 社で利用しているクラウドサービスのうち，グループウェアサービスだけは，接続元 IP アドレスを制限する機能を備えていたので，その機能を有効化し，社内からだけログインできるように設定した。しかし，残りのクラウドサービスは接続元 IP アドレスの制限機能を備えていなかった。
本文中の下線①について，条件を満たす利用者 ID を特定するためには，どのような条件を満たすログイン記録を抽出すればよいか。満たすべき条件を 35 字以内で述べよ。
解答例
接続元IPアドレスがF社のグローバルIPアドレスではないこと
解説
本文の根拠
〔クラウドサービスへの不正アクセス〕
F 社で利用しているクラウドサービスではログイン記録として，アクセス日時，利用者 ID，接続元 IP アドレス，接続先 URL が記録されている。
〔クラウドサービスへの不正アクセス〕
接続元 IP アドレスとして，F 社の IP アドレス以外に，海外の IP アドレスが一つあった。
本文（下線①）
①F 社以外からのログインがあった利用者 ID を特定し
下線①で特定したいのは，F 社以外からログインされた利用者 ID である。クラウドサービスのログイン記録には接続元 IP アドレスが残るので，接続元 IP アドレスが F 社のものでない記録を抜き出し，その利用者 ID を拾えばよい。条件は“接続元IPアドレスがF社のグローバルIPアドレスではないこと”である。
R さんの不正アクセスも，接続元 IP アドレスに F 社以外（海外）のものがあったことで見つかった。端末はプロキシサーバを経由してクラウドサービスを使うので，社内からのログインは F 社のインターネット側の IP アドレス（グローバル IP アドレス）から来る。講評も，クラウドサービス側に記録されるログイン記録がよく理解されていた，としている。
字数は 35 字以内で，解答例は 30 字。クラウドサービス側から見えるのは F 社の社内の IP アドレスではなく，インターネット側の“グローバル IP アドレス”なので，そう明記する。アクセス日時や接続先 URL は，社外からのログインかどうかの判断には使えない。
![枠内の HTML（20行）。1 <html> 2 <head> 3 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 4 </head> 5 <body> 6 <iframe src="ifrm1.html" width="1" height="1" name="ifrm1"></iframe> 7 <iframe src="ifrm2.html" width="1" height="1" name="ifrm2"></iframe> 8 <form target="ifrm1" method="POST" action="https://www.e-sha.co.jp/member/taikai"> 9 <input type="text" name="action_id" value="［ e ］"> 10 <input type="text" name="taikai_message" value="OK"> 11 <input type="submit"> 12 </form> 13 <form target="ifrm2" method="POST" action="https://www.e-sha.co.jp/member/taikai"> 14 <input type="text" name="action_id" value="［ f ］"> 15 <input type="submit"> 16 </form> 17 <script>setTimeout('document.forms[0].submit()',0);</script> 18 <script>setTimeout('document.forms[1].submit()',1000);</script> 19 </body> 20 </html>](/data/figures/2017h29h-sc-pm1/q2-f2.png)
