目的：「イラスト図解式 この一冊で全部わかるWeb技術の基本」の要点を自分なりにまとめ、Qiitaへアウトプットして理解力の向上に努める。
| 注意点 |
|---|
| 🤔 ←この絵文字の文章は個人的な見解になります。的外れなこともあるかと思います。 |
（参考書籍）
（参考サイト）
- HTTPリクエストメッセージに載せる情報の１つに
HTTPメソッドがある-
HTTPメソッドは「このリクエストはWebサーバーに何の処理を要求するものなのか」を示す
-
[
- 代表的なのは「GET」「POST」メソッド
-
GETメソッド= HTMLファイルなどのWebコンテンツを取得したいという処理要求 -
POSTメソッド= ブラウザからWebサーバーに対して何かデータを渡したいという処理要求
-
- Webサーバーのデータを編集・削除したいという処理要求である「PUT」メソッド、「DELETE」メソッドはWebサーバー側で使用禁止にしている場合が多い
- データ改ざんのリスクがあるため
HTTPメソッドはクライアントがWebサーバーに要求する処理の種類を表します。Webサーバーによっては制限されているメソッドもありますが、「HEAD」メソッドと「GET」メソッドは必須です。
HTTPメソッド名 説明 HEAD HTTPヘッダーの情報のみを取得するHTTPメソッド
データの更新日時やデータのサイズのみを取得したい場合に利用するGET HTMLファイルや画像といったデータを取得する場合に利用する
Webサイト閲覧時において使用頻度が高いPOST フォームに入力したパスワードといったデータを転送する場合に利用する PUT データ（ファイル）をアップロードする場合に利用する
Webサーバー上のファイルを置き換えることができるため、利用できないように制限されている場合が多いDELETE 指定したデータ（ファイル）を削除する場合に利用する
PUTメソッド同様に利用できないように制限されている場合が多いCONNECT Webサーバーに接続するまでに別のサーバーを中継する場合に利用する
CONNECTメソッドを悪用した攻撃があるため、利用を制限されている場合が多いOPTIONS 利用できるHTTPメソッドを問い合わせる場合に利用する
PUTやDELETEメソッドのように利用制限されているHTTPメソッドがあるため、事前に機能を確認する際に利用されるTRACE WebブラウザとWebサーバーの経路をチェックする場合に利用する
TRACEメソッドを悪用した攻撃があるため、利用を制限されている場合が多い※主要なメソッドは太字 （P55の表より）
「GET」と「POST」の違い
※厳密にはGETメソッドはWebコンテンツを取得するためだけではなく、POST同様に入力値をWebサーバーへ送ることができるメソッドでもある
↓ ↓ ↓
Ｑ．じゃあPOST要らなくない？GETがあれば一人二役では？
Ａ．GETとPOSTではWebサーバーへのデータの送信方法が異なる
-
GETメソッドを利用する場合、『URLの後ろに送信したいデータを付与して送る』 -
POSTメソッドを利用する場合、『HTTPリクエストメッセージ内のメッセージボディに送信したいデータを格納して送る』
（図：とあるサイトにログインしようとした場合のメソッド別の違い）
- GETメソッドの"URLに送信内容が付与されるパターン"は「Webブラウザに閲覧履歴が残ってしまう」のが好ましくない
- 一方、POSTメソッドであればHTTPリクエスト内のメッセージボディに格納してから送信されるので、表面的に入力内容が表示されることなく入力内容を送信できる
- だから初学者向け参考書などには「GETでも送信できるけどPOSTの方が安全だからコッチ使った方が良いよ」と書かれている
・HTTPリクエストには「何の処理を要求しているリクエストなのか」を示すHTTPメソッドが情報として載せられている
・GETメソッドでも入力値を送信できるが、POSTメソッドはURLに入力内容を付加せず送信するのでこちらの方が送信には適している
[個人的疑問・所感など]
🤔<(「GETメソッドの"URLに送信内容が付与されるパターン"は「Webブラウザに閲覧履歴が残ってしまう」のが好ましくない」とはいうモノの、ぶっちゃけ履歴が見られなければ問題なくない？POSTメソッドの方が安全というのがまだ腑に落ちない)
⇒ 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践 を参考に深堀
【結論】URL上にパラメータが残ることであらゆる面で漏洩のリスクが伴ってくる
（以下、「GETメソッドで送信処理を行い、URLにログイン情報など機密情報が付加されている状況」を前提に記述）
- アクセスログなどURLが記録として残る場合
- 例）アクセスログには綿密にユーザーの動向を記録しており、ログを確認するとユーザーがどのURL先にアクセスしたかを確認でき、URLにはパラメータが付加されているのでユーザーの機密情報を取得できる ← 悪用の恐れあり
- 物理的にURLを見られる場合
- 例）なんとなく自分のPCを他人に貸したら、その人が自分のWebブラウザの履歴からURLを確認して機密情報を抜き取った
- 何気ないリンクの共有での危険性
- 例）自分のブログにお気に入りの書籍情報リンクを載せたら、ログインした状態で共有リンクを取得したせいか自分の機密情報が漏洩した
- HTTPリクエストメッセージに"Referer"という「リクエストされているページへのリンク先を持った直前のウェブページのアドレス」の情報が載る場合もあり、それが原因で漏洩するケース1
- refererはPHP、Railsなどあらゆる言語で参照できてしまうので、それら関数経由で漏洩してしまう
- 本来はユーザーの動向分析などにも使える
- refererはPHP、Railsなどあらゆる言語で参照できてしまうので、それら関数経由で漏洩してしまう