Coders Conquer Security OWASP Top 10 APIシリーズ - オブジェクトレベルの認可不備（BOLA）

今日のサイバーセキュリティに対する脅威は、いたるところに存在し、容赦ありません。その状況は深刻化しており、プログラムのデプロイ後に対応しようとしても、追いつくことはほぼ不可能です。しかし、DevSecOpsや継続的デリバリーが普及し、かつてないほど多くのデータが扱われる現代において、賢明な組織は開発者がセキュリティ意識の高いスペシャリストへと成長できるよう支援しています。これにより、脆弱性が本番環境に到達する前に排除することが可能になります。これまで私たちはWeb脆弱性に加え、独自のInfrastructure as Code（IaC）におけるトップ8のバグについて取り上げてきました。そして今、ソフトウェアセキュリティにおける次の大きな課題に目を向ける時が来ました。準備はいいですか？

このブログシリーズでは、アプリケーション・プログラミング・インターフェース（API）に関連する最悪のセキュリティバグのいくつかに焦点を当てます。これらは非常に深刻であり、Open Web Application Security Project（OWASP）が公開するAPI脆弱性トップリストにも名を連ねています。現代のコンピューティングインフラにおいてAPIがいかに重要であるかを考えると、これらはアプリケーションやプログラムから何としても排除しなければならない重大な問題です。

コードを用いてセキュリティを強制することが不可欠である理由は、「オブジェクトレベルの認可不備」という脆弱性を検証することで明確に理解できます。これは、どのユーザーがオブジェクトやデータを閲覧できるかをプログラマーが明示的に定義しなかったり、オブジェクトの閲覧、変更、操作、アクセスを行うための検証プロセスを実装しなかったりした場合に発生します。その結果、攻撃者はAPIエンドポイントを通じてオブジェクトやデータを操作・閲覧できるようになります。APIエンドポイントとは、APIと他のシステム間の通信に使用される接点（多くはURL）のことです。アプリ間の接続性は世界中で愛されるソフトウェアの発展に寄与してきましたが、エンドポイントが堅牢でなければ、複数の脆弱性を露呈させるリスクを伴います。

また、コーダーが親クラスからプロパティを継承する際、その過程で重要な検証プロセスが欠落していることに気づかない場合にも発生します。一般的に、ユーザー入力を使用してデータソースにアクセスするすべての関数には、オブジェクトレベルの認可チェックを含める必要があります。

すでにこの問題に精通しており、今すぐアクセス制御のバグを見つけて修正・排除できる自信はありますか？ゲーミフィケーション形式のチャレンジに挑戦してみましょう：

結果はどうでしたか？スコアを上げたい方は、引き続き読み進めてください！

オブジェクトレベルの認可不備の脆弱性には、どのような例があるのでしょうか？

オブジェクトレベルのアクセス制御における脆弱性は、攻撃者が本来許可されるべきではない操作を実行することを可能にします。これには、管理者のみが実行すべきデータの閲覧やレコードの削除といった操作が含まれます。高度にセキュアな環境では、特定の権限を持つユーザー以外にはレコードの閲覧を一切許可しないといった対策が必要になることもあります。
オブジェクトレベルの認可を定義する際は、あらゆる操作の可能性を考慮に入れるべきです。例えば、Java Spring APIにおいて問題が発生しうるエンドポイントは、以下のようなコードになります：

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

このAPIエンドポイントはIDに基づいて注文を削除しますが、その注文が現在ログインしているユーザーによって作成されたものかどうかを検証していません。これにより、攻撃者がこの抜け穴を悪用して他人の注文を削除できるリスクが生じます。

安全なアクセス制限を適切に実装するには、コードは以下のように記述されるべきです：

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

オブジェクトレベルの認可不備の脆弱性を排除する

アクセス制御のコードは、過度に複雑である必要はありません。Java Spring API環境の例であれば、誰がオブジェクトにアクセスできるかを厳密に定義することで修正可能です。

まず、リクエストを行っているのが誰であるかを特定するための検証プロセスを実装する必要があります：

User user = userService.getUserByContext();

次に、オブジェクトIDが存在し、かつリクエストを行ったユーザーに属していることを確認する必要があります。

boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));

最後に、オブジェクトの削除を実行します。

orderRepository.deleteById(id);

コード内の認証方式が、組織のユーザーポリシーやデータアクセス制御と整合していることを必ず確認してください。コードの安全性を完全に確保するためには、権限レベルの異なるユーザーが業務に必要なデータにはアクセスでき、制限されるべきデータにはアクセスや変更ができないよう、検証を行う必要があります。これにより、意図せず見落とされていたオブジェクト制御の脆弱性が明らかになる可能性があります。

これらの例から得られる重要な教訓は、まずユーザーがオブジェクトに対して実行可能なすべてのアクションを定義し、その上で強力なアクセス制御をコードに直接組み込むことです。また、親から継承されたプロパティに依存したり、権限の管理を外部に委ねたりしてはいけません。保護が必要なすべてのオブジェクトタイプに対して、ユーザーの権限とアクションをコード内で明示的に定義してください。

この脆弱性に関する詳細や、その他のセキュリティ上の欠陥から組織や顧客を守る方法については、Secure Code Warriorのブログをご覧ください。また、デモを試して、Secure Code Warriorのトレーニングプラットフォームでサイバーセキュリティスキルを常に最新の状態に保つことも可能です。