Webの世界-セキュリティ編-

# Webの世界-セキュリティ編-
## 概要
この記事は[Webの世界-通信高速化編-](https://qiita.com/haseesah/items/b76b625da2a6abc6ab24)の続きになります。

どのレイヤの技術でも、セキュリティは常に考慮しなければいけない事項である。
そこで、本記事ではWebに纏わるセキュリティの問題点を説明する。  

なお、本記事では各ソフトウェアなどに固有な脆弱性の話などは取り扱わない。

## 中間者攻撃
### 概要
[HTTPSの投稿](https://qiita.com/haseesah/items/36cd0089884dcf318bb3)でも少し説明したが、HTTPによる通信は平文で行われるため、通信経路上のどこかしらで通信を傍受したり改ざんしたりすることが可能である。これを**中間者攻撃(MITM攻撃)** という。
中間者攻撃の起点となるものとしてはWifiのアクセスポイントやルーターなどが挙げられる。

### 対策
#### HTTPS通信
中間者攻撃の根本的な原因は、HTTPによる通信が平文で行われていることである。
そのため、HTTPSを用いて通信を暗号化することで大きく脅威を低減できる。
HTTPS通信については前回の投稿にて解説したため本記事では説明しない。  
なお、HTTPS通信といっても中間者攻撃が完全に防げるわけではなく、また通信経路以外の安全性を保証するものではない。

#### HSTS(HTTP Strict Transport Security)
クライアントに対してサーバー側からHTTPS通信を行うように要請する技術。
サーバはクライアントに対し```Strict-Transport-Security```ヘッダーを付与したレスポンスを送付することでクライアント側はそれ以降の同一ドメインに対する接続をHTTPSに切り替える。
なお、この場合最初の一回はHTTPで通信する必要があるが、クライアント側で最初からHTTPSで接続するサイトをリストアップすることでHTTPによる通信をせずともHTTPSで通信を開始することができる。

#### HTTP公開鍵ピンニング
HTTPS通信を行う際のサーバ証明書の正当性を確認する手段である。
サーバからサーバ証明書が送られてくる際に証明書に付属している公開鍵をクライアント側で保存し、次回以降の通信で公開鍵を比較することで、サーバ証明書が不正に書き換えられていないかを検証できるようになる。
こちらも一番最初のサーバ証明書が不正に書き換えられた場合は検証できないが、クライアント側で事前に公開鍵を取得することで回避できる。

## クロスサイトスクリプティング(XSS)
### 概要
攻撃者の作成したスクリプトを標的サイトの権限を用いて閲覧者(クライアント)のブラウザで実行させる攻撃全般を**クロスサイトスクリプティング(XSS)**という。
Webアプリケーションにおいて、スクリプトはそれなりに大きな権限を持つため、この攻撃が成功すると大きな被害が生じる可能性がある。  
![XSSの概略図.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/292905/3c3ba53d-1755-3f40-6cf3-a5edd8029169.png "XSSの概略図")



原因としては、主にWebページでhtmlやスクリプトを生成している部分に脆弱性が存在する場合である。
例えば掲示板などの第三者が記述したテキストが表示されるようなページでは、攻撃者が作成したスクリプトをそのまま表示させてしまうと、第三者がwebページを読み込んだ際にスクリプトを第三者のブラウザが解釈してしまい、実行してしまう。　　
この攻撃により、ユーザの意図しないリクエストを発行したり、クッキーの情報を取得されたり改ざんされたりする可能性がある。
### 対策
#### 適切なエスケープ
最も基本的な対策は、攻撃者のスクリプトをWebページに埋め込まない、もしくはスクリプトとしての機能を持たない形にすることである。
特にWebページ上で特別な意味を持つ **<** , **?** などを他の記号に書き換えることで、スクリプトをスクリプトとして成立しない文字列に置き換え、攻撃を防ぐことができる。  

#### httpOnly
直接XSSを防ぐ方法ではないが、XSSによるクッキーに対する攻撃を防ぐ手法である。
クッキーに**HttpOnky**属性を設定すると、スクリプトからはアクセスが不可能になるため、結果的にXSSによるクッキーへの攻撃を防ぐ事ができる。

#### X-XSS-Protection
非公式ヘッダーの一つだが、このヘッダーを付与した場合、Webページの怪しい箇所をパターンマッチングで検出してくれる。
FireFoxは対応していない。

#### Content-Security-Policy
Webページで使えるセキュリティの機能を細かく設定することができるヘッダー。
機能は多岐にわたるが、代表例としては

- 各リソースファイルへのアクセス権
- 反射型XSSへのフィルタ
- ポップアップの許可
- HTTPSの通信先をHTTPSに

などが挙げられる。

## クロスサイトリクエストフォージェリ(CSRF)
### 概要
本人の意図しないリクエストを無関係のページやサイトから送らせる攻撃。  
例えばあるECサイトにログイン中のユーザが別ページでCSRFによる攻撃が含まれた不正なURLを踏んだためにECサイトで勝手に注文が送られてしまったなどが挙げられる。

![スライド2.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/292905/13b7edbc-4a6b-e697-2bbb-fd4076f53305.png "CSRFの概略図")


### 対策
#### CSRF対策トークン
注文処理などのフォームを設定する際に、隠しフィールドにランダムに作成されたトークンを埋め込み、フォームを送信した際にサーバ側でトークンの値が正しいか検証することでCSRFを防ぐ。

## セッションハイジャッキング
### 概要
セッションハイジャッキングと呼ばれる攻撃手法は、下記の三種類が挙げられる。

- セッションIDの推測
- セッションIDの盗み出し
- セッションIDの強制

いずれにしても、セッション管理機能の脆弱性を突く攻撃になる。
攻撃に成功した場合は、攻撃者が本来の利用者に成り済ますことが可能になるため被害は大きい。

### 対策
#### セッションIDの適切な管理
非常に単純ではあるが、セッションIDを適切に管理する/させることでセッションハイジャッキングへの対策ができる。

例としては

- 適切なライブラリ/FWを用いてセッションIDのランダム性を保持する
- URL埋め込みセッションIDを利用しない


## クリックジャッキング
### 概要
ユーザに意図しないクリックを行わせる攻撃をクリックジャッキングという。
手法としては、攻撃用のフォームとクリックボタンを持つ本来の画面をiframe要素などで別の一見無害な画像と重ね合わせることでクリックを誘発する方法などがある。

### 対策
#### X-Frame-Options
クリックジャッキングはアプリケーション側単体での対策は困難であり、クライアント(ブラウザ)側での対策が必要である。
その対策としては**X-Frame-Options**を用いてiframe要素への参照を制限することが有効である。
このヘッダーを設定することで、重要な処理を行う入力フォームを罠サイトで表示させないようにできる。

## まとめ
セキュリティ関連はまだまだあるので続きそのうち書きます。