アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点

Slide 1

Slide 1 text

Slide 50

Slide 50 text

© 2025 GMO Flatt Security Inc. All Rights Reserved. 観点3: 権限の昇格が可能 Authorization Control 「管理者ユーザーかどうかの認可制御」が正しく行われていても、「一般ユーザーが管理者ユーザーとして振る舞える」ような状態になるのであれば意味がありません。このような「権限の昇格」が行われる原因のパターンを紹介します。脆弱性を生む実装のパターン一般ユーザーの権限情報を変更可能例えば、自分のユーザー情報を更新しようとして送信されたリクエストにrole_idという権限情報が含まれている場合、管理者権限のユーザーのrole_idを指定できれば権限昇格ができてしまうような状況ですこれは、データ更新の権限の管理を「このユーザーの所有するデータかどうか」だけで行っている場合起こり得ます。一般ユーザーが管理者ユーザーを作成可能一般ユーザー自身が管理者ユーザーの権限を得られなくとも、一般ユーザーが管理者ユーザーを作成できて認証が可能であればそれは立派な権限昇格です「観点1: 権限を持たない機能の操作が可能」のような実装がユーザー登録機能等の新規のユーザーを作成する部分に行われていれば起こりえます。一般ユーザーが管理者ユーザーの認証情報を変更可能例えば「管理者ユーザーのパスワードを自分が知っているパスワードに変更してしまう」というような、既存の管理者ユーザーの認証情報を自分が知っているものに書き換えられる状態です前述の「観点1: 権限を持たない機能の操作が可能」のような実装が前項同様に行われていれば起こり得ます。

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text