“それなりに”安全なWebアプリケーションの作り方

TechBull LT&交流会！#3 で使用したLTスライドです。
https://techbull.connpass.com/event/368936/

Transcript

1. “それなりに”安全な Webアプリケーションの作り方 石川琉聖 (xryuseix) 　@ryusei_ishika GMO Flatt Security Inc.
2. 石川琉聖 (xryuseix) 　@ryusei_ishika GMO Flatt Security株式会社 所属。 専門はWebセキュリティ、 Webアプリケーションの開発、 OSINTなど。 趣味は麻雀🀄、開発💻、CTF🚩。 お仕事でやっていたこと プログラミング学習サービスのコンテンツ制作 (アルバイト) フロントエンド・バックエンドエンジニア (アルバイト) セキュリティエンジニア @ GMO Flatt Security Webアプリ脆弱性診断、クラウドペンテストなどをしています 2020-2023 2021-2025 2025- 自己紹介
3. 怖い人「セキュリティ？知らねぇよ。 まずは納期までに動くもの作る方が優先でしょ」 とても怖い偉い人 僕「た、たしかに......?」 3 Webアプリケーションの開発でこんなことありませんか？
4. じゃあ...... 4 今回は実装コストがかからないやつを 4つ紹介します 「なんかコスパよく 、Webアプリが”それなりに ” 安全になる開発テクニックってないっすか？」
5. 今日はこんなAPIを題材に喋っていきます 5
6. 1. 認証認可系は共通モジュール化する 6 • JWTの検証 • JWTに書かれていたユーザが、 /money/transfer APIを使用する権限を 持っているか • そもそもsenderIdって必要？ • 「このAPIだけ認証認可を実装し忘れてた！」を防ぎたい • 「Controllerでこの関数さえ呼べばOK！」など、 何も考えなくてもいい感じに認証認可される を目指す 題材のAPIで考えるべきこと
7. 2. 型がある言語を採用・入力値の検証をする 7 • senderId, receiverIdは文字型 ◦ /[a-z_]+/のみ許可する • amountは正の整数 • ユーザ入力のvalidationがあるだけで、 体感8割くらい攻撃者のできることが減ります (出典なし) • validationをする最も楽な方法が、型のある言語の導入 ◦ ダメだったら勝手にエラーになるから • これに加えて、型のとり得る値のスコープを狭める ◦ 正の整数, URL format, uuid format など 題材のAPIで考えるべきこと
8. 3. ユーザによって汚染可能な変数を意識する 8 • senderId, receiverId, amountは ユーザが任意の値に書き換えてくる • 検証後のJWTの値は信用していい • 攻撃者がどの変数の値を汚染 (変更)できるのか を意識する ◦ 汚染された値を加工した値も汚染されている ◦ 汚染された値は特に重点的に検証する 題材のAPIで考えること baseSQL = "SELECT * FROM users" senderSQL = baseSQL + "WHERE sender_id = " + senderId sender = db.query(senderSQL) ←ユーザ入力
9. 4. 眠い時に大事な実装をしない 9 • ちゃんと寝る 。 • 実装者やLLMが「ヨシ！w」と言ってるからと言って、 レビュアも雑に「ヨシ！w」と言わない。ちゃんと見る 。
10. 終わり 10 • 認証認可系は共通モジュール化する • 型がある言語を採用・入力値の検証をする • ユーザによって汚染可能な変数を意識する • ちゃんと寝る ご紹介した楽にできそうなこと一覧 :