Skip to content

Commit 0664943

Browse files
committed
Vue.jsで脆弱なアプリを作って学ぶ
1 parent 5941c46 commit 0664943

File tree

5 files changed

+255
-1
lines changed

5 files changed

+255
-1
lines changed

source/_posts/2025/20251016a_Vue.js連載_2025_を始めます.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@ lede: "Vue.jsの魅力と可能性をさらに深く探るべく、フューチ
2626
| 10/22(水) | 山本 竜玄 | [Vueでモバイルアプリ開発](/articles/20251022a/) |
2727
| 10/23(木) | 澁川 喜規 | [Vueのフロントエンドをセキュリティのしっかりしたコンテナにする](/articles/20251023a/) |
2828
| 10/24(金) | 松本 朝香 | 初心者がSPA(Single Page Application)を実装してみた |
29-
| 10/27(月) | 永井 優斗 | 脆弱なアプリを作って&使って学ぶ、Vue.jsのセキュリティ観点で気をつけたいポイント |
29+
| 10/27(月) | 永井 優斗 | [脆弱なアプリを作って&使って学ぶ、Vue.jsのセキュリティ観点で気をつけたいポイント](/articles/20251027a/) |
3030

3131
[Vue Fes Japan 2025](https://vuefes.jp/2025/)も10/25と開催間近、[フューチャーもゴールドスポンサー](https://vuefes.jp/2025/sponsors/future)として協賛しております。一緒に盛り上げていきましょう。
3232

Lines changed: 254 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,254 @@
1+
---
2+
title: "Vue.jsで脆弱なアプリを作って学ぶ、セキュリティ面で気をつけたいポイント"
3+
date: 2025/10/27 00:00:00
4+
postid: a
5+
tag:
6+
- Vue.js
7+
- 脆弱性
8+
category:
9+
- Frontend
10+
thumbnail: /images/2025/20251027a/thumbnail.png
11+
author: 永井優斗
12+
lede: "Vue.jsで実際にわざと脆弱なアプリを作り、そこからXSS・Cookie・CSRF・レート制限といった脆弱性を一気に体験してみます。"
13+
---
14+
<img src="/images/2025/20251027a/image.png" alt="image.png" width="1200" height="800" loading="lazy">
15+
16+
※上記サムネイルはChatGPTにて本記事を読み込ませて生成しました。
17+
18+
Future Value Group(FVG)の永井優斗です。
19+
20+
[Vue.js連載](/articles/20251016a/)の8本目です。Vue.js は使いやすく、直感的なテンプレート構文でフロントエンド開発を加速してくれます。しかし、その便利さゆえに「セキュリティをうっかり見落とす」ことがあるのも事実です。
21+
22+
この記事では、Vue.jsで実際に**わざと脆弱な**アプリを作り、そこからXSS・Cookie・CSRF・レート制限といった脆弱性を一気に体験してみます。ちなみにソースの8割ぐらいは生成AIに生成してもらいました。この記事も生成AIと相談しながら書きました。すごいね。
23+
24+
教材アプリは[こちらのGitHub](https://github.com/yut0naga1/vue-ctfs)上で公開しています。
25+
26+
※試すことを優先しているのでUIはシンプルに。そのうちきれいにしたいなあ…
27+
28+
# はじめに
29+
30+
今回の教材アプリは Vue 3 + Vite で構築し、バックエンドには Express を利用します。
31+
32+
「脆弱版」と「安全版」を切り替えて、落とし穴と対策を比較できる構成です。
33+
34+
```sh
35+
01-vulnerable/ # ← わざと脆弱な実装
36+
02-safe/ # ← 対策を施した実装
37+
```
38+
39+
ローカルで起動してお試しください。
40+
41+
教材アプリはセキュリティの知識を駆使して情報を抜き取るゲームである、「CTF(Capture The Flag)」のような形で作成しており、脆弱版では各課題にて「攻撃」が成功すると100点のスコアがGetできます。全部で3問あります。
42+
43+
この記事はCTFの「答え」にあたるものでもあるので、セキュリティ知識を試したい方は先に教材アプリを試してみてから本記事をお読みください。
44+
45+
::: note warn
46+
**警告**
47+
意図的に脆弱性をふくめているアプリケーションですので、公開環境やインターネットに接続された環境で実行しないでください。学習用にローカルで閉じた環境でのみ利用してください。
48+
49+
また、本記事や教材アプリは代表的な脆弱性の学習のための資料であり、攻撃を目的としたものではございません。
50+
:::
51+
52+
起動方法:
53+
54+
```bash
55+
cd 01-vulnerable
56+
npm install
57+
npm run server # APIサーバ (http://localhost:3001)
58+
npm run dev # フロントエンド (http://localhost:5173) 上のnpm run serverとは別のターミナルで実行してください
59+
```
60+
61+
# 1. DOM XSS(v-htmlの乱用)
62+
63+
Vue.js では、テンプレートの中で変数を埋め込む際、`{{ userInput }} `のように記述すると、自動的にHTMLがエスケープされます。
64+
そのため、通常の使い方ではユーザーの入力からXSSは発生しません。
65+
66+
しかし、「HTMLを直接描画したい」という欲求に負けて v-html を使うと、XSSの標的になるかもしれません。
67+
68+
## v-htmlとは
69+
70+
```html
71+
<div v-html="someHtml"></div>
72+
```
73+
74+
このように書くと、someHtml の中身がそのままHTMLとして挿入されます。
75+
76+
つまり、ユーザー入力が `<p>こんにちは</p>` なら、実際に `<p>` タグが生成されます。そしてユーザー入力が `<img src=x onerror="alert(1)">` だったら……?そのままスクリプトが実行されます。
77+
78+
## 実際にXSSを起こしてみよう
79+
80+
教材アプリでは「脆弱UI(XSS)」という課題ページがあります。
81+
82+
手順:
83+
84+
- テキストエリアに以下を入力してください。
85+
86+
```html
87+
<img src=x onerror="alert(window.__FLAG_XSS)">
88+
```
89+
90+
- 下のプレビュー領域が v-html で描画されています。
91+
92+
そこに画像タグが挿入され、onerror 属性が評価されるとアラートが表示されます。ここで表示される `window.__FLAG_XSS` は教材用のフラグでグローバルな秘密変数を想定しています。実運用ならこのような「グローバルな秘密変数」は致命的です。
93+
94+
#### 攻撃を試してみて何も起きないときは以下を確認してみてください。
95+
96+
- `<script>` タグは innerHTML 経由では実行されません。イベント属性(onerror / onload)を使ってください
97+
- CSP(Content-Security-Policy)が有効な場合、inline スクリプトがブロックされることがあります
98+
- 要素が正しく挿入されているか、開発者ツールの Elements タブで確認しましょう
99+
100+
## 対策
101+
102+
- v-html を安易に使わない
103+
- どうしてもHTMLを扱う場合は、ホワイトリスト方式のサニタイズを適用する
104+
- ユーザー入力は常に **「テキスト」として表示** することを原則に
105+
106+
# 2. Cookieの危険な使い方
107+
108+
続いて、Cookie周りの落とし穴です。
109+
110+
教材の2つ目の課題は「CookieにセッションIDを保存しているが、HttpOnly が設定されていない」例を取り扱います。
111+
112+
## document.cookieとは
113+
114+
ブラウザ内でアクセス可能なCookieを読み取るAPIです。
115+
116+
```js
117+
console.log(document.cookie)
118+
// => "sid=demo-session; theme=light"
119+
```
120+
121+
しかし本来、セッションIDなどの機密情報はサーバー専用で使うべきです。
122+
それをHttpOnly無しで発行すると、XSSを使って誰でも読める状態になります。
123+
124+
## Cookieから`sid`を盗みだす
125+
126+
脆弱版では sid というCookieが HttpOnly: false で発行されています。
127+
そのため、以下のコードで誰でも読み取れます。
128+
129+
```html
130+
<img src=x onerror="alert(document.cookie)">
131+
```
132+
133+
もしアラートに sid=demo-session と出たら、XSSがCookieを盗み出せたということです。
134+
攻撃者はこの値を使って、別の環境で「なりすましログイン」することができます。
135+
136+
#### 攻撃を試してみてアラートが空だった場合は以下を確認してみてください
137+
138+
- HttpOnly が有効になっている(安全版を開いていないか?)
139+
- オリジンが異なる(5173と3001問題)
140+
- Viteのプロキシ設定でcookieDomainRewriteが漏れている
141+
142+
## 対策
143+
144+
- セッションIDなどのCookieには必ずHttpOnlyとSecureを付与
145+
- SameSite=Lax 以上を設定してクロスサイト送信を制限する
146+
- 機密情報をフロント側のJSから参照できないように設計する
147+
148+
# 3. CSRF
149+
150+
次に、CSRF(クロスサイトリクエストフォージェリ)の課題です。
151+
152+
バックエンドの話も入ってしまうんですが、フロントエンドの開発者も知っておくべきだと思うので入れてみました。
153+
154+
ここでは、ユーザーが意図していない送金が実行されてしまう脆弱なAPIを見ます。
155+
156+
## CSRFとは?
157+
158+
ユーザーが認証済み状態(Cookieを持っている)で、攻撃者のサイトを開いたとき、そのブラウザが自動的にCookieを添えてリクエストを送ってしまう、これがCSRF攻撃の基本構造です。
159+
160+
<img src="/images/2025/20251027a/image_2.png" alt="image.png" width="680" height="462" loading="lazy">
161+
162+
[情報処理推進機構(IPA):安全なウェブサイトの作り方 - 1.6 CSRF(クロスサイト・リクエスト・フォージェリ)より引用](https://www.ipa.go.jp/security/vuln/websecurity/csrf.html)
163+
164+
## 意図せず残高を減らす「罠ページ」
165+
166+
教材の「CSRF」課題では、次のようなAPIがあります。
167+
168+
```sh
169+
GET /api/csrf/transfer?to=attacker&amount=100
170+
```
171+
172+
1. /api/wallet を開くと、現在の残高が表示されます(例:1000)
173+
2. 攻撃者ページを開きます(以下を保存してブラウザで開く):
174+
175+
```html
176+
<html>
177+
<body>
178+
<h1>かわいいねこの画像だよ!</h1>
179+
<img src="http://localhost:5173/api/csrf/transfer?to=attacker&amount=100">
180+
</body>
181+
</html>
182+
```
183+
184+
3. ページを開くと自動的にリクエストが発生します
185+
4. `/api/wallet`を再確認すると、残高が減っていることを確認します
186+
187+
※ 教材アプリでは攻撃が成功した際にスコア付与のため、csrfCode が付与されています。それをフォームに入力して提出してください。
188+
189+
## 対策
190+
191+
1. 副作用のある操作はGETにしない(POST限定)
192+
2. CSRFトークンを導入する
193+
194+
```javascript
195+
// 発行時
196+
res.cookie('csrfToken', token, { httpOnly: false, sameSite: 'lax' })
197+
198+
// 検証時
199+
if (req.cookies.csrfToken !== req.headers['x-csrf-token']) {
200+
return res.status(403).json({ error: 'csrf check failed' })
201+
}
202+
```
203+
204+
3. SameSiteを適切に設定(Lax or Strict)
205+
4. Referer / Origin チェックを補助的にする
206+
5. レート制限で濫用防止(次の章で説明します)
207+
208+
# 4.(補足) レート制限なし
209+
210+
CSRFやXSSなどの被害を拡大させるのは「無限リクエスト」です。
211+
212+
同一IPやユーザーが短時間に何百回もアクセスできる状態は危険です。
213+
214+
## Expressで簡単にレート制限を導入する
215+
216+
以下のように`express-rate-limit`を設定することで簡単にレート制限を導入できます。
217+
218+
```js index.js
219+
import rateLimit from 'express-rate-limit'
220+
221+
const limiter = rateLimit({
222+
windowMs: 30_000, // 30秒
223+
max: 10,
224+
message: { ok:false, error: 'rate limited' }
225+
})
226+
227+
app.post('/api/transfer', limiter, (req, res) => {
228+
// 安全な送金処理
229+
})
230+
```
231+
232+
これだけで「30秒に10回まで」という制限を導入できます。
233+
234+
短いコードですが、セキュリティ上の効果は絶大です。
235+
236+
# まとめ
237+
238+
|脆弱性|原因|対策|
239+
|:--:|:--:|:--:|
240+
|DOM XSS|v-htmlの乱用|サニタイズ、`{{ }}`で表示|
241+
|Cookie漏洩|HttpOnlyなし|HttpOnly, Secure, SameSite設定|
242+
|CSRF|GETで副作用、トークン未検証|POST限定、CSRFトークン|
243+
|レート制限なし|無限アクセス|express-rate-limit などで制限|
244+
245+
# 最後に
246+
247+
Vue.js は便利ですが、安全性を担保する仕組みは「フレームワークまかせ」では不十分です。
248+
249+
「なぜ危ないのか」を一度体験しておくことで、脆弱性への実感を持ってもらえたらうれしいです!
250+
251+
脆弱なアプリを作らないように気をつけながらフロントエンド開発をEnjoyしましょう!
252+
253+
**GitHubリポジトリ**
254+
[vue-ctfs(脆弱版と安全版を含む)](https://github.com/yut0naga1/vue-ctfs)
1.15 MB
Loading
191 KB
Loading
50.3 KB
Loading

0 commit comments

Comments
 (0)