sunabarイベントは、人が集いグラスを交わしながらセッションを行います。飲み物を片手に、司会の矢上によるGMOインターネットグループ流の乾杯（かんぱい）ならぬ、完勝（かんしょう）からスタートしました。

まずは、松本氏から「OWASP API Security Top 10」のご紹介と具体例についてご説明いただきました。

松本氏「OWASP API Security Top 10とは、APIをセキュアに利用するための対策を目的とした、重要なセキュリティリスクを集めたものです。OWASP（Open Worldwide Application Security Project）というオープンソース・ソフトウェアコミュニティが定期的に公表しています。」

オブジェクトレベルの認可不備（BOLA：Broken Object Level Authorization）
ユーザーIDやアイテムコードなど、一意に表すものに対して攻撃を仕掛け、本来であればユーザーが操作できないオブジェクトを閲覧したり、操作・更新ができてしまうものです。この問題はAPIベースのアプリケーションで非常に一般的だそうで、セキュリティを考慮せずにAPIを実装してしまうと脆弱性を埋め込むことになってしまいます。

ユーザー認証の不備
ユーザー認証に不備があると、ユーザーではない第三者からアクセスされ情報を閲覧・更新されてしまいます。ユーザー認証はID・パスワード、アクセストークン、OAuthなど多様化、複雑化しており難しい課題でもあります。設計・運用しているAPIに適切に適用されていないケースが数年来で増えていることに対しての啓蒙の意味もあるそうです。

最近では、APIの実装が容易になりました。フレームワークなどが充実したことで、認証・認可機能もそのまま流用することで簡単に動作してしまうがゆえ、自分たちのサービスに特化した認証・認可の仕組みになっておらず、認証の不備や失敗が増えている印象があるそうです。

村上「OWASP API Security Top 10を見ても、認証・認可に関する脆弱性が半分を占めているので、APIに携わるうえでは、認証・認可に関する知見や経験が肝なのだと感じました。また、セキュリティエンジニアの誤解により認証の問題が蔓延している点は、大変重要な話ですね。」

松本氏「セキュリティエンジニアでも、技術要素が増えてきた昨今、さまざまな問題を網羅的に深掘りできていない現実があります。そういった状況の中で、常に情報のキャッチアップやアップデートを心がけることが大切だと感じています。」

矢上「セキュリティエンジニアに限らず、設計や構築を行う立場のエンジニアも学び続ける必要があると改めて実感しました。」

APIのよくある脆弱性事例集と題して、イエラエ社の脆弱性診断で検出した内容の一部を、事例として紹介してくださいました。

事例1：認可不備（BOLA＆BFLA）
松本氏「APIに限らない事例ですが、オブジェクトレベル、機能レベルの認可不備です。ほかのユーザーの情報を閲覧・更新が可能な状態だった典型的な例となります。先ほどもお話したように、APIの実装が容易になったことで、セキュリティ対策が不十分なまま実装を進めることで発生した事案になります。」

事例2：過剰なデータ露出
松本氏「本来、返さなくてよいようなデータをユーザーに返していた脆弱性です。こちらは、2019年のOWASP API Security Top 10でも指摘されています。例えば、特定のコミュニティで、本来管理者のみが閲覧可能なユーザーのブラックリストが、本人も確認できる状態になったとします。その場合、そのコミュニティ内で問題行動を誘発してしまう可能性が大きくなります。」

矢上「コミュニティを例として紹介いただきましたが、他人事ではないと感じました、当社もデータの露出に対しては常に細心の注意を払っています。我々は金融機関でオープンAPIを提供する立場として、機密性の高い情報も数多く扱っていますので。」

ここで、参加者の方からユーザー認証に関する質問がありました。

質問：ユーザー認証に失敗した場合のエラーメッセージの出し方についてよい例があれば教えてください。

松本氏「素早く確実にエラーの原因を特定するために、詳細なエラーメッセージを表示したくなりますが、あまりにも詳細だと内部構造やフレームワークまで読み取れてしまう脆弱性となる場合もあります。」

詳細すぎるエラーメッセージは、API脆弱性の代表例のひとつだそうです。

松本氏「ユーザーにバグの解決に役立つ情報を返しても、デバックするのは開発者なので、手間は発生しますが、システムにログインしてログから不備を特定する方法にすべきだと考えます。実際に、詳細すぎるエラーメッセージもAPIの脆弱性診断で頻繁に指摘している事項のひとつです。」

矢上「おっしゃるとおりだと思います。エンジニアの立場からみても、手間を省くことよりも、サービスが安全に実装されていることが重要になりますので。」

セキュアなAPIの設計・利用には、認証と認可、そして適切なアクセス制御が必要と名古屋氏は語ります。

名古屋氏「セキュアにAPIを利用するためには、ユーザーが認証されていることと、リソースに対する操作が許可されていることは、別であることを意識することが大切です。」

アカウント連携を伴うAPIの利用は、さらに慎重な対応が求められると言います。

名古屋氏「APIを公開する・公開されているAPIを利用する際には、サービス提供者・API提供者とサーバーサイドが複数に分かれるためさらに注意した設計が必要になります。アカウント連携やAPI利用で利用される技術標準は下記の4つが代表的です。」

1. ①OpenID Connect Core 1.0（以下、OIDC）
2. ②SAML2.0
3. ③OAuth2.0
4. ④Financial-grade API Security Profile 1.0（以下、FAPI）

イベントでは、FAPIについての定義や仕様についても、詳しく解説いただきました。

矢上「金融業界では、2017年の銀行法改正により銀行APIのオープン化に伴いセキュリティ基準もOAuth2.0が標準仕様となりました。一方で、イギリスのオープンバンキングが推奨しているFAPIについて、ご紹介いただけますか？」

名古屋氏「FAPIはOAuth/OIDCを金融分野でも安全に使えるようにするための基準で、2021年4月に正式リリースされました。参照用API を基準に考えられたBaselineと、より強固な認証されたAdvancedという2種類の基準があります。」

矢上「FAPIは現在どの程度浸透しているのでしょうか？」

名古屋氏「FAPIへの対応のご相談は増えています。金融系だと次のAPIでの採用を考えている事業者さまや、海外展開に際して対応を求められるケースも見られます。」

セキュリティの領域では、その時点での最善の対策を講じても、時間をかけて粗を探しセキュリティを突破してくることが常です。定期的な情報の見直しを実施し、学び・改善し続けることがもっとも重要なことだと考えます。

会場では、恒例の懇親会を開催しました。飲食を交えながら、参加者同士の活発な交流が行われました。
※本レポートは2023年9月25日時点の情報です。