この記事では，研究のサーベイをまとめていきたいと思います。ただし，全ての論文が網羅されている訳ではありません。また，分かりやすいように多少意訳した部分もあります。ですので，参考程度におさめていただければ幸いです。
間違えている箇所がございましたらご指摘ください。随時更新予定です。他のサーベイまとめ記事はコチラのページをご覧ください。
読みたい場所へジャンプ！
本記事の内容
大学で学習した「情報セキュリティ」の内容を網羅的にまとめていくものです。目次は以下の記事をご覧ください。
WWWの誕生
今や広く使われるようになった「Web」という言葉は，クモの巣状のものという語義が由来になっています。そして，「WWW」というのは「world wide web」の頭文字をとった略称で，私たちが「インターネット」と呼ぶとき，多くの場合はWWWを指しています。
WWWはHTMLなどのハイパーテキスト（文書を相互に結び付けるしくみ）用の記述言語で表現されます。WWWは，ユーザーがWebブラウザを通してサーバとやりとりを行うシステムです。
WWWの特徴と要素は，以下の通りです。
●特徴
・ハイパーテキスト
・リンクは単方向
・クライアントサーバー方式
●要素
・HTML（Hypertext Markup Language）
→文章の構造を記述する言語
・URI（Uniform Resource Identifier）
→リソースを指し示す識別子
・HTTP（Hypertext Transfer Protocol）
→サーバからテキストを取得するためのプロトコル
という方は，以下の記事を参考にしていただければと思います。超簡単にまとめるとすれば，HTTPでは「リクエスト」を出し，TCPでは「ポート番号」（HTTPは80番）を識別します。IPではIPアドレスを判別され，それらが電気信号となりサーバに届けられます。
ここでは，HTTPのリクエスト（要求）の種類について簡単にみていきましょう。
●GET
→リソースの取得
●POST
→子リソースの作成・データ追加
●PUT
→リソースの更新・作成
●DELETE
→リソースの削除
●HEAD
→リソースのヘッダ取得
●OPTIONS
→リソースが対応するメソッドの取得
●TRACE
→リクエストの試験
●CONNECT
→プロキシ接続のトンネル化
例えば，HTML上で「method=”get”」という記述があれば，GETメソッドを利用して，URL上から「?username」を付加することでクエリ文字列（今回の場合はusername）を渡すことができます。一方，「method=”post”」という記述があれば，POSTメソッドを利用して，リクエスト本文にパラメータを記載することで，情報を渡すことができます。
具体的には，例えば名前を「https://usename」で入力して「https://username/show」に表示させるようなシステムを考えてみましょう。もし，GETメソッドを使って入力ページを構築すれば，記入欄にTaroと打ち込めば，「https://username/show?name=Taro」というURLで名前を表示することになります。一方，POSTメソッドを使って入力ページを構築すれば，同じようにしても「https://username/show」に名前が表示されます。
このように，GETを使うとURL上に入力が丸見えになってしまうため，機密データを扱う際には注意が必要です。また，送信するデータ量が多い場合も，もしGETメソッドを利用すればURLが長くなり制限に引っかかる可能性もあるため，POSTメソッドを使うようにするべきです。
Webアプリケーション
Webを介して動くアプリケーションは，「フロントエンド」と「バックエンド」に分けられます。前者はクライアントサイドとも呼ばれ，ユーザがアプリケーションを使用しているときに直接操作できるシステムを指します。一方，後者はサーバーサイドとも呼ばれ，ユーザの入力に基づいてデータを処理するシステムを指します。主に使用されている技術をいかにまとめます。
【クライアントサイド】
●HTML/CSS（スクリプト言語）
→Webページの構造を記述
●JavaScript（スクリプト言語）
→Webページに動きをつける
●Java Applet（コンパイラ言語）
→HTMLに埋め込めるJavaのプログラム
【サーバサイド】
●CGI（スクリプト言語/コンパイラ言語）
→クライアントの要求に従って処理
●Servlet（スクリプト言語/コンパイラ言語）
→クライアントの要求に従って処理するJavaプログラム
●JSP（コンパイラ言語）
→Servletとして動くHTML風のJavaプログラム
クライアントの状態
また，サーバとクライアントの通信方式には，「ステートレス」と「ステートフル」の二種類があります。前者はクライアントの状態を記憶しないのに対し，後者は記憶します。HTTPはステートレスプロトコルで，SMTPはステートフルプロトコルです。
ステートレスプロトコルでは，クライアントの状態を記憶しないため，クライアントからの要求が冗長になってしまいます。対して，ステートフルプロトコルでは，クライアントからの要求はコンパクトにすることができます。しかし，HTTPなどでは複数の処理を同時に行うため，ステートフルにしてしまうと接続数や容量が限界に達してしまいます。そのため，HTTPではステートレスを採用しています。
ステートレスでも，状態を記憶することはありませんが，認証のしくみは存在します。一度認証が通れば，クライアントから毎回同じユーザ名とパスワードを送り続けることになります。認証には「Basic認証」と「Digest認証」があります。前者は，IDとパスワードを「Base64」と呼ばれる方式で変換するのに対し，後者はハッシュ関数を利用して変換します。前者は，ほとんど生のデータを通信しているといえるため，現在ではDigest認証が主流です。
クッキー
クッキー（Cookie）とは，クライアントとサーバ間でやり取りされる特定のファイルのことを指します。よく「証明書」に例えられます。以下の記事も参考にしていただければと思います。RFC 6252に記述があります。RFCは，インターネット技術に関する仕様を記述した文書のことを指します。
HTTPクッキーは，ステートレスなプロトコルであるHTTP上で有効な機能です。つまり，状態を記憶する代わりにクッキーの中に情報を詰め込んで毎回やりとりしていれば，状態を記憶しているかのような通信が可能になるのです。
しかし，クッキーを利用した通信では，暗号化されずに送信される場合もあるため，盗聴や改ざん，なりすましといったような危険性があります。特に，毎回送信されるセッションIDは盗まれると非常に危険なため，注意が必要です。
参考：サードパーティークッキー
サードパーティーデータが通信されるときに利用されるクッキーを，サードパーティークッキーと呼びます。サードパーティーとは，保存されたドメインとは関係のないドメインによって収集された情報のことを指します。基本的に，クッキーはドメインと紐づけられて保存されますので，保存してあるドメインとは関係のないドメインから発行されるクッキーはサードパーティークッキーとなります。
身近な例で言えば，広告のカスタマイズのためにクッキーが利用される例です。どこかのサイトでサッカーボールを買い物したら，違うサイトの広告でサッカーボールがレコメンドされた，というようは具合です。
同一生成元ポリシー
Webブラウザに訪れる源泉（Origin）に基づいて，さまざまな制限をかける考え方を，同一生成元ポリシーと呼びます。異なるOriginからアクセスしている場合，情報漏洩などの危険性が考えられるからです。源泉を同一とみなす条件は，「ホスト」「スキーム」「ポート」をが全て一致するときです。
●ホスト
→「www.」など
●スキーム
→「http://」「https://」など
●ポート
→「80」など
たとえば，以下のようなドメインは同一と見なされます。
・http://example.com/
・http://example.com:80/
一方，以下のようなドメインは，上記ドメインとは同一とは見なされません。
・https://example.com
・http://example.com:123
・http://www.example.com
異なる源泉から来た通信に対しては，以下のような制限を行います。
●リクエストによる取得の禁止
●別Originのフレームへの操作の制限
●Canvasへの操作の制限
クロスサイトスクリプティング
同一生成元ポリシーでは，同じ源泉からのコンテンツに対しては効力をなしません。同じ権限内の範囲でWebサイトの脆弱性を利用してターゲットに攻撃をしかけることを，クロスサイトスクリプティングと呼びます。
具体的な被害としては，クッキーの情報を盗まれたり，マルウェアに観戦させられたりすることが挙げられます。対策としては，エンジニアであればサニタイズ処理（特殊文字の変換），サーバー側であればHttpOnlyフラグやContent Security Policyの利用，ブラウザ側ではXSSフィルタの利用が挙げられます。
SQLインジェクション
悪意のある改ざんにより，データベースを直接操作されてしまうような攻撃を，SQLインジェクションと呼びます。アプリケーションが想定しない入力をいれることで，プログラムがデータベースをいじれるようにしてしまう攻撃方法です。
たとえば，ユーザーネーム入力欄に「taroʻ or ʻAʼ = ʻA」を入れると，「id = ʻtaroʻ or ʻAʼ = ʻAʻ」となり常にTrueになるため，全てのレコードが返されてしまい，情報漏洩につながります。
対策としては，SQL文と入力変数を分離させるために，プレースホルダー（変数の代替物）をうまく利用することです。また，SQLインジェクション以外にも，引数やパラメータを動的にやりとりするアプリケーションでは，インジェクション系の脆弱性が発生する可能性があります。
SCRF（Cross Site Request Forgeries）
異なるサイトへリクエストを行わせることで，重要な情報を抜き取る攻撃を，SCRF（Cross Site Request Forgeries）と呼びます。
対策としては，リクエストにtoken（合言葉のような情報）を設定することで，秘密情報をもとにアクセスが妥当なものかを判断することができます。また，パスワードの再入力やCaptchaを利用する方法も考えられます。
まとめ
情報セキュリティのWebセキュリティについてお伝えしました。私自身もプログを運営しているということで，Webセキュリティの知識は必須だと感じています。便利なことに，様々なツールが開発されているおかげで，私たちの役割はほとんど文章を書くことだけです。一方で，中身がブラックボックス化してしまっているため，何かあったときに対策の施しようがわからないのも現状です。特に，クッキーなどの話題は身近に危険が潜んでいるいい例だと思います。耳が痛いですが，私たちも受動的にならずにセキュリティ意識を強化していく必要があります。
