1.POSTとGETという2つのメソッド
HTTPのメソッドには8つのメソッドがある。
POSTとGETの動作の違いをPHPのスクリプトで体験してみよう。
分かりやすさを優先して、余分なものは全て消してある。実際のプログラムはもう少し整形することになるだろう。
ここではあくまでも、仕組みをシンプルにお伝えすることを優先している。
(1)スクリプトの内容
◆login.html
| ログイン画面<br> <FORM ACTION="result.php" METHOD="POST"> ID：<INPUT TYPE="text" NAME="id" VALUE=""><br> Password：<INPUT TYPE="password" NAME="password" VALUE=""><br> <INPUT TYPE="submit" VALUE="Login"> </FORM> |
実際の画面は以下のようになる 
◆result.php ※結果表示のスクリプト
| <?php print($_REQUEST['id']); ?> さん、ログインしました。 |
(2)POSTの場合
IDとしてuser1と、パスワードを入力してLoginボタンを押す。その後の画面（result.php）は以下のようになる。
URLの部分をよく見て、次のGETを見てほしい
(3)GETの場合
login.htmlの赤字の「POST」部分を「GET」に変更して実行する。
GETの場合は、以下のように、入力した情報がURLに表示される。ログインIDやパスワードが漏えいするので、これはよくない。それで、POSTが使われる。
http://127.0.0.1/result.php?id=user1&password=pass
なるほど。
じゃあ、GETは使われないのですね？
そうでもない。Yahoo！やGoogleの検索ではURLに値が表示される。おそらくGETで処理しているはずだ。
以下は、Yahoo!にて「network」というキーワードで検索した結果である。URLに p=network の表示がある。
これにより、この検索結果のURLを保存しておいたり、誰かに共有することも可能であり、それは一つの利点である。
また、Referer能により、リンク先にリンク元の情報が送られる。このようにGETを利用してURLに情報が埋めこまれているから、どの検索エンジンのどのキーワードでリンク先に来たかが分かる。これによって、アクセス元の詳細な分析も可能になる。
Googleの場合は、さらにシンプルである。
たとえば、「security」というキーワードを検索すると、結果のURLは以下。
https://www.google.co.jp/#q=security
◆参考：Webサーバを建てて、いろいろと実際に体験してみよう
Webサーバの簡単なたてかた。Windows7や8ではIISで立てられる。ASPによるプログラミングも簡単である。後日きちんと書きたい。 ツールとしては、IPAから以下が公開されている。最低限の手間と時間はかかるが、有効だと思う。
2.referer
HTTPでは、どのサイトから訪れたのかを記録するフィールドがある。これがrefererである。
これにより、ホームページのアクセス元の分析などが可能になる。どんなキーワードで検索されたかも分かるという利点もある。たとえば、Goolgeで「security」と入力して検索したとする。すると、検索結果は以下のようになる。
https://www.google.co.jp/#q=security
その検索結果のとあるサイトをクリックすると、Refererによって、上記のURLが通知される。このことから、Googleの「security」という検索キーワードをもとに、サイトを訪れたことが分かり、便利と言える。これは、検索エンジンがPOSTではなくGETメソッドを利用しているから、このようにURLに情報を付与する。
しかし、セッション管理でGETメソッドを利用している場合、問題がある。URLにセッション情報が記載されるので、リンク先にセッション情報が漏えいする。
参考であるが、情報処理安全確保支援士試験の過去問H26年春SC午後Ⅰ問1では、以下の記述がある。
| GETメソッドではなくPOSTメソッドを使用しておかないと、HTTPヘッダ内のフィールドが原因で、バナー広告に設定されたリンク先のWebサーバへセッションIDが漏えいすることが考えられるね。 |
★詳しくは、キャプチャを付けたり、図にして解説するつもりだ。
3.HSTS
(1)HSTSとは
HSTS（HTTP Strict Transport Security）に関して情報処理安全確保支援士試験の過去問（H26秋SC午後Ⅱ問2）では、「HSTSとは, WebサイトがHTTPSの使用をブラウザに強制させる機能」と述べています。HSTSのフルスペルにあるように、Strict（厳格な）セキュリティを保つ機能です。
|
Q.なぜ、HTTP通信はHTTPS通信と比べてセキュリティが不十分なのか、理由を述べよ。 |
↓
↓
↓
↓
↓
A.HTTP通信だと、通信が暗号化されていません。また、サーバ証明書の確認もできないので、偽りのサーバに接続させられる可能性もあるのです。
|
Q.たとえば、UFJ銀行の正規のドメイン「https://direct.bk.mufg.jp/」に接続したとする。HTTPの場合、偽のサーバに接続させられるようなことが実際にあるのか。あるのであれば、どういう攻撃によってか。 |
↓
↓
↓
↓
↓
A.中間者攻撃や、DNSキャッシュポイズニングによって可能です。たとえばDNSキャッシュポイズニングの攻撃を受けると、正しURLを入れたとしても、違うサーバに接続してしまうリスクがあります。
そこで、HTTPではなく、HTTPSでの通信を強制させます。
なるほど。では、HTTPで接続してきたら、HTTPSのサイトにリダイレクトさせればいいですね？
考え方はあっていますが、リダイレクトではありません。リダイレクトだと、安全とは言えないのです。
|
Q.なぜ、HTTPSへのリダイレクトだと不十分なのか。 |
↓
↓
↓
↓
↓
A.最初の通信がHTTPだと、この時点で情報を取得されたり、サーバ証明書を確認できないので、嘘のサイトに接続している可能性があります。
なので、最初からHTTPSで通信させなければいけません。
そんなことできるんですか？
たしかに、完全にはできません。1回目はHTTPで接続してくる可能性があります。ですが、一度、Webサーバに通信したら、WebサーバがHSTSの仕組みを使って、「次回からはHTTPSで通信してください」と通知すればいいのです。そして、そのことをブラウザが覚えておけばいいのです。であれば、今後はHTTPで通信をすることが無くなります。
具体的には、最初の接続はHTTPでも受け付けますが、この応答（HTTPレスポンス）のStrict-Transport-Securityヘッダフィールドを使ってHTTPSを強制します。このときHTTPSを強制する適用範囲としてサブドメインを含むかや、HSTSのポリシーを保存しておくキャッシュ期間（max-age）なども指定します。
じゃあ、ブラウザもHSTSに対応している必要がありますね。
もちろんです。
わかりました。HSTSのポリシーを伝えるとともに、httpでアクセスしてきたユーザに対し、https通信にリダイレクトさせるんですね
そのとおり。ただ、ちょっと誤解しないようにしてもらいたいのが、HTTPSのページをレスポンスで返すのではなく、HTTPSに切り替えるよう、ブラウザに伝えます。具体的には、リダイレクト先のページを通知します。そして、ブラウザから再度HTTPSでページにアクセスをしてもらいます。
(2)HSTSが有効になるまでの流れ
情報処理安全確保支援士試験の過去問（H26秋SC午後Ⅱ問２）をベースに、HSTSがブラウザで有効になる通信の流れをみてみましょう。
|
HSTSがブラウザで有効となるまでの通信の流れを，図4に示す。（中略）HSTSは, HTTPS 応答のヘッダに〔 i 〕を指定することによって有効となる。
図4 HSTSがブラウザで有効となるまでの通信の流れ |
図4は，問題文にあるように、「HSTSがブラウザで有効となるまでの通信の流れ」です。利用者のブラウザは、普通に通信をするだけです。HSTSのための特別な設定は不要です。ただ、ブラウザがHSTSに対応している必要があります。
Webサイトからは、HTTPS応答にHSTSを有効化するための[ i ：Strict Transport Security ]を含めます。
HTSTが有効になるには、利用者はHTTPSで通信を開始する必要があります。HTTPでは有効になりません。HTTPだと、嘘のHSTS情報が送信される可能性もあるからです。
では、HTTPでアクセスした場合はどうなりますか？
Webサーバがブラウザに対して、HTTPSのサイトへのリダイレクトを指示します。その後、HTTPSで通信した際に、HSTSが有効になります。また、HSTSが有効になり、HSTSの有効期限内の場合は、ブラウザが自動でHTTPSに変更して通信をします。（以下、同じ過去問を参照）
|
また, HSTSが有効になったブラウザのアドレスバーに“http://www.example.jp/”を入力した場合のブラウザの挙動を，図5に示す。（後半略）
図5 HSTSが有効になったブラウザの挙動 |
(3)ブラウザにてHSTSの設定をみてみよう。
chromeブラウザでHSTSの設定を確認します。URLに「chrome://net-internals/#hsts」を入れるとHSTSの設定が表示されます。
ここで、Query HSTS/PKP domainに「www.ipa.go.jp」と入れ、「Query」ボタンを押しましょう。STSのドメイン（www.ipa.go.jp）やサブドメインを含むのか（Falseなので含まない）などが記載されています。
解説図4 ChromeでのHSTS設定例
ブラウザがこの情報を保持しているので、今後こうなっていると、HTTPで通信しようとしても、ブラウザが強制的にHTTPSで通信します。お時間がある方は、パケットキャプチャで確認してみるといいでしょう。HTTPプロトコルの通信が存在しないことを確認することができます。
(4)過去問を解いてみよう
❶H30秋NW午前Ⅱ
|
問18 WebサイトがWebブラウザに対して,指定された期間において,当該Webサイトへのアクセスをhttpsで行うように指示するHTTPレスポンスヘッダフィールドはどれか。 ア Content-Security-Policy ウ X-Content-Type-Options イ Strict-Transport-Security エ X-XSS-Protection |
↓
↓
↓
↓
↓
正解 イ
❷H30秋午前Ⅱ
|
問12 HTTP Strict Transport Security (HSTS)の動作はどれか。 ア HTTP over TLS (HTTPS)によって接続しているとき,EV SSL 証明書であることを利用者が容易に識別できるように, Webブラウザのアドレス表示部分を緑色 に表示する。 イ Webサーバからコンテンツをダウンロードするとき,どの文字列が秘密情報か を判定できないように圧縮する。 ウ WebサーバとWebブラウザとの間のTLSのハンドシェイクにおいて,一度確立 したセッションとは別の新たなセッションを確立するとき,既に確立したセッシ ョンを使って改めてハンドシェイクを行う。 エ Webサイトにアクセスすると, Webブラウザは,以降の指定された期間,当該 サイトには全てHTTPSによって接続する。 |
↓
↓
↓
↓
↓
正解 エ
❸H26秋SC午後Ⅱ問2
|
正規のWebサイトでHSTSが有効になるように設定していない場合，正規のWebサイトがHTTPS通信だけを受け付けるように構成していても，中間者攻撃が行われると、⑤ブラウザがHTTP通信で接続してしまい,中間者によって通信を盗聴されてしまう。 利用者は毎回〔 j 〕ことでこの攻撃を受けても気付くことができる。しかし，〔 j 〕ことを利用者に徹底させるのは難しいので, HSTSのプロトコルが開発され, 2012年にRFC 6797 として公開された。その後，この機能に対応するブラウザが増えている。 |
↓
↓
↓
↓
↓
設問3(5)ですが、中間者攻撃を受けないようにします。それは、HTTPSで通信をして、Webサーバの証明書が正規のものかを確認することです。
解答例：ブラウザのアドレスバーの情報で，httpsで通信していることを確認する。
設問3(6)ですが、HTTPで通信をすると、HSTSは有効にはなりません。この場合、たとえば、DNSキャッシュポイズニングなどで違うサーバに接続させられる可能性があります。そのサーバが中間者となり、仮に正規のサーバと通信できたとしても、情報を搾取されるリスクがあります。
解答例：初回にブラウザでWebサイトへhttpでアクセスした場合
4.その他
(1)Webビーコン
beaconとは標識などを意味する言葉であり、Webビーコンとは、WebサイトやHTMLメールなどに埋め込まれた小さな画像のことである。
Webバグと言われることもある。バグといってもプログラムの誤りを表わすバグという意味ではない。
一体、何の目的で、そんなことをするんですか？
アクセスしたユーザのIPアドレスなどを把握するためである。IPアドレスや時刻などを元に、アクセス履歴を分析することができる。過去問では、次のように述べられている。
| 「webページなどに小さい画像を埋め込み、利用者のアクセス動向などの情報を収集する仕組み（H21春FE午前問42）」 |
メールを送っても、それが読まれたかどうかは分からない。
そこで、Webビーコンの登場である。もしメール受信者がHTMLメールを開くと、埋め込まれた画像ファイルのリンクがサーバに通信をする。つまり、履歴が残るので、読んだかどうかが分かる。しかも、ユーザ毎に違う画像をリンクさせておけば、誰がアクセスしたかまで分かる。
Webビーコンを利用することで個人情報が漏えいすることはないが、利用者に無断で情報収集することには一部批判がある。そこで、SBIのサイトでは、WebビーコンとCookieを利用してアクセス履歴をとっていることを公表している。
(2)プロキシツールによる検査
IPAの「『セキュア・プログラミング講座 （Webアプリケーション編）』 ブートアップセミナー」（http://www.ipa.go.jp/files/000030878.pdf）では、ローカルプロキシツールの例として、OWASP ZAP、Fiddler、Burp Proxyが挙げられている。
最初に掲載されているOWASP ZAPが無償であることからも利用するにはいいと思う。
①OWASP ZAPダウンロード
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
から、Download ZAP
②JREのダウンロード
③OWASP ZAPを使った脆弱性診断
以下に解説があるが、スパイダー機能でURLを見つけ出し、そのURLに対してスキャンをする（攻撃>動的スキャン）
http://gihyo.jp/dev/column/newyear/2016/owasp?page=2
★詳細は別途記載予定
(3)クローラへの耐性
H29秋SG午後問2で、「ウェブ健康診断仕様」における「クローラへの耐性」が問われました。（といっても、選択式）
https://www.ipa.go.jp/files/000017319.pdf
クローラとは、検索エンジンがサイトの情報を知るためのプログラムです。クローラの通信により、サーバのレスポンスが悪化する場合があります。つまり、可用性が失われるのです。これに耐えられるかが「クローラへの耐性」です。