こんにちは。なおとです。
冬で外が寒いのなんのなんの。
一歩も外出せず家のセキュリティ対策はバッチリ。
最近APIのセキュリティについての学習を始めました。
とっかかりとして、OWASPのAPI Security Risks Top 10を1つずつ読んでとても簡単に説明し、感想の端くれを述べていくことにしました。
OWASPとは、セキュリティに関する情報共有及び普及啓発を目的としたオープンソース・ソフトウェアコミュニティです。
API Security Risks Top 10とはOWASPが発表している、Web APIにおける10大セキュリティ懸念事項みたいです。
今回はTop 10の1つ目「Broken Object Level Authorization(BOLA)」を見ていきます。
BOLAとは
BOLAのうち、OLA(Object Level Authorization)の部分は言葉の通り、
「ユーザーがアクセス権限を持つオブジェクトにのみアクセスできること」
を指します。
つまり、BOLA(Broken OLA)は
「ユーザーがアクセス権限を持たないオブジェクトにアクセスできてしまうこと」
を指します。
具体例
とあるサービスでは、/users/:id/updateにPUTメソッドでHTTPリクエストを送信することで、ユーザーのプロフィール更新が行えるとします。(パスは仮置きです。)
例えばidが10のユーザーが自身のプロフィールを更新する場合、/users/10/updateにリクエストを送信します。
ここで、ユーザーは自身のプロフィールのみを更新することができるとします。
BOLAの対策が行われている場合は、idが10のユーザーでログインしている時、パスの:idの部分が10の時のみ更新処理が正常に行われます。
BOLAが発生している場合、idが10のユーザーでログインしている時、パスの:idの部分を100に変更してリクエストを送っても更新処理され、idが100のユーザーのプロフィールが更新されてしまう等の現象が発生します。
対策
OWASP公式では以下のような対策が挙げられています。
- BOLAが発生していないか、脆弱性を評価するテストを書くこと。
- ユーザーの各オブジェクトへのアクセス権限を適切に実装すること。
- DBにアクセスするために、ユーザーからの入力を使用する全ての関数でアクセス権限をチェックする。
- レコードのIDには、ランダムで予測不可能な値をGUIDとして使用することを推奨する。
以上で簡単なBOLAについての説明とさせていただきます。
技術的な感想
まず、BOLAに関しては結構初歩のセキュリティリスクだと思いました。
丁寧に実装し、テストを書いて、正しく対策をとらなければと再度考えました。
もう少しだけ以下の2つについて感想を述べます。
ユーザーのプロフィール更新に関して
更新用のパスにidを含めても、処理内ではセッション管理しているユーザー、JWTによって認証できたユーザー等を使用するべきだと思います。
ユーザープロフィールの場合は更新用のパスにidを含めない方が良いのかもしれないですね。
レコードのIDにGUIDを用いる対策に関して
これは自分はできていないですね。
というよりRuby on Railsを使うことが多いのですが、デフォルトでIDは1からの連番でbigint型なんです。
PrimaryKeyにランダム文字列を用いると、何かのgemが動かなくなったなんて話も小耳に挟んだり挟まなかったりしますし。
ただ、アプリケーションのコードで、オブジェクトへのアクセス権限が正しく設定されていれば、ここまでやらなくても良いのかなとも感じました。
最後に
セキュリティよく知らないしなんだか怖い、、、と思っていたのですが、OWASP公式の文章がとても読みやすくてハードルが少し下がりました。
この記事の説明は本当に簡単に行っています。
しっかり学びたい方は是非公式の文章を読んでみてください。
とっても綺麗な文章で読みやすいと思います。
最後まで読んでいただき、ありがとうございました。