Coders Conquer Security OWASP Top 10 APIシリーズ - 認証の不備

認証の不備がOWASPのAPIセキュリティリスクリストに挙げられているのも不思議ではありません。認証メカニズムを正しく実装するのは非常に困難だからです。また、認証の仕組みは本質的にユーザーに公開しなければならないため、攻撃者はそれを観察し、悪用可能なパターンや脆弱性を探す機会を得られるという点で、攻撃者側に多少の優位性があります。

最後に、認証はアプリケーションやネットワーク全体への入り口となることが多いため、攻撃者にとって格好の標的となります。認証プロセスに不備や脆弱性があると、攻撃者にその弱点を見つけられ、悪用される可能性が高まります。

そこで本章では、認証に関する問題を解決し、悪意のある攻撃者を締め出す方法を学びます。まずは自分のスキルを試してみたいという方は、ぜひゲーミフィケーション形式のチャレンジに挑戦してみてください。

スコアを上げたいですか？このまま読み進めて、詳細を確認していきましょう。

認証の不備や設定ミスには、どのような例があるのでしょうか？

一見すると問題が分かりにくい例として、認証メソッドがクレデンシャルスタッフィング（既知のユーザー名とパスワードのリストを使用してセキュリティを突破する手法）に対して脆弱な場合があります。多要素認証のように通常は非常に安全な認証方法であっても、リクエストの制限やスロットリング、その他の監視が行われていなければ、脆弱になる可能性があります。

例えば、攻撃者が /api/system/verification-codes に対してPOSTリクエストを送信し、リクエストボディにユーザー名を含めることで、パスワード復旧リクエストをトリガーできるとします。もしアプリがSMSで6桁のコードを送信する認証方式を採用しており、かつ入力フィールドに制限が設けられていなければ、わずか数分でアプリケーションに侵入される恐れがあります。攻撃者は、正しいコードにたどり着くまで、考えられるすべての6桁の組み合わせを送信するだけでよいからです。

このシナリオでは、表面上は二要素認証があるためアプリケーションは安全に見えます。しかし、ユーザー入力に対してレート制限がかかっていないため、認証は不備があり脆弱な状態と言えます。

別の例として、アプリケーションがエンコードされたユーザーオブジェクトを認証クッキーとして使用している場合を考えます。もし、低い権限しか持たない攻撃者がBase64でそのクッキーをデコードできれば、アプリケーションがどのようにセッションやユーザーを定義しているかを知ることができます。例えば、デコード後に以下のようなJSONが見つかるかもしれません。

{
"username" : "ShadyGuy",
"role" : "user"
{

その時点で、悪意のあるユーザーは自分のユーザー名やロール、あるいはその両方を変更できてしまいます。値をいくつか書き換えるだけで、より高い権限を持つ別のユーザーになりすますことが可能です。

{
"username" : "GoodGuy",
"role" : "admin"
{

この時点で、攻撃者が情報を再エンコードしてクッキーの値として設定すれば、実質的に高い権限を持つ新しいユーザーになりすますことができます。このような変更を防ぐ手段が講じられていない限り、アプリケーションがその改ざんを受け入れてしまう可能性は非常に高いでしょう。

認証の不備や設定ミスの排除

認証が失敗すると、システム全体のセキュリティが侵害される可能性が高まります。しかし、アプリケーションのコーディング時にいくつかの重要なガイドラインに従うことで、全体を安全に保つことができます。

まず、ユーザーがプログラムの機能にアクセスするすべての箇所に、必ず認証チェックを組み込んでください。認証チェックが全く存在しなければ、その時点でセキュリティ対策は失敗したも同然です。

ベストプラクティスとして、ユーザーがアクセス可能なURLにセッションIDを露出させないようにすることが重要です。前述の認証の不備に関する2つ目の例のように、セッションクッキーを攻撃者に決して見せないようにすれば、デコードを試みられるリスクを大幅に減らすことができます。

多要素認証の導入も推奨されます。ハードウェアトークンを使用して、アルゴリズムに基づき短時間でパスワードを生成する方法が安全です。専用デバイスの配布が難しい場合は、SMS認証も有効です。ただし、30秒間に3〜4回までといった試行回数の制限を設け、コードの有効期限を数分以内に設定することが不可欠です。また、英数字を組み合わせたコードを採用することで、セキュリティをさらに強化できます。

最後に、可能であればユーザー名や推測可能な連番をセッションIDとして使用することは避けてください。代わりに、安全なサーバーサイドのセッションマネージャーを利用し、毎回ランダムなセッションIDを生成するようにしましょう。

安全な認証の実装は、一般的な脆弱性対策よりも少し複雑です。しかし、認証はあらゆるアプリケーション、プログラム、APIにおいて極めて重要な要素であるため、時間をかけて確実に構築する価値があります。

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