OWASP API Security Top 10 (2019) を読んでみた
情報収集が追いついていなくて今日見つけました。とても面白かった。
日本語版はまだGithubにあるようです。
API Securityプロジェクトの紹介スライドがこちら。合わせて読むとなかなか良い。PDFなので情報が下のプレビューに出てきませんが、API Security Projectというタイトルのプレゼンテーションです。
ここから先は読んで思うところを書いて行こうと思います。私が気になるのは、設計やアーキテクチャレベルのミスで脆弱性が起こるパターンです。OWASPの公式見解や対応策、セキュリティベストプラクティスは上記のリンクを直接読んでいただけると良いと思います。
API1 - オブジェクトレベルの認可の不備
攻撃シナリオに記載された2つのケースは、どちらも同じ問題点を持っていて、
- バックエンドAPIではレコード単位のアクセス制限がかかっていない
- APIクライアントから送られてくる情報をキーとしてレコードを取り出している
昔ふうのブラウザ型Webアプリケーションではこの実装で問題なかったんです。WebサーバーとDBが同じファイアウォールの内側にある場合、自分がアクセス権を持たないレコードにアクセスするには、この実装でも他のレコードにアクセス権を持つ他のユーザーのセッションクッキーをとってこないといけなかったのでハードルが高かった。こんな感じ。
で、問題のケースはこの画面のHTMLを生成するWebサーバーの役割をそのままアプリに置き換えると攻撃のシナリオに記載された内容が起こります。こんな感じ。赤いのが悪い人。
APIサーバー側で「ユーザーAはユーザーAのレコードにしかアクセスできない」という設定が足りないので、認証通ってしまえばどのユーザーのデータも取り放題になってしまう。
こっちの方が良いと思います。
API2 - 認証の不備
暗号化強度が弱いので総当たりでクラックできたり、パスワードの強度が弱いので総当たりでクラックできたり。
APIキー認証と呼ばれた時期がありましたが、APIキーは実際のところただのIDなので、現在では認証としては不十分です。
あと意外とやりがちなのが、URLクエリでトークンとかパスワードとかを渡してしまう実装パターン。OAuth 2.0でもこういった情報をURLクエリで渡すことを許容していますが、OAuth 2.1ではNGになるようです。
API3 - データの過剰な公開
Select * ... でDBから取り出したデータをAPIにそのまま渡すなよ、という話。
昔ふうのWebアプリケーションではこんな実装でも問題なかった。メモリ効率が悪いだけで、WebサーバーがHTMLを生成するときに不要なフィールドを入れなければファイアウォールの外側にデータが流れなかったので問題なかったんです。逆に画面に表示する要素を入れ替えるときにDBからのデータ取得の部分を書き換えなくてよかったんで、楽だったんですよね。
これをAPIとアプリにすると途端に問題が出ます。
あとは悪い人が認証をくぐり抜ければ情報が全て取得できます。
万が一パスワードのフィールドがユーザーテーブルに含まれていたら、暗号化しているとはいえ取得できてしまいます。T-Mobileの2018年情報流出事件はこういう実装だったはずです。
API4 - リソース不足と帯域制限
リソース不足を招くような大きなサイズのメッセージの受け入れや、短時間に何度アクセスしても受け入れてしまうような実装はやめましょうね、という話。
API5 - 機能レベルの認可の不備
例として上がっているのは例えば、
- /users をユーザーに公開したが、HTTPメソッドでのフィルタリングを忘れていた。DELETEやPOSTはAdminだけだったはずなのに全ユーザーに使えるようになってしまっていた。
- /users をユーザー向けに公開し、/users/all をAdmin向けに公開したかったが、/users/all のアクセス権はユーザー向けについてしまっていた。
API Gatewayをやっていたときに、この点はURIベースでコントロールしようとするとやっちゃいそうだな、と思った記憶があります。
API Gateway便利なんですけど、ユースケースベースで実施しなければならないような内容までAPI Gatewayに持たせると、
- Gateway担当チームにアプリもセキュリティもわかる超優秀な人が必要
- どんなアップデートがあった時もGatewayに手を入れなければならなくなるので、結局SOAPのESB問題が再発する
ので、やめた方が良いです。
API6 - 一括割り当て (Mass Assignment)
例で書かれているのは2パターン。
1. ユーザー側に書き込みを許可してはいけないフィールドの書き込みを制限していなかったパターン。管理者により入力されるフィールドや、ビジネスロジックが入力するフィールドなどであっても、APIからの更新を許可してしまっていた。
2. APIで受け付けたインプットをそのままシェルスクリプトに渡して実行させてしまっていた。
API7 - セキュリティ設定ミス
餅は餅屋に。
API Gatewayの後ろで管理用に使っているヘッダーをそのままクライアントにパスしてしまうパターンのフィルタリングミスはやりがちなので気をつける。
API8 - インジェクション
インプットとアウトプットは精査してから処理しましょうねという話。
API9 - 不適切な資産管理
設計やアーキテクチャじゃないんですけど、これは多分いっぱいある。
作ったまま放置してしまい、存在を忘れてしまったエンドポイントやバージョン、ベータ用の環境などで、セキュリティ管理が適切にされていなくて攻撃対象になるパターン。
数年前にサービスマネジメントのセミナーだったかと思いますが、サーバーの棚卸しをずっとしていなかった会社が、サーバー台帳を使って棚卸しをしてみたら台帳にないサーバーがたくさん出てきて、もう使っていないサーバーを廃棄したらサーバー数が1/3になったという話を聞いたことがあります。
同じことはソフトウェアでも起こりますし、サーバー棚卸しはやっててもサービス棚卸しがあるところはあまりみたことがない。サービス台帳がないところもある。
API10 - 不十分なロギングとモニタリング
これも設計やアーキテクチャじゃないんですけど、これもいっぱいあるはず。
セキュリティは悪さをさせないことと、悪さをされた場合にすぐに修正することのセットが必要。
クレジットカードが、支払いの受付に認証をしたりしますが、不正なトランザクションを見つけてカードを停止するような活動もしている、このモデルがAPIにも必要です。
で、設計や実装の上でセキュリティ対策はしっかりするものの、悪さをされたことを検知できていないパターンや、検知できても対応し切れていないパターンが非常に多い。とセキュリティの専門家にお伺いしています。
OWASPのページには検知することと、検知した時に何が起こっているかが把握できる程度のログの取得などが対策として書いてありますが、そのほかに調査に十分な要員がいないとかで、検知したけど放置されるケースなどがよくあります。
ですので何を言いたいかというと、検知の後工程、検知数に対して処理完了数を把握するの大事です。
感想
OWASPすごい。面白い。よくまとめてます。
各説明からリンクされた参考資料もチラ見しましたがなかなか面白いです。
とはいえ脆弱性の内容そのものは5年くらい前から言われている内容と実はあまり変わっていない。
OWASPのTop 10でこの辺が周知されると良いなと思います。
この記事が気に入ったらサポートをしてみませんか？