“それなりに”安全な Webアプリケーションの作り方 石川琉聖 (xryuseix) 　@ryusei_ishika GMO Flatt Security Inc. 

石川琉聖 (xryuseix) 　@ryusei_ishika GMO Flatt Security株式会社 所属。 専門はWebセキュリティ、 Webアプリケーションの開発、 OSINTなど。 趣味は麻雀🀄、開発💻、CTF🚩。 お仕事でやっていたこと プログラミング学習サービスのコンテンツ制作 (アルバイト) フロントエンド・バックエンドエンジニア (アルバイト) セキュリティエンジニア @ GMO Flatt Security Webアプリ脆弱性診断、クラウドペンテストなどをしています 2020-2023 2021-2025 2025- 自己紹介 

怖い人「セキュリティ？知らねぇよ。 まずは納期までに動くもの作る方が優先でしょ」 とても怖い偉い人 僕「た、たしかに......?」 3 Webアプリケーションの開発でこんなことありませんか？ 

じゃあ...... 4 今回は実装コストがかからないやつを 4つ紹介します 「なんかコスパよく 、Webアプリが”それなりに ” 安全になる開発テクニックってないっすか？」 

今日はこんなAPIを題材に喋っていきます 5 

1. 認証認可系は共通モジュール化する 6 ● JWTの検証 ● JWTに書かれていたユーザが、 /money/transfer APIを使用する権限を 持っているか ● そもそもsenderIdって必要？ ● 「このAPIだけ認証認可を実装し忘れてた！」を防ぎたい ● 「Controllerでこの関数さえ呼べばOK！」など、 何も考えなくてもいい感じに認証認可される を目指す 題材のAPIで考えるべきこと 

2. 型がある言語を採用・入力値の検証をする 7 ● senderId, receiverIdは文字型 ○ /[a-z_]+/のみ許可する ● amountは正の整数 ● ユーザ入力のvalidationがあるだけで、 体感8割くらい攻撃者のできることが減ります (出典なし) ● validationをする最も楽な方法が、型のある言語の導入 ○ ダメだったら勝手にエラーになるから ● これに加えて、型のとり得る値のスコープを狭める ○ 正の整数, URL format, uuid format など 題材のAPIで考えるべきこと 

3. ユーザによって汚染可能な変数を意識する 8 ● senderId, receiverId, amountは ユーザが任意の値に書き換えてくる ● 検証後のJWTの値は信用していい ● 攻撃者がどの変数の値を汚染 (変更)できるのか を意識する ○ 汚染された値を加工した値も汚染されている ○ 汚染された値は特に重点的に検証する 題材のAPIで考えること baseSQL = "SELECT * FROM users" senderSQL = baseSQL + "WHERE sender_id = " + senderId sender = db.query(senderSQL) ←ユーザ入力 

4. 眠い時に大事な実装をしない 9 ● ちゃんと寝る 。 ● 実装者やLLMが「ヨシ！w」と言ってるからと言って、 レビュアも雑に「ヨシ！w」と言わない。ちゃんと見る 。 

終わり 10 ● 認証認可系は共通モジュール化する ● 型がある言語を採用・入力値の検証をする ● ユーザによって汚染可能な変数を意識する ● ちゃんと寝る ご紹介した楽にできそうなこと一覧 :