Spring Security にできること・できないこと

## 自己紹介
<img src="https://qiita-image-store.s3.amazonaws.com/0/28302/63d28421-104b-3066-2712-768e6aded5f7.jpeg" width="150px" class="pull-right"/>

- opengl-8080
- 主に Qiita で技術メモを書いたり
- 関西の SIer 勤務

---
## 今日お話しすること
- Spring Security が保護してくれること、してくれないこと
- Spring Security を導入すれば、この攻撃は守ってくれる
- この攻撃は Spring Security の守備範囲外なので別途対処が必要
- 仕様や機能の話をメインにして、実装の細かい話は無し


---
## デモ用アプリ
https://github.com/opengl-8080/spring-security-sample

### 起動方法
GitHub からプロジェクトをダウンロードし、プロジェクトのルートで `gradlew start` を実行

※初回は Payara （60MB）などのダウンロードが行われるので注意

```bash
# Windows
> gradlew.bat start

# Linux
$ ./gradlew start
```

### 動作確認
AP サーバーが起動したら、以下の URL にアクセスする。

- `https://localhost:8443/secure`
    - Spring Security を使用したアプリケーション
- `https://localhost:8443/non-secure`
    - 脆弱性のあるアプリケーション

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/4ab9ff10-5037-1b91-066d-38c244826a04.jpeg)

同じ機能を持つアプリケーション(`app`)に対して、脆弱性のある形で自力でセキュリティ機能を実装したもの(`non-secure`)と、 Spring Security を導入したもの(`secure`)を用意

#### ログインユーザ
- `user` と `admin` という２つのユーザを用意しています
- パスワードはユーザー名と同じです


---
## 安全なウェブサイトの作り方
- IPA が公開している資料[^1]
- ウェブサイトを作るときに注意すべきセキュリティ対策についてまとめられている
- ここで紹介されている個々の脆弱性に対して Spring Security がどうカバーしているか、という観点で説明していく

---
## 紹介されている脆弱性
1. SQL インジェクション
1. OS コマンド・インジェクション
1. パス名パラメータの未チェック／ディレクトリトラバーサル
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. CSRF
1. HTTP ヘッダ・インジェクション
1. メールヘッダ・インジェクション
1. クリックジャッキング
1. バッファーオーバーフロー
1. アクセス制御や認可制御の欠落

---
## そもそも Spring Security の管轄外
- Spring Security は、 Servlet の Filter 機能を利用してセキュリティ機能を提供するフレームワーク
    - HTTP リクエストの前後でごにょごにょする
- 根本的な対策が Filter でできないものは Spring Security の管轄外
- 例：SQL インジェクション
    - 根本的な対策は、 SQL の組み立てにプレースホルダを使うこと
    - Filter で完全に防ぐのは困難

---
## 管轄外の脆弱性を除く
1. <del><font color="#ccc">SQL インジェクション</font></del>
1. <del><font color="#ccc">OS コマンド・インジェクション</font></del>
1. <del><font color="#ccc">パス名パラメータの未チェック／ディレクトリトラバーサル</font></del>
1. **セッション管理の不備**
1. **クロスサイト・スクリプティング**
1. **CSRF**
1. **HTTP ヘッダ・インジェクション**
1. <del><font color="#ccc">メールヘッダ・インジェクション</font></del>
1. **クリックジャッキング**
1. <del><font color="#ccc">バッファーオーバーフロー</font></del>
1. **アクセス制御や認可制御の欠落**

これらは Spring Security を導入しても、個別に対策を講じなければならない。

<font color="red">※管轄外だ、というのは私の判断によるものです（Spring Security のドキュメントに「そうだ」と書いているわけではないので、もし「～～すれば Spring Security でも防げるよ」というのがあれば教えていただけると助かります）</font>

---
## 残った脆弱性
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. CSRF
1. HTTP ヘッダ・インジェクション
1. クリックジャッキング
1. アクセス制御や認可制御の欠落

---
## 残った脆弱性
1. **セッション管理の不備**
1. クロスサイト・スクリプティング
1. CSRF
1. HTTP ヘッダ・インジェクション
1. クリックジャッキング
1. アクセス制御や認可制御の欠落

---
## どういう問題？
- ユーザの識別で使用する識別子（セッションID）の扱い方に問題がある
- セッションID を盗まれたりすることで、別のユーザになりすますことができてしまう
- 情報の漏洩やデータの改ざんにつながる
- 「安全なウェブサイトの作り方」では、３種類の不備を紹介している

---
## セッション管理の不備
1. セッションIDの推測
2. セッションIDの盗用
3. セッションIDの固定化

---
## セッション管理の不備
1. **セッションIDの推測**
2. セッションIDの盗用
3. セッションIDの固定化


---
## 1. セッションIDの推測
- 例：１からの連番
- 次の ID を攻撃者が推測できると、別人のセッションID を使ってなりすましができる

---
## 根本的対策
- 推測できないランダムな値を生成する
- 暗号論的疑似乱数生成器を使う（Java だと `SecureRandom` を使う）

---
## Spring Security のサポート
- セッションID の発行は Servlet の仕事なので、 Spring Security の管轄外

---
## Servlet の発行するセッションID
- 仕様上は具体的な採番方法について言及されていない様子

> The identifier is assigned by the servlet container and is implementation dependent.
> 
> （訳）
> 識別子は Servlet コンテナによって割り当てられ、それは実装依存です。

[HttpSession#getId() の Javadoc](http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html#getId--)

- 使用している Servlet コンテナごとに確かめる必要がありそう
- Payara (GlassFish) は、実装を見たところ、セッションID の一部に `SecureRandom` を使っていた


---
## セッション管理の不備
1. セッションIDの推測
2. **セッションIDの盗用**
3. セッションIDの固定化


---
## 2. セッションIDの盗用
- セッションID を、攻撃者が盗みやすい状態で取り扱っている
- 例１：セッションID をクエリパラメータにセットしている
- 例２：HTTP 通信にも Cookie を流してしまう

---
## 2. セッションIDの盗用
- セッションID を、攻撃者が盗みやすい状態で取り扱っている
- **例１：セッションID をクエリパラメータにセットしている**
- 例２：HTTP 通信にも Cookie を流してしまう


---
## セッションID をクエリパラメータにセット
```
https://xxx.com/foo/bar?jsessionid=xxxxxxxxxxxxxxx
```

- Cookie がサポートされていないクライアント（昔のガラケーとか）でもセッションの仕組みが働くようにするための代替策
- URL リライティングと呼ばれる
- Referer にセッションIDが載ってしまうので、セッションIDが盗まれやすくなる

---
## 根本的対策
- 常に Cookie を使い、クエリパラメータにセッションIDを載せる仕組みを使わない

---
## Spring Security のサポート
- セッションIDの管理は Servlet の仕事なので、管轄外
- ただし、保険的な機能はある（後述）

---
## Servlet のセッションID管理
- 仕様上 Cookie のサポートは必須

> 7.1.1 Cookies[^2]
> 
> Session tracking through HTTP cookies is the most used session tracking mechanism and **is required to be supported by all servlet containers**.
> 
> （訳）
> HTTP Cookie によるセッション追跡は、セッション追跡のメカニズムとして最もよく使われており、全ての Servlet コンテナによってサポートされる必要があります。



- URL にセッションIDを載せる方法は必須ではないが、 Cookie をサポートしないクライアントにも対応できなければならないことになっている

> 7.1.4 Session Integrity[^2]
> 
> Web containers **must be able to support** the HTTP session while servicing HTTP requrets from clients that **do not support the use of cookies**.
> To fulfill this requirement, Web containers commonly support the URL rewriting mechanism.
> 
> （訳）
> Web コンテナは Cookie の利用をサポートしないクライアントからの HTTP リクエストを処理するときに、 HTTP セッションをサポートできなければならない。
> この要求を満たすため、 Web コンテナは通常 URL リライティングの仕組みをサポートします。

---
## セッション追跡の変更方法
```xml:web.xml
<session-config>
  <tracking-mode>COOKIE</tracking-mode>
</session-config>
```

- Servlet 3.0 からは、 `web.xml` でセッション追跡の方法を指定できる
- `<tracking-mode>` に `COOKIE` を指定すれば、 Cookie が使われるようになる
- `URL` を指定すると URL リライティングが使用されるようになる

---
## Spring Security によるガード
- Spring Security は URL リライティングが働かないように保護機能を提供している
- URL にセッションIDが含まれていると、自動的に除去される
- 意図せず URL リライティングが動作しても、セッションID がクエリパラメータに載らないようになっている

---
## 2. セッションIDの盗用
- セッションID を、攻撃者が盗みやすい状態で取り扱っている
- 例１：セッションID をクエリパラメータにセットしている
- **例２：HTTP 通信にも Cookie を流してしまう**

---
## HTTP 通信にも Cookie を流してしまう
- セッションID が載った Cookie を暗号化されていない HTTP で流してしまうと、盗聴される危険性がある

---

## 根本的対策
- Cookie の secure 属性を有効にする
- ブラウザはその Cookie を HTTPS 通信でしか送信しなくなる


---
## Spring Security のサポート
- こちらもセッションIDの管理なので、 Spring Security は管轄外

---
## Servlet での secure 属性の指定方法
```xml:web.xml
<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>
```

- `web.xml` で指定する
- `<cookie-config>` の `<secure>` に `true` を指定する

---
## セッション管理の不備
1. セッションIDの推測
2. セッションIDの盗用
3. **セッションIDの固定化**


---
## 3.セッションID の固定化
- ログインの前後でセッションIDを変更しない場合に問題になる
- ログイン前に攻撃者が取得したセッションIDを被害者に使わせ、被害者がログインしたあとで攻撃者が同じIDでアクセスすることでなりすましができる

**<font color="blue">デモ</font>**

### セッションID がログイン前後で変わらない様子
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/ce3d1833-dcde-3d8a-528a-b828ddce0a88.jpeg)

- ログイン前
- セッションID は `5fbb4bcd29ecba2a37f7caa07302`

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/186d0a84-edb1-db7c-c989-2f1b45d1b859.jpeg)

- ログイン後
- セッションID は `5fbb4bcd29ecba2a37f7caa07302` のまま

### セッション固定化攻撃の様子
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/9417801a-0be7-ccf2-8c1f-fede22567123.jpeg)

- 攻撃者のブラウザでログインページにアクセスする
- ログイン前のセッションID（`5fea683aa1653ccb9f0962150ad6`）を入手する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/f5a54e45-1e2d-cfab-bd80-8bceace092f5.jpeg)

- 被害者のブラウザに、何らかの方法で攻撃者が入手したログイン前のセッションIDをセットする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/99e59649-f1d0-63df-4583-86d8c3be128f.jpeg)

- 被害者は、セッションIDが強制されていることに気付かずにログインする
- これで、攻撃者が用意したセッションID（`5fea683aa1653ccb9f0962150ad6`）は被害者を識別するためのセッションIDとなる

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/ccc440d6-7869-4f17-7492-00f4ef23b2de.jpeg)

- 攻撃者側のブラウザでホームにアクセスすると、ログイン処理していないのにホームページが表示される
- このとき、セッションIDは `5fea683aa1653ccb9f0962150ad6` を使っているので、被害者に成りすました状態でアクセスしていることになる

---
## 根本的対策
- ログインの前後でセッションIDを変更する

---
## Spring Security のサポート
- Form ログインを使っている場合、 Spring Security はデフォルトでログイン時にセッションIDを変更してくれる

**<font color="blue">デモ</font>**

### セッション固定化攻撃を仕掛けようとする
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/2c0b8387-0e68-bf63-6223-7a143d4a8fc1.jpeg)

- 攻撃者がセッションID (`609c76875301d863f53cdf9d175d`) を入手する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/9d6c34cc-ad13-6139-ad95-223eb843f597.jpeg)

- 攻撃者が入手したセッションID をブラウザにセットする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/a108ab3c-b6a0-e099-4782-3c520fdca332.jpeg)

- ログインすると、セッションID が変更される（`60c229f9b2988231a31587dd1df6`）

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/62a17ebc-564c-587e-e06c-f5ed0421f823.jpeg)

- 攻撃者側のブラウザでホームにアクセスしても、ログイン画面に飛ばされる

---
## セッション管理の不備　まとめ
![セッション管理の不備.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/4bec0b50-6901-c00d-dbad-443c6410f6bb.jpeg)

- セッションID の生成や追跡は Servlet コンテナの役割なので、そちらの設定で対処する

---
## 脆弱性
1. セッション管理の不備
1. **クロスサイト・スクリプティング**
1. CSRF
1. HTTP ヘッダ・インジェクション
1. クリックジャッキング
1. アクセス制御や認可制御の欠落

---
## どういう問題？
- ユーザが入力したテキストを html にそのまま出力すると、 JavaScript を埋め込まれることでページの改ざんやセッションIDが盗まれたりする

---
## 根本的対策
- html に出力するすべての要素に対してエスケープ処理をする
- 例：`<script>` → `&lt;script&gt;`

---
## Spring Security のサポート
- 根本的対策についてのサポートはなし
- html の出力は、主にレンダリング（テンプレート）エンジンの役割
    - Thymeleaf なら、デフォルトでエスケープしてくれる
    - JSP はエスケープなし
        - JSTL の `<c:out>` を使っていればエスケープされる



---
## 保険的対策
- レスポンスヘッダーを使用した保険的な対策はサポートされている

### X-XSS-Protection
- 反射型 XSS を防ぐためのブラウザ機能を有効にするレスポンスヘッダ
- ブラウザによってはこの保護機能がデフォルトでは無効になっている場合がある
- このレスポンスヘッダをつけることで、ブラウザの保護機能を有効にできる
- Spring Security は、デフォルトでこのヘッダーをレスポンスに付与する

**ブラウザのサポート状況**

[X-XSS-Protection - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection)

|ブラウザ|Desktop    |Mobile |
|-------|-----------|-------|
|Chrome |Yes        |Yes    |
|Edge   |Yes        |Yes    |
|Firefox|No         |No     |
|IE     |8+         |?      |
|Opera  |Yes        |Yes    |
|Safari |Yes        |Yes    |
|Android WebView|-  |Yes    |

Firefox が対応していないことについて情報を頂きました、ありがとうございます！

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">X-XSS-ProtectionがFirefoxで対応していないのは、より詳細に設定できる Content-Security-Poricy  で unsafe-inline をすればいいから。<br>レガシーブラウザ互換のためだけなのものなので、実装しないようです。 <a href="https://twitter.com/hashtag/ccc_g4?src=hash&amp;ref_src=twsrc%5Etfw">#ccc_g4</a> <a href="https://twitter.com/hashtag/jjug_ccc?src=hash&amp;ref_src=twsrc%5Etfw">#jjug_ccc</a></p>&mdash; Yuji@にゃーん (@YujiSoftware) <a href="https://twitter.com/YujiSoftware/status/931763560560017409?ref_src=twsrc%5Etfw">2017年11月18日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>



**<font color="blue">デモ</font>**

#### X-XSS-Protection が無効な場合
※以下の操作は X-XSS の対策がデフォルトでは無効なブラウザ（Edge とか）を使って試してください（Chrome はダメ）

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/d3242f9c-c592-f747-86ac-63354cd1a2db.jpeg)

- ログイン後 `X-XSS` を選択する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/77887d31-3373-b356-bd37-73a36f7dfacb.jpeg)

- この画面は、クエリパラメータの `message` をそのまま HTML 上に出力している
- メニューから飛んだ場合は `message=Hello+World!!` がパラメータとして設定されているので、「Hello World!!」と画面に出力される

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/6b9eb2da-6bf7-ddee-6c56-be1479b2f215.jpeg)

- 「攻撃を再現」リンクをクリックすると、 GitHub に上げている静的 HTML ページに飛ぶ
- `/non-secure` と `/secure` のそれぞれに同じ X-XSS 攻撃を仕掛けるリンクが用意されている
    - `message` に `<script>` タグを仕込んでいる
- 上のリンクをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/a18952db-50f5-4e12-c61a-1e4b5fb1084b.jpeg)

- X-XSS が成功して、ダイアログが表示される

#### X-XSS-Protection を有効にした場合
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/692b9b4b-6a0d-3c80-0f49-747694de640b.jpeg)

- `/secure` の方にログインし、「攻撃を再現」を開く

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/85befd9d-b9d2-505e-4b18-525e641a7e25.jpeg)

- 今度は下のリンクをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/2341a300-11ed-30b7-094b-f0351069678c.jpeg)

- スクリプトは実行されず変なエラー画面になった

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/db1a0124-c1d2-a3d6-5c81-684dcefa5371.jpeg)

- ブラウザのコンソールを見ると、 `XSS` をブロックしたことを示すメッセージが表示されている

---
## 脆弱性
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. **CSRF**
1. HTTP ヘッダ・インジェクション
1. クリックジャッキング
1. アクセス制御や認可制御の欠落

---
## どういう問題？
- 正規ログインしているユーザに罠のリンクを踏ませるなどして、意図しない処理を実行させる

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/eaadc2c3-3266-c42c-5780-d412854a970d.jpeg)

- メニューの「CSRF」を選択する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/cc5ffc49-f33b-b0a7-b19f-5aa5adebb9a2.jpeg)

- テキストボックスに適当な文字を入力して「Add」ボタンをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/9dda0640-ef3b-4d88-e87d-e450c9e4f2fa.jpeg)

- 入力された文字列がサーバーに保存され、保存された文字列がリストとなって表示される

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/a64f0028-acd8-f1bc-487c-cddf3f30ae34.jpeg)

- 「攻撃を再現」リンクを開くと、 GitHub 上の CSRF 攻撃を仕掛けるためのページが開く
- 上の「Submit」ボタンをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/9a0633bb-bee0-8a0a-f101-d2bae8a2e14e.jpeg)

- CSRF 攻撃が成功し、攻撃ページで指定されていた文字列（`CSRF Attack!`）がサーバーに記録され、一覧に表示される


---
## 根本的対策
- リクエストが正規のページからやってきたことを検証する
    - セッションID とは別に推測困難な文字列（トークン）を生成し、ページに埋め込んでおく
    - リクエストのたびにトークンも送るようにし、トークンの検証を行う


---
## Spring Security のサポート
- Spring Security は、デフォルトでこの CSRF 対策が有効になっている

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/eea18ce5-209e-9fd4-ff4c-f01c042201f0.jpeg)

- `/secure` にログインし、「CSRF」のページを開く

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/1b77d4e2-45ea-d72c-ac56-fb4f6600aaaa.jpeg)

- 「攻撃を再現」リンクから攻撃用のページに飛び、次は下の「Submit」ボタンをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/829745f6-15d7-c3a5-9c3d-53212118ea5b.jpeg)

- CSRF 攻撃が検知され、エラーページに飛ばされる


---
## チェックが行われる条件
- リクエストの HTTP メソッドが `GET`, `HEAD`, `TRACE`, `OPTIONS` <font color="red">以外</font>
- `GET` メソッドで状態を更新するような実装をしているとチェックをすり抜けるので注意
- 一応、設定で変更可能


---
## 脆弱性
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. CSRF
1. **HTTP ヘッダ・インジェクション**
1. クリックジャッキング
1. アクセス制御や認可制御の欠落

---
## どういう問題？
- ユーザ入力を HTTP レスポンスヘッダーに利用する場合、改行コードの入力を許しているとレスポンスの内容が意図しない形に書き換えられる危険性がある
- 改行コードは HTTP メッセージの各ヘッダーやボディを区切る役割を持つため、改行コードを任意に埋め込めるようにしていると HTTP メッセージ（レスポンス）を改ざんできてしまう

---
## イメージ
仮に、次のようなレスポンスを返すアプリが存在したとする。

```text
Aaa-Header: AAAAA<改行>
Bbb-Header: BBBBB<改行>
User-Input-Header: 【ここにユーザが入力した文字列を出力】<改行>
<改行>
HTTP Message Body
```

もしユーザ入力が次のようなテキストの場合、

```text:ユーザー入力
xxx<改行>Xxxx-Header: xxxxxxxxxx
```

これをそのまま埋め込むと、レスポンスは下のようになる

```text:生成されるレスポンス
Aaa-Header: AAAAA<改行>
Bbb-Header: BBBBB<改行>
User-Input-Header: xxx<改行>
Xxxx-Header: xxxxxxxxxx<改行>
<改行>
HTTP Message Body
```


---
## 根本的対策
- 「安全なウェブサイトの作り方」では、実行環境や言語が用意しているヘッダ出力用 API を使うよう促している
- Java の場合は Servlet の [HttpServletResponse#setHeader(String, String)](http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html#setHeader-java.lang.String-java.lang.String-) とかになる

---
## Servlet の API は改行コードを消す？
- Javadoc や JSR の仕様書を眺めたが、改行コードの扱い方についての記述は見当たらなかった
- Servlet の仕様としては、改行コードをどうするかは決められていないっぽい

Servlet でのヘッダーの扱いについて、詳しい情報を教えていただけました！
↓のような事情なようです。


<blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"><p lang="ja" dir="ltr">すまん。URLエンコードじゃなくて、MIMEエンコードだった(RFC2047)</p>&mdash; m6s (@megascus) <a href="https://twitter.com/megascus/status/931764347176546310?ref_src=twsrc%5Etfw">2017年11月18日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


<blockquote class="twitter-tweet" data-conversation="none" data-lang="ja"><p lang="ja" dir="ltr">ていう感じみたいですね。Payaraの実装見てませんが。</p>&mdash; m6s (@megascus) <a href="https://twitter.com/megascus/status/931774221813915648?ref_src=twsrc%5Etfw">2017年11月18日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


---
## 実際のところ
- 今回 Payara を使って動作を検証
- 値に改行コードがある場合は自動的に除去され、一行になった
- 名前に改行コードがある場合はヘッダーのセットが拒否された

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/8b4766e2-a37f-c589-b65e-69086e82abba.jpeg)

- リンクの「Header Injection」を選択する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/84d9e906-8ba6-9420-48bf-9aa0fa76fca4.jpeg)

- 「Header-Value」に複数行の値を入力して「Submit」ボタンをクリック

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/59381098-1b26-7700-116c-5ef48f74a34f.jpeg)

- レスポンスヘッダーを確認すると、改行が除去され１行になって返されている

---
## Spring Security のサポート
- `HttpServletResponse` がラップされ、ヘッダーに改行コードを含んだ文字を渡したときの動作が変わる
- 改行コード（`\n` or `\r`）が含まれると、 `IllegalArgumentException` がスローされる
- そのままだとサーバーエラー（500 エラー）になるので、ヘッダーに値を出力する場合は事前に改行コードの有無をチェックしなければならない

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/eaab3e10-1ba9-2e67-4650-dd809d590d03.jpeg)

- 「Header-Value」に改行をいれた状態で「Submit」をクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/4d7c3f23-9038-c46b-6002-a3922433d667.jpeg)

- `IllegalArgumentException` が発生してサーバーエラーになる

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/68220470-08c9-ccf9-4165-2b71df64b397.jpeg)

- 「改行コードを明示的に除去する」のチェックを入れて「Submit」する
    - サーバー側で改行コードが除外されたうえでレスポンスヘッダーにセットされるようになる

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/0b51afee-07a1-3a05-f0df-5217d3bf7209.jpeg)

- 今度はエラーにならずレスポンスが返される



---
## 脆弱性
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. CSRF
1. HTTP ヘッダ・インジェクション
1. **クリックジャッキング**
1. アクセス制御や認可制御の欠落

---
## どういう問題？
- 見えない `<iframe>` を仕込むことで、閲覧者が意図していないクリック操作をさせる攻撃

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/1772a3cf-0847-1c5d-93e8-b35d335a08fc.jpeg)

- メニューから「Click Jacking」を選択する

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/07612f3a-752c-043c-2ad1-389d6038d167.jpeg)

- 「Count up」ボタンをクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/8fbdb5c1-3b75-2a4c-ca06-f4263c0b3e0b.jpeg)

- サーバーに記録しているカウントがインクリメントされ、画面表示も更新される

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/5c57bd55-aaf4-7e7f-8d23-20364cbfdf28.jpeg)

- 「攻撃を再現」リンクをクリックすると、クリックジャッキングを仕掛けた攻撃ページが開く
- 「Click」ボタンを何回かクリックする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/0c3cf85f-13bd-ae88-ca93-70a172128412.jpeg)

- 元のページに戻って、画面を再描画させる
- すると、攻撃ページで「Click」ボタンをクリックした数だけカウントが上昇している

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/b867f1f0-4929-d377-c90b-ca90163e419e.jpeg)

- 攻撃ページには、元ページが `<iframe>` として埋め込まれている
- `opacity` で透明にして見えなくしている
- 元ページの「Count up」ボタンと攻撃ページの「Click」ボタンがうまく重なるように位置を調整されており、「Click」ボタンの位置をクリックすると実は「Count up」ボタンがクリックされるようになっている


---
## 根本的対策
- 自分の Web ページを `<iframe>` で表示できないようにする
- レスポンスヘッダに `X-Frame-Options` を設定することで可能になる

**ブラウザのサポート（基本機能）**

[X-Frame-Options - HTTP | MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)

|ブラウザ|Desktop|Mobile|
|-------|-------|------|
|Chrome |4+     |Yes   |
|Edge   |Yes    |Yes   |
|Firefox|3.6.9+ |Yes   |
|IE     |8+     |Yes   |
|Opera  |10.5+  |Yes   |
|Safari |4+     |Yes   |
|Android WebView|-|Yes |


---
## Spring Security のサポート
- デフォルトで `X-Frame-Options` がレスポンスヘッダに設定される

**<font color="blue">デモ</font>**

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/0f9d9c10-9fe8-ccf8-289d-afc20b8cfdba.jpeg)

- `/secure` の方の「Click Jacking」ページから「攻撃を再現」リンクを開く

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/baf28e4d-e956-335d-0442-c8b6a8e44216.jpeg)

- `X-Frame-Options` に `deny` が指定されているため `<iframe>` に元ページを表示できなくなっている


---
## 脆弱性
1. セッション管理の不備
1. クロスサイト・スクリプティング
1. CSRF
1. HTTP ヘッダ・インジェクション
1. クリックジャッキング
1. **アクセス制御や認可制御の欠落**

---
## どういう問題？
- 適切にアクセス制御ができていない場合、本来閲覧できてはいけない情報を見られたり、できてはいけない操作を実行されたりするかもしれない


---
## 根本的対策
- 認証・認可の制御を適切に実装する
    - パスワードログイン
    - 権限によるアクセス制御

---
## Spring Security のサポート
```java:SpringSecurityの設定例(一部)
// "/login" へのアクセスは誰でも可
.antMatchers("/login").permitAll()

// "/admin" 以下のパスへのアクセスは admin 権限を持つユーザのみ可
.antMatchers("/admin/**").hasAuthority("admin")

// それ以外のアクセスは認証されていれば可
.anyRequest().authenticated()
```

- Ant 形式のパスや権限の指定が、宣言的な定義で記述できる
- 見落としがちなバイパス方法にも対応
    - URL のパスパラメータの考慮など

**<font color="blue">デモ</font>**

### パスのマッチングが不十分な場合
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/88d7d54c-081a-6e2a-62a5-2faef95c522f.jpeg)

- `user` でログインしたうえでメニューから「Access Control」を開く

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/78f233b4-f05b-6a00-98a0-c77ea97f79e1.jpeg)

- 権限がないのでエラー画面に飛ぶ

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/14db1ba5-03b8-76ef-6bb2-dad92ce4b9f1.jpeg)

- つづいて `admin` ユーザでログインしてから、もう一度「Access Control」を開く
- すると、今度は権限があるので画面が表示される

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/697b8add-8dc2-8064-b5eb-e778b59b2ba7.jpeg)

- もう一度 `user` でログインしなおして、また「Access Control」を開く
- ここで、 URL の末尾に `;aaa` と追加して再アクセスする

![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/945e1d3b-208d-2340-5614-8bc67f7cf991.jpeg)

- すると、権限がないはずなのに画面が表示できてしまう

```java:アクセス権限のチェックをしている独自Filterの実装
...

@WebFilter(value="/*", filterName="authorizationFilter")
public class AuthorizationFilter implements Filter {
    private static final Map<String, String> PATH_AUTHORITY_MAP;
    
    static {
        Map<String, String> map = new HashMap<>();
        
        map.put("/admin.jsp", "admin");
        
        PATH_AUTHORITY_MAP = Collections.unmodifiableMap(map);
    }

    ...

    private boolean needsToValidateAuthorization(HttpServletRequest request) {
        String uri = request.getRequestURI();
        return PATH_AUTHORITY_MAP.keySet().stream().anyMatch(uri::endsWith);
    }

    ...
```

- キーに権限が必要なパス（`/admin.jsp`）、値に必要な権限（`admin`）を持った `Map` を定義
- `HttpServletRequest#getRequestURI()` で取得した URL の末尾が権限チェックが必要なパスかどうかで認可のチェックが必要か判断している
- `/admin.jsp;aaa` のようなパスパラメータが入った URL がくると条件にマッチしなくなり、認可のチェックがスルーされてしまう


### Spring Security の場合
![spring-security.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/36b67852-c358-fdc3-f5cc-6e8ce9c9ad50.jpeg)

- 当然パスパラメータのことも考慮してチェックしてくれる



---
## まとめ
![まとめ.jpg](https://qiita-image-store.s3.amazonaws.com/0/28302/504a9ccf-d289-d7e0-eb60-6d5406a59af4.jpeg)




[^1]: [安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構](https://www.ipa.go.jp/security/vuln/websecurity.html)
[^2]: [Java Servlet Specification Version 3.1](https://jcp.org/en/jsr/detail?id=340)