Coders Conquer Security OWASP Top 10 API Series - Broken Authentication
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が 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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
マティアス・マドゥ博士
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
セキュアコーディングに関する最新の知見をブログでご紹介しています。
当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。
開発者主導のセキュリティに関する最新の研究成果を入手する
ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。
Coders Conquer Security OWASP Top 10 API Series - Broken Authentication
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が 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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
