SPAセキュリティ超入門

680.4K Views

September 25, 22

security php javascript

スライド概要

SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。
本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら、現実的な対策について紹介します。LaravelやReact以外のフレームワーク利用者にも役立つ説明を心がけます。
PHPカンファレンス2022での講演資料です。

PHPカンファレンスでの動画URL
https://www.youtube.com/watch?v=jZ6sWyGxcCs

徳丸浩

@ockeghem

スライド一覧

徳丸本の中の人 OWASP Japanアドバイザリーボード EGセキュアソリューションズ取締役CTO IPA非常勤職員 YouTubeチャンネル: 徳丸浩のウェブセキュリティ講座 https://j.mp/web-sec-study

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

SPAセキュリティ入門～PHP Conference Japan 2021

security

徳丸浩 286.5K

ウェブセキュリティのありがちな誤解を解説する

security php

徳丸浩 52.9K

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

security

徳丸浩 36.1K

Webアプリケーション開発に潜むリスクのケーススタディ

security cookie

徳丸浩 26.6K

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

security aws

徳丸浩 24.6K

オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法

security

徳丸浩 22.3K

各ページのテキスト

徳丸浩の自己紹介 • 経歴 – 1985年京セラ株式会社入社 – 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社(現社名:EGセキュアソリューションズ株式会社)設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始 – 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ • 現在 – – – – EGセキュアソリューションズ株式会社取締役CTO https://www.eg-secure.co.jp/ 独立行政法人情報処理推進機構非常勤研究員 https://www.ipa.go.jp/security/ 著書「体系的に学ぶ安全なWebアプリケーションの作り方（第2版）」(2018年6月) YouTubeチャンネル「徳丸浩のウェブセキュリティ講座」 https://j.mp/web-sec-study – 技術士（情報工学部門）徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 2

本日お話したいこと • SPA(Single Page Application)とは • SPAと攻撃経路 • JavaScriptによる検証はバイパスできる • 認可制御不備 • SQLインジェクション • クロスサイトスクリプティング(XSS) • クロスサイトリクエストフォージェリ(CSRF) • まとめ ※ コード例には、ReactとLaravelを用います徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 3

SPA（Single Page Application）の構造ページ遷移をしないのでJavaScriptの変数は保持される。ただし、ページ遷移、戻る、リロードで変数の値はリセットされる SPA → セッション管理あるいは localStorageによりデータを引き継ぐ HTML JS XHR/ Fetch コンテンツ配信 Webサーバー徳丸浩のウェブセキュリティ講座 JSON 処理 APIサーバー © 2022 Hiroshi Tokumaru 6

SPAのHTML（いわゆるガワ）はとてもシンプル <!DOCTYPE html> <html lang="en"> <head> クライアントアプリ <link rel="manifest" href="/manifest.json" /> の実体はJavaScript <title>React App</title> <script defer="defer" src="/static/js/main.js"></script> <link href="/static/css/main.css" rel="stylesheet" /> </head> <body> <noscript>You need to enable JavaScript to run this app.</noscript> <div id="root"></div> </body> HTMLの実体は div要素一つだけ </html> 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 7

10.

11.

DOMとは? <html> <head> <title>HTMLサンプル</title> Document html テキストノード head </head> <body> <h1>今日（9月25日）は何の日?</h1> 属性ノード title HTMLサンプル <p id="p0925"> 10円カレーの日<br /> 藤ノ木古墳記念日<br /> 山田邦子の日 body h1 今日（8月11日）は何の日? </p> </body> </html> p id 10円カレーの日 br 今日（9月25日）は何の日? 藤ノ木古墳記念日 10円カレーの日藤ノ木古墳記念日山田邦子の日徳丸浩のウェブセキュリティ講座要素ノード br 山田邦子の日 © 2022 Hiroshi Tokumaru 11

12.

JavaScriptによるDOM操作の基本（Vanilla JS） <html> <body> <div id="div1"></div> </body> <script> const div1 = document.getElementById('div1') // p要素生成 const p = document.createElement('p') // テキストノード生成 const txt = document.createTextNode('バナナ') // テキストノードをp要素にぶら下げる p.appendChild(txt) // p要素をdiv要素にぶら下げる div1.appendChild(p) </script> </html> 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 12

13.

Reactの表示はJSXが一般的 const SomeApp = () => { return ( <div>{ JavaScriptの式 }</div> JSの中でHTMLタグが使える ) } • JSXはトランスパイラ（Babel）により通常のJavaScriptに変換される • JSX中では { } の中にJavaScriptの式（文字列）を書くと、式の値が展開されて表示される。HTMLエスケープは必要ない徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 13

14.

15.

16.

SPAのセッション管理方式 1 セッションID方式 POST /login {"id":"bob","pass":"123456"} SESSID=f8d92b0… API Front End SESSID=f8d92b0… Store ビジネスロジック {"email":"bob@example.jp"} 表示ロジック DB SESSID=f8d92b0… 5:bob,bob@example.jp 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru Session Storage f8d92b0…:5,bob 16

17.

SPAのセッション管理方式 2: ステートフルトークン POST /login {"id":"bob","pass":"123456"} token=a94c5d… API Front End token=a94c5d… Store ビジネスロジック {"email":"bob@example.jp"} 表示ロジック DB localStorage a94c5d…:id=5 5:bob,bob@example.jp token=a94c5d… 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 17

18.

SPAのセッション管理方式 3 ステートレストークン(JWT等) POST /login {"id":"bob","pass":"123456"} token=eyJhbG… API Front End Store token=eyJhbG… ビジネスロジック {"email":"bob@example.jp"} 表示ロジックデコード&検証 {"sub":"5","exp":17…} localStorage 5:bob,bob@example.jp DB token=eyJhbG… 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 18

19.

Laravel APIのセッション管理方式名セッションID ステートフルトークンステートレストークン(JWT) ブラウザ側保管場所 Cookie localStorage localStorage データの保管場所ファイルやRedis DB トークンに内包保管できる情報認証情報 + なんでも認証情報 + 権限認証情報 +α スケーラビリティ小～中中大即時ログアウト容易容易困難一斉ログアウト工夫を要する容易困難 Laravelでの実装 Sanctum （SPA認証） Sanctum（APIトークン） tymon/jwt-auth CSRF脆弱性の可能性あり=対策要なしなし徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 19

20.

21.

22.

悪用例1: クライアント側バリデーションの回避 START HTMLやJavaScritによるチェック <input type="number" min="0" max="100"> ※ 0～100の数値のみ許容 HTMLやJavaScriptによるチェック（バリデーション等）は攻撃者は回避可能 No OK? Yes 処理実行(API) エラー END 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 22

23.

24.

25.

パスワード変更機能の脆弱な実装利用者 www.example.com POST /auth HTTP/1.1 {"currentPass":"P@assword"} example.jp // 再認証に成功したら // パスワードを変更する if (authCheck()) { changePassword() } else { error("Auth Error") } HTTP/1.1 200 OK POST /changepassword HTTP/1.1 {"newPass":"123456"} HTTP/1.1 200 OK 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru パスワード変更 25

26.

[beta]

再認証をバイパスしてパスワード変更が可能
攻撃者
www.example.com

POST /auth HTTP/1.1
{"currentPass":"P@assword"}

HTTP/1.1 200 OK

$ curl -X POST -H "Content-Type:
application/json" -d '{"newPass":"123456"}
https://www.example.com/changepassword

POST /changepassword HTTP/1.1
{"newPass":"123456"}
HTTP/1.1 200 OK

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

26

https://www.example.com/changepassword

27.

28.

認可制御不備の典型的パターン(1) 利用者 http://example.jp/login http://example.jp/logindone ログインしました ID パスワードログイン秘密情報をどうぞ情報リソースのURLを知っていると認証なしで情報が閲覧できる徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 攻撃者 http://example.jp/secret 秘密情報・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ URL を知っていると未ログインでも閲覧可能 28

29.

[beta]

APIの認可制御不備（正常系）
利用者

example.jp

POST /login HTTP/1.1
example.jp

<script>
xhr = new XMLHttpRequest()
xhr.open('POST', '/user')
xhr.send(…)
</script>

HTTP/1.1 200 OK
Set-Cookie: SESSID=xxxx
GET /secret HTTP/1.1
Cookie: SESSID=xxxx

HTTP/1.1 200 OK
{"text":"Secret Information…"}
徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

29

30.

[beta]

APIの認可制御不備（攻撃）
攻撃者

example.jp

POST /login HTTP/1.1
HTTP/1.1 200 OK
Set-Cookie: SESSID=xxxx

$ curl https://example.jp/secret
{"text":"Secret Information…"}

GET /secret HTTP/1.1
<Cookie なし>

HTTP/1.1 200 OK
{"text":"Secret Information…"}
徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

認証チェック
なしに秘密情
報を返す
30

31.

[beta]

Laravel/Sanctum の認証設定
// routes/api.php

脆弱なルーティング設定

Route::get('secret', [SecretController::class, 'secret']);

// Laravel/Sanctumで認証を要求するルーティング設定例(routes/api.php)

Route::middleware('auth:sanctum')->group(function(){
Route::get('secret', [SecretController::class, 'secret']);
});

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

31

32.

認可制御不備の典型的パターン(2) ID:yamadaでログインユーザ情報 http://example.jp/profile.php?id=100246 ようこそ yamadaさんユーザID:yamada メールアドレス:xx 氏名: 山田〇〇電話: 03-xxxx-xxxx 情報リソースのIDを変更すると権限外の情報が参照できる http://example.jp/profile.php?id=100247 ようこそ yamadaさんユーザID:sato メールアドレス:xx 氏名: 佐藤△△ 電話: 06-xxxx-xxxx 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 内部ID 外部ID 100246 yamada 100247 sato ※アプリケーション内部では表示用の外部IDではなく、内部ID(一連番号)で管理されている 32

http://example.jp/profile.php?id=

33.

APIの認可制御不備（正常系）利用者 example.jp GET /tasks HTTP/1.1 Cookie: SESSID=xxxx example.jp タスク一覧 • 3 • 5 • 7 • 10 {"tasks":[3,5,7,10]} GET /tasks/10 HTTP/1.1 Cookie: SESSID=xxxx HTTP/1.1 200 OK {"id":10,"user_id":5,"subject":"Secret Task"} 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 33

34.

APIの認可制御不備（攻撃）攻撃者 example.jp GET /tasks HTTP/1.1 Cookie: SESSID=zzzz example.jp タスク一覧 • 2 • 4 • 6 {"tasks":[2,4,6]} GET /tasks/10 HTTP/1.1 Cookie: SESSID=zzzz HTTP/1.1 200 OK 権限がない情報が盗まれる {"id":10,"user_id":5,"subject":"Secret Task"} 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 34

35.

[beta]

ポリシーによる認可制御の実装例(Laravel)
// app/Policies/TaskPolicy.php
class TaskPolicy
{
use HandlesAuthorization;
public function view(User $user, Task $task)

// showコントローラに対応するポリシー

{
return $user->id === $task->user_id;

// タスクの持ち主のみがアクセスできる

}

}
// コントローラの定義
class TaskController extends Controller
{
public function show(Task $task)
{
$this->authorize($task); // ポリシーの確認
return $task;
}

}
徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

35

36.

認可制御不備の典型的パターン(3) 正常系一般向けメニュー http://example.jp/a001 管理者としてログイン http://example.jp/menu 投稿閲覧プロフィール攻撃一般ユーザとしてログイン http://example.jp/menu 一般機能一般機能管理者機能管理者用メニュー http://example.jp/b001 ユーザ登録アカウント停止ロック解除問い合わせ対応 URLを直接指定すると管理者用メニューが表示され実行もできる一般向けメニュー http://example.jp/a001 投稿閲覧プロフィール管理者用メニュー http://example.jp/b001 ユーザ登録アカウント停止ロック解除問い合わせ対応 URL 書き換えメニューの表示・非表示のみで制御している徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 36

37.

[beta]

APIの認可制御不備（正常系）
管理者

example.jp

POST /login HTTP/1.1
example.jp

<script>
xhr = new XMLHttpRequest()
xhr.open('POST', '/user')
xhr.send(…)
</script>

HTTP/1.1 200 OK
Set-Cookie: SESSID=xxxx
{"id":1}
PATCH /users/10 HTTP/1.1
Cookie: SESSID=xxxx
{"email":"carol@example.jp"}
HTTP/1.1 200 OK

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

管理者がメールア
ドレスを変更する
37

38.

[beta]

APIの認可制御不備（攻撃）
攻撃者（一般ユーザー）

example.jp

POST /login HTTP/1.1
example.jp

<script>
xhr = new XMLHttpRequest()
xhr.open('POST', '/user')
xhr.send(…)
</script>

HTTP/1.1 200 OK
Set-Cookie: SESSID=zzzz
{"id":6}
PATCH /users/10 HTTP/1.1
Cookie: SESSID=zzzz

※一般ユーザーからは呼び出されないエンドポイント

{"email":"carol@example.jp"}

HTTP/1.1 200 OK
徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

権限のないメール
アドレス変更
38

39.

認可制御不備の典型的パターン(4) 正常系一般ユーザとしてログイン Cookie: USER=normal 管理者としてログイン Cookie: USER=admin 攻撃投稿閲覧一般ユーザとしてログイン Cookie: USER=admin 投稿閲覧ユーザ登録アカウント停止 Cookieに保持した権限情報を変更しただけで管理者メニューが表示され、実行もできる投稿閲覧ユーザ登録アカウント停止フレームワークのStoreやlocalStorage、クッキーに権限情報を保持している徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 39

40.

[beta]

APIの認可制御不備（正常系）
管理者

example.jp

POST /login HTTP/1.1

localStorage

HTTP/1.1 200 OK
Set-Cookie: SESSID=xxxx
{"id":1, "role":1}

role:1

PATCH /users/10 HTTP/1.1
Cookie: SESSID=xxxx
{"role":1, "email":"carol@example.jp"}
HTTP/1.1 200 OK

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

管理者がメールア
ドレスを変更する
40

41.

[beta]

APIの認可制御不備（攻撃）
攻撃者（一般ユーザー）

example.jp

POST /login HTTP/1.1

localStorage

HTTP/1.1 200 OK
Set-Cookie: SESSID=zzzz
{"id":6, "role":0}

role:0
role:1

PATCH /users/10 HTTP/1.1
Cookie: SESSID=zzzz
{"role":1, "email":"carol@example.jp"}
HTTP/1.1 200 OK

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

権限のないメール
アドレス変更
41

42.

[beta]

Gateファサードによる認可実装例(Laravel)
// app/Providers/AuthServiceProvider.php
class AuthServiceProvider extends ServiceProvider
{
/* */
public function boot()
{
$this->registerPolicies();
Gate::define('admin', function ($user) { // adminポリシーの定義
return $user->role >= 1; // ユーザのroleが1以上をadminとする
});

}
}

// routes/api.php

ルーティング設定

// ...
Route::group(['middleware' => ['auth', 'can:admin']], function () {

// adminのみupdateEmail を許可する

Route::patch('user/update_email/{user}', [UserController::class, 'updateEmail']);
});

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

42

43.

認可制御の正しい実装 • 認可制御の基本は、APIの中で権限を確認すること – 秘密情報の表示 – 権限の必要な機能実行 – その他、権限を必要とする操作 • 権限を確認する基準は、セッション変数やトークンに紐づいたログインID • admin等の特権専用ユーザーは作らず、個人IDに権限を割り当てる仕様が好ましい • 複雑な認可制御が必要な場合は、役割を抽象化したロールを定義する • 時間経過に伴い、権限やロールが変化する場合もあるので、権限やロールはセッション変数に保存せず、データベースを都度確認する • ロールと権限を「権限マトリックス」としてドキュメント化する徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 43

44.

45.

46.

LaravelのEloquent / クエリビルダーは基本的に堅牢 • LaravelのORマッパ(Eloquent)やクエリビルダーは通常何もしなくても SQLインジェクション対策されている – $tasks = Task::where('kind', '=', $kind)->get(); … WHERE kind=? プレースホルダでSQLインジェクション対策される – $tasks = Task::where('kind = 1 or 1=1#', '=', $kind)->get(); Column not found というエラーになる – $tasks = Task::where('kind', '=1 OR true# ', $kind)->get(); kind = '=1 OR true#' と解釈される徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru … WHERE kind='=1 OR true#' 46

47.

48.

[beta]

脆弱性のあるアプリケーション（正常系）
class TaskController extends Controller
{
public function getTaks(Request $request)
{
kind=Shopping
$kind = $request->kind;
$tasks = Task::whereRaw("kind = BINARY '$kind'")->get();
return $tasks;
大文字・小文字
}
を区別して検索
[
}
{

select * from `tasks` where kind = BINARY 'Shopping'

"id":2,
"kind":"Shopping",
"title":"Remember the milk",
"memo":"Get one milk. If the eggs are there, get six."
},

【以下略】

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

48

49.

[beta]

脆弱性のあるアプリケーション（攻撃）
class TaskController extends Controller
{
public function getTaks(Request $request)
kind=' UNION SELECT id, name, email, password, FROM users #
{
$kind = $request->kind;
$tasks = Task::whereRaw("kind = BINARY '$kind'")->get();
return $tasks;
}
select * from `tasks` where kind = BINARY '' UNION SELECT id, name, email, password FROM users #'
}
[

{

パスワードハッシュ値を
"id":2,
含む個人情報が漏洩する
"kind":"takahashi",
"title":"takahashi@example.jp",
"memo":"$2y$10$wMgTH4/IDTpzuUtRDvkYj.kDbfdnXJ6odWnJ5BvfZCKeu0bTJpFhG"
},

【以下略】
徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

49

50.

[beta]

対策 プレイスホルダ
• O/Rマッパーの機能を正しく使うことでSQLインジェクション対策
• whereRaw等を用いる場合は、文字列連結による条件生成をやめて、
プレイスフォルダを用いること
$tasks = Task::whereRaw("kind = BINARY '$kind'")->get();

$tasks = Task::whereRaw("kind = BINARY ?", [$kind])->get();

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

50

51.

52.

SPAに対するXSS攻撃の概要 SESSION ID JavaScript Front End 表示ロジック { … } JSON TOKEN { … } JSON DB localStorage 徳丸浩のウェブセキュリティ講座 API XSSがあると、攻撃者はAPIを自由に悪用でき、秘密情報の盗み取りや不正操作が可能にビジネスロジックなる © 2022 Hiroshi Tokumaru Session Storage 52

53.

Reactの表示はJSXが一般的（再掲） const SomeApp = () => { return ( <div>{ JavaScriptの式 }</div> JSの中でHTMLタグが使える ) } • JSXはプリプロセッサ（Babel）により通常のJavaScriptに変換される • JSX中では { } の中にJavaScriptの式（文字列）を書くと、式の値が展開されて表示される。HTMLエスケープは必要ない徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 53

54.

55.

56.

57.

PHPで改行交じりテキストを表示するのは簡単 • Vanilla PHP（素のPHP）の場合 echo nl2br(htmlspecialchars($text)); まずHTMLエスケープしてから改行を<br>に変換する • Laravel（Blade）の場合 {!! nl2br(e($text)) !!} まずHTMLエスケープしてから改行を<br>に変換する {!! !!} を用いてBladeのエスケープを抑止 • SPAの場合は上記は使えないのでJavaScriptで対応する必要がある徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 57

58.

Vanilla JSでinnerHTMLを使う（危険） <div> <span id="span1></span> </div> <script> const span1 = document.getElementById('span1') span1.innerHTML = text.replace('¥n', '<br>') </script> • innerHTMLを使うと改行→<br>の変換は簡単だが、DOM Base XSS脆弱性が混入する • それでも使ってしまう開発者はいる徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 58

59.

innerHTMLによるXSS <html> <body> <div id="div1"></div> </body> <script> const div1 = document.getElementById('div1') div1.innerHTML = '<img src=1 onerror=alert(1)>' </script> </html> 徳丸浩のウェブセキュリティ講座 Copyright © Hiroshi Tokumaru 59

60.

61.

[beta]

ReactでinnerHTML相当の機能を使う
const App = () => {
return <span dangerouslySetInnerHTML={{__html : nl2br(param)}}></span>
}
const newlineRegex = /(¥n)/g
const nl2br = str => str.replace(newlineRegex, '<br/>')

// 改行を<br>に変換

• Reactの場合、innerHTML相当の機能はdangerouslySetInnerHTMLと
いう見るからに危険そうな名前のディレクティブ
• それでも使ってしまう開発者はいる

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

61

62.

63.

64.

65.

66.

このような声も… https://twitter.com/azu_re/status/1570780991614222337 徳丸浩のウェブセキュリティ講座 66

https://twitter.com/azu_re/status/1570780991614222337

67.

[beta]

JSXを活用して改行表示
const App = () => {
return <span>{ nl2br(param) }</span>
}
const newlineRegex = /(¥r¥n|¥r|¥n)/g
const nl2br = (str) =>
str.split(newlineRegex).map((line, index) =>
line.match(newlineRegex) ?
<br key={index}/> :
line
)

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

文字列 ABC¥nDEF

配列 ABC

配列 "ABC"

¥n

DEF

<br key=0/>

"DEF"

DOM span
ABC
br
DEF

67

68.

69.

[beta]

【参考】AngularでDOM Based XSSに対してサニタイズが入る
app.component.html
<div><span [innerHTML]="text"></span></div>
import { Component } from '@angular/core'
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
})
export class AppComponent {
text = '<img src=/ onerror=alert(1)>';
}

app.component.ts

onerrorイベントが
削除されている

<img src="/">

徳丸浩のウェブセキュリティ講座

Copyright © Hiroshi Tokumaru

69

70.

XSSの緩和策の変遷 • X-XSS-Protection（XSS Auditor） – – – – – IE8にて初めて導入され、その後Google Chrome、Safariに導入される Firefoxは一貫して導入しなかった Google Chrome 78にて無効化（2019年10月） Safari 15.4にて無効化（2022年3月）現在X-XSS-Protectionに対応しているブラウザはない • Content Security Policy(CSP) – X-XSS-Protectionに代わるXSS緩和策としてMozillaにより提唱され、その後標準化された – Google Chrome 25（2013年2月）、Firefox 23（2013年 8月）、Safari 7（2013 年10月）にて正式導入 – 現在および今後のXSS緩和策はこちら徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 70

71.

[beta]

Content Security Policy入門
• 以下は、JavaScriptのソースを自分自身のオリジンと api.example.com に限定する
– Content-Security-Policy: script-src 'self' api.example.com

• 同時にインラインスクリプトも禁止される
– <script> … </script> や <body onload="…"> は禁止される

• インラインスクリプトを書きたい場合は、ナンスまたはハッシュを指定
<script nonce=EDNnf03nceIOfn39fn3e9h3sdfa>
…
</script>
に対して下記のCSPヘッダ
Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

あるいは
<script>alert('Hello, world.');</script>
に対しては下記のCSPヘッダ
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

参考: https://developers.google.com/web/fundamentals/security/csp/?hl=ja

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

71

72.

なぜCSPを勧めるか • MPA（ページ遷移型のウェブアプリケーション）では、CSPの設定がやっかいである – インラインスクリプトが使えないのは面倒 • SPAはCSPと相性がよい – webpack等が生成するコードはHTMLとJavaScriptが分離されており、インラインスクリプトが元々ない – CSPを利用するサイトが増えている • XSS Auditorは蓄積型XSSおよびDOM Based XSSに効果がないが、CSP は防御効果がある • 開発当初からCSPヘッダを有効にして、確認しながら進めるとよい徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 72

73.

SPAのXSSまとめ • SPAのフレームワークはXSS対策がなされている • innerHTML相当の機能やjavascriptスキームによるXSSの可能性 • XSSの検査する時はscriptタグではなくイベントハンドラを使う ○ <img src=/ onerror=alert(1)> × <script>alert(1)</script> • X-XSS-Protection は今は有効ではない • CSPのすすめ • XSSやばい（APIの悪用）ので気をつけよう徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 73

74.

75.

[beta]

まず被害者は正規サイトにログインしている前提
利用者

example.jp

GET /loginform HTTP/1.1
example.jp

<script>
xhr = new XMLHttpRequest()
xhr.open('POST', '/user')
xhr.send(…)
</script>

HTTP/1.1 200 OK
Content-Length: 1056
POST /login HTTP/1.1
{"id":"bob","password":"123456"}

HTTP/1.1 200 OK
Set-Cookie: SESSID=xxxx

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

75

76.

[beta]

脆弱なAPI（メールアドレス変更）の正常系
利用者

example.jp

<script>
xhr = new XMLHttpRequest()
xhr.open('PATCH', '/user')
xhr.send(…)
</script>

example.jp

PATCH /user HTTP/1.1
Cookie: SESSID=xxxx
{"email":"bob@example.jp"}

HTTP/1.1 200 OK
メールアドレス変更

徳丸浩のウェブセキュリティ講座

© 2022 Hiroshi Tokumaru

76

77.

罠サイトからCSRF攻撃する模様利用者攻撃者 evil.example.com example.jp GET /trap HTTP/1.1 evil.example.com <form action= "https://example.jp/user" method="post"> <input "_method"="patch" <input name="email" value="evil@example.com"> <input type="submit"> </form> HTTP/1.1 200 OK Content-Length: 832 POST /user HTTP/1.1 Cookie: SESSID=xxxx _method=PATCH&email=evil@example.com 徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 77

78.

Laravel / Sanctum のCSRFに関するサマリ • CSRF脆弱性が問題になるのはCookieによるセッション管理の場合のみ – Autherizationヘッダにトークンをセットする場合は影響なし • LaravelのCSRF対策はCSRFトークン • SanctumはCookieのSameSite属性を強制的に Lax にセットする • Laravelを普通に使えばCSRFは心配ない – Cookieによるセッション管理を使う場合はCSRF対策を無効化しないこと • 色々理屈をつけて無効化する人がいるがお勧めしない • Laravel以外のフレームワークを使う場合は、フレームワークのCSRF対策機能を調べて使う徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 78

79.

総まとめ • SPAの代表的な脆弱性を紹介 • 脆弱性診断ではSPAの脆弱性が多く見つかっている – 特に、認可制御不備とSQLインジェクション • ブラウザ側（HTMLとJavaScript）のチェック処理は回避できる • フレームワークのセキュリティ機能を正しく活用する • innerHTML相当の機能（dangerouslySetInnerHTML、v-html等）は原則使わない – 使う場合は危険な要素や属性を取り除くサニタイズ処理を行う • 開発者ができるセキュリティテストは多いので試してみよう徳丸浩のウェブセキュリティ講座 © 2022 Hiroshi Tokumaru 79

SPAセキュリティ超入門

徳丸 浩

関連スライド

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

Webアプリケーション開発に潜むリスクのケーススタディ

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

オニギリペイのセキュリティ事故に学ぶ安全なサービスの構築法

各ページのテキスト

徳丸浩