Webセキュリティ勉強会 Part-2

[Webセキュリティ勉強会 Part-1]:https://qiita.com/megmogmog1965/items/317fe05770006c4cb27a
[OWASP Juice Shop]:https://owasp.org/www-project-juice-shop/
[dangerouslySetInnerHTML]:https://ja.react.dev/reference/react-dom/components/common#common-props
[javascript: scheme]:https://developer.mozilla.org/ja/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web#%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%A0%E3%81%BE%E3%81%9F%E3%81%AF%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB
[CSP (Content-Security-Policy)]:https://developer.mozilla.org/ja/docs/Web/HTTP/CSP
[Vercel]:https://vercel.com/
[AWS Instance Metadata]:https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html


:::note
[Webセキュリティ勉強会 Part-1] の続きものです。
:::

# 目的

[Webセキュリティ勉強会 Part-1] では、Day 1 → Day 2 途中までは [OWASP Juice Shop] を題材にハンズオン学習を行いますが、以下の脆弱性に関しては [OWASP Juice Shop] の問題は難易度が高く短時間のハンズオンでやるには難しかったです。

1. Stored XSS (格納型クロスサイトスクリプティング)
1. CSRF (Cross-Site Request Forgery)
1. Clickjacking
1. SSRF (Server-Side Request Forgery)

そこで、上記４脆弱性の学習を目的とした Web サイトを作成しました。

https://vulnerable-web-site.vercel.app/

https://github.com/megmogmog1965/vulnerable-web-site

本書ではこのサイトを題材に、上記４脆弱性の解説をします。

# サイトアクセス

まず、この脆弱性デモサイトのアクセスの仕方を説明します。

https://vulnerable-web-site.vercel.app/signup

ユーザー登録画面で適当な「メールアドレス」、「パスワード」を入力して登録を行って下さい。メール送信とかはされないのでご安心を。

![fe7f8a18-213e-7bfc-f652-ffed211264fa.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/61aaea5a-5261-ed80-1004-45188367d7d6.png)

登録した「メールアドレス」、「パスワード」でログインします。

https://vulnerable-web-site.vercel.app/login

ログイン後は「Profile」ページで、自身のプロフィール設定を変更できる。たったそれだけのサイトです。

![f02c8df1-8fbc-e80e-f533-0061078d809d-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/deda7ebf-3661-fcff-392e-4e28f05ac3d1.png)

# 解説

本 Web サイトを題材に、次の４脆弱性を説明します。

1. Stored XSS (格納型クロスサイトスクリプティング)
1. CSRF (Cross-Site Request Forgery)
1. Clickjacking
1. SSRF (Server-Side Request Forgery)

## 1. Stored XSS (格納型クロスサイトスクリプティング)

近年のフロントエンド開発では React, Vue, Angular 等のフレームワークを使って開発ことが多く、これらのフレームワークは自動でサニタイズをしてくれます。

```jsx
const userInput = `<script>alert('xss')</script>`

// ちゃんと、テキストノードはサニタイズされる
// &lt;script&gt;alert('xss')&lt;/script&gt;
return(
  <div>{ userInput }</div>
)
```

しかし、フレームワークのサニタイズ対応は完璧ではありません。
例えば React の場合、主に次の２点が XSS を許すセキュリティホールとして知られています。

1. [dangerouslySetInnerHTML]
1. [javascript: scheme]

:::note
Vue.js 公式でも同様の注意喚起がされていますね！
* https://ja.vuejs.org/guide/best-practices/security
:::

### [dangerouslySetInnerHTML]

React の全ての Component は [dangerouslySetInnerHTML] という Attribute があります。
文字列 (変数) で与えられた HTML を解釈して、実行時に動的に DOM を生成できます。

これは内部的には単に [Element: innerHTML](https://developer.mozilla.org/ja/docs/Web/API/Element/innerHTML) を呼び出すのですが、文字列として渡した HTML から DOM 生成される為、悪意あるコードの埋め込みを許してしまいます。

```jsx
const userInput = `<iframe src="javascript:alert('xss')" />`

return(
  <div dangerouslySetInnerHTML={{ __html: userInput }} />
)
```

脆弱性デモサイトでは `Memo` テキストエリアに入力した内容が `dangerouslySetInnerHTML` を使って描画される様になっています。 ([※ソース](https://github.com/megmogmog1965/vulnerable-web-site/blob/1.0.0/app/(header)/profile/page.tsx#L43))

https://vulnerable-web-site.vercel.app/profile/edit

![e945bed4-df82-af6b-c962-e4c83a859210.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/ce3535d1-55ba-34db-86f1-8bf6070ae2a3.png)

### [javascript: scheme]

分かってないとやってしまう可能性が高いのはこちらで、 [javascript: scheme] によるコード埋め込みです。

次の様に、ユーザー入力をアンカー要素 `<a href=...` の URL に指定すると、 [javascript: scheme] を用いた悪意あるコードの埋め込みを許してしまいます。

```jsx
const userInput = `javascript:alert('xss')`  // 開発者は "https://..." 入力を期待しているが...

return(
  <a href={ userInput } />
)
```

脆弱性デモサイトでは `Image URL` テキストフィールドに入力した URL が、プロフィール画像をクリックした際の宛先 URL になっています。 ([※ソース](https://github.com/megmogmog1965/vulnerable-web-site/blob/1.0.0/app/(header)/profile/page.tsx#L35))

https://vulnerable-web-site.vercel.app/profile/edit

![a3ea5c7f-bab8-fc28-a30c-3a9cc8da7bd6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/b18a3e33-4834-74b1-a3bf-fb27ae7973a4.png)

⇩⇩⇩

![45a12774-de51-467c-e125-328252b2638a-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/78458d79-c7d6-0cef-9682-a3263441a498.png)

![616a2ac1-c47b-bebe-559d-13729bf0542d.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/7d69c6b1-0758-4ffc-9646-e2f03ef883db.png)

### XSS 対策

2024年現在は、XSS 脆弱性に対して有効な対策があります。[CSP (Content-Security-Policy)] を適用することです。

https://developer.mozilla.org/ja/docs/Web/HTTP/CSP

サイトへの Top-Level-Navigation アクセスに対して、レスポンスに `Content-Security-Policy` ヘッダを付与します。 ([※ソース](https://github.com/megmogmog1965/vulnerable-web-site/blob/1.0.0/middleware.ts#L41))

```
Content-Security-Policy: script-src 'self'
```

[CSP (Content-Security-Policy)] が適用されたサイトでは、悪意あるコード (インラインスクリプト) はブラウザが実行を防ぎます。

![7bc9c505-7210-cb47-086e-5df0b53953ae.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/3c69259a-f2fc-92a0-b151-e72d5f8731ff.png)

実は [CSP (Content-Security-Policy)] はコードが「悪意あるかどうか」を判断しません。次の様な「インラインコード」を丸ごと全て禁止にしています。

```html
<!-- ❌ これはインラインなので NG -->
<script type="text/javascript">
  alert('xss');
</script>

<!-- ❌ これはインラインなので NG -->
<iframe src="javascript:alert('xss')" />
```

逆に、次の様に `src=` 要素を指定してロードした `<script>` はインラインとはみなされません。

```html
<!-- ✅ これは OK ! インラインではない -->
<script src="/path/to/javascript.js" />
```

ほぼ全ての XSS は「インラインコード」によって実現される為、[CSP (Content-Security-Policy)] は XSS 対策にとても効果的です。


## 2. CSRF (Cross-Site Request Forgery)

2020年に Google を中心として、Web 標準で COOKIE 仕様の `SameSite` 属性が追加されました。

https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure?hl=ja

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value

これによって昨今では、CSRF (Cross-Site Request Forgery) はかなり起こりづらくなっています。

従って、これから原理を説明はしますが、発生するシチュエーションは次の通り限定的です。

1. サイトの認証情報を Cookie で保存している
1. その Cookie には `SameSite=None` が明示的に指定 (*1) されている
1. クロスサイトからのアクセス対象は `<form action="※攻撃対象のURL">...</form>` である (*2)

:::note
1. SameSite 属性は現在 Default 値が `SameSite=Lax`であり、標準で CSRF 対策がされます
1. [Ajax (`XHR`, `Fetch` API) でのアクセス](https://developer.mozilla.org/ja/docs/Web/API/Fetch_API/Using_Fetch#%E8%B3%87%E6%A0%BC%E6%83%85%E5%A0%B1%E3%81%A4%E3%81%8D%E3%81%AE%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%AE%E9%80%81%E4%BF%A1) は CORS で明示的に指定したドメインにしか、Cookie は送信されません

![ba98123a-594d-ea06-a48b-cea84a8277eb.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/0d3f5288-8d19-0ed8-96a3-a73714b0b3aa.png)
:::

攻撃手法の解説は、実際に JSFiddle で書いた攻撃コード (デモサイト) を見た方が速いでしょう。

https://jsfiddle.net/megmogmog/yxkcqd42/

```html
<form action="https://vulnerable-web-site.vercel.app/api/userUpdateForm" method="post" id="form">
  <input type="hidden" name="name" id="name" value="CSRF !!" />
  <input type="hidden" name="message" id="message" value="CSRF !!" />
  <input type="hidden" name="imageUrl" id="imageUrl" value="http://example.com" />
  <input type="submit" value="submit" />
</form>
```

```javascript
// Automatically submit form.
const form = document.getElementById('form');
form.submit();
```

全く無関係の別のサイト (攻撃者) から、`<form method="post">...</form>` による POST リクエストが攻撃対象のサイトに送信されます。

この時、攻撃者のサイトには認証に関わるコード・情報は一切ありません。

しかし、被害者がこのサイトにアクセスすると、攻撃対象のサイトに POST リクエストが送信される際に、ブラウザに保存された Cookie が送付されてしまいます。


## 3. Clickjacking

実際に JSFiddle で書いた攻撃コード (デモサイト) を見た方が速いでしょう。

https://jsfiddle.net/megmogmog/7w35ry2u/

次の画像は攻撃者が用意したサイトです。 
Click me ! ボタンを押下すると、攻撃対象のサイトで「ログアウト」操作がされてしまいます。

* サイト内に `<iframe>` で攻撃対象のサイトを埋め込みしています。
* `<iframe>` で埋め込んだサイトの上に別の要素を被せて、視覚的に見えない様にします
* 被せた要素に CSS `pointer-events: none` を指定する事で、クリックイベントを下部の `<iframe>` まで貫通させます

![52d5c83e-aed5-0a71-83bf-8ec94ad9d4ef.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/b24f188e-f7ec-642b-eda6-c7b50ae18b57.png)

この脆弱性への対策は、外部のサイト (クロスサイト) で `<iframe>` 埋め込みを許さない事です。

サイトへの Top-Level-Navigation アクセスに対して、レスポンスに `X-Frame-Options: SAMEORIGIN` ヘッダを付与します。 ([※ソース](https://github.com/megmogmog1965/vulnerable-web-site/blob/1.0.0/next.config.js#L9))

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Frame-Options

```
X-Frame-Options: SAMEORIGIN
```


## 4. SSRF (Server-Side Request Forgery)

### 実例

:::note warn
SSRF 脆弱性だけは [インターネット上に公開している脆弱性デモサイト](https://vulnerable-web-site.vercel.app/) では有効にしていません。

実際に攻撃が成功すると、 **このデモサイトをホスティングしている [Vercel] に被害が及ぶ可能性がある** 為です。
:::

SSRF 脆弱性によって被害が出た有名な実例があります。

https://logmi.jp/business/articles/329553

> ※ 出典: ログミーBiz・徳丸浩 様

このケースでは、攻撃者は SSRF 脆弱性を用いて [AWS Instance Metadata] の取得に成功しました。
[AWS Instance Metadata] には **AWS のアクセスキー** などが含まれています。

```shell
# Amazon EC2 サーバー内部で有効な、プライベート IP アドレス `169.254.169.254`.
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}

{
  "AccesskeyId": "...",
  "SecretAccessKey": "...",
  ...
}
```

### 説明

例えばあなたの Web サイトにインターネット URL を入力するフォームがあるとします。

![2482eb8c-aca0-b243-6d1e-c48fe14f302b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/daa75b7d-7cc7-24a3-6156-c6014d9e53d4.png)

そのユーザー入力 (URL) はサーバーへ送信され、サーバー内部のコードで HTTP リクエストを実行します。

```javascript
// express で書いた 「脆弱なサーバー」                                                                                                    
const express = require('express')
const app = express()

app.get('/', async (req, res) => {
  // クエリパラメーター `?url=` で指定した URL のリソース本文を                                                                             
  // そのまま帰す、HTTP エコーサーバー                                                                                                      
  const url = req.query.url
  const response = await fetch(url)
  const text = await response.text()

  res.send(text)
})

app.listen(3000, () => {
  console.log(`Echo server listening on port 3000`)
})
```

上記の様なリクエストを転送・プロキシするサーバーは、サーバーが属するプライベートネットワーク上のリソースへの間接的なアクセスを許してしまいます。

次のシーケンスは、上記「脆弱なサーバー」への HTTP リクエスト `https://{脆弱なサーバー}?url=http://169.254.169.254/...` を説明した図です。

:::note warn
`169.254.169.254` はプライベート IP アドレスの為、本来インターネット上からはアクセスできません。
:::

```mermaid

sequenceDiagram
    participant A as 攻撃者
    participant S as 脆弱なサーバー
    participant I as 内部ネットワークリソース<br />(169.254.169.254)

    A->>S: 悪意のあるリクエスト<br>(?url=http://169.254.169.254/...)
    Note over S: サーバーはリクエストを検証しない
    S->>I: リクエストの転送<br />http://169.254.169.254/...
    Note over I: 内部リソースにアクセス
    I-->>S: レスポンス
    S-->>A: レスポンス（内部情報を含む）
    Note over A: 攻撃者は内部情報を受け取る
```

### デモサイト (localhost) で試してみる

脆弱性デモサイトを localhost で起動します。

```shell
git clone https://github.com/megmogmog1965/vulnerable-web-site

... (省略) ...
export ENABLE_SSRF=true
npm run dev
```

Instance metadata (っぽいもの) を返す疑似サーバー (`http://localhost:3001`) を立てます。

> ※前述の `169.254.169.254` に当たるもの。

```javascript:index.js
const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.json({ id: '......', key: 'xxxxxxx' });
});

app.listen('3001', () => {
    console.log('Example app listening on port 3001');
});
```

```shell
npm install express
node index.js
```

脆弱性デモサイトにアクセスし、`Image URL` を `http://localhost:3001` にして保存します。

http://localhost:3000/profile/edit

![b1ece23e-f0c7-3493-2d42-5f638286155b.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/df6b2cbc-01c7-de08-df81-b68e03a9b7f1.png)

壊れたプロフィール画像を Chrome DevTools の Inspector で見てみましょう。

![43a66a77-ed19-5b20-daa3-b8aa8fba1664.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/ca6e9785-4030-5071-6198-6d722ab60807.png)

img タグに `data:` 埋め込みしています。

![f906254e-3c41-4000-f74c-293fe4a961c7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/548cf378-81b2-5bd0-9bec-19fd06ee3f3f.png)

別タブで開くと、この様な結果が得られました。

![1326a837-01cb-5598-81fe-5e10cd70e8d6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60131/1d75248a-7251-3635-fcc1-b1e6b27406c7.png)

:::note warn
昨今、この様な data url は本番サイトでは少ないとは思いますが、脆弱性再現の一例として実装しました。
:::