「Basic認証は危険と聞いたことがあるけど実際のところはどうなのだろうか…」
「Basic認証以外にどのような認証方式を使えば良いのか？」
Basic認証とは、Webアプリケーションにおいて利用される認証方式の一つです。実装コストが低いため、すでに利用したことがある方もいらっしゃるかもしれません。しかしながら、この認証方式にはセキュリティ上の問題が指摘されており、企業の信頼が失われるだけでなく、なりすましや情報漏洩が発生する恐れもあります。
特に近年は、生成AIを活用したWebアプリケーションの増加により、認証まわりのセキュリティリスクがさらに複雑化しています。AIとの連携機能を持つシステムでは、認証の甘さが意図しない情報流出やアクセス制御の不備につながる可能性もあるため、より強固な対策が必要です。
そこで本記事では、以下の内容について解説します。
- Basic認証の仕組みや問題点
- Basic認証の問題点を悪用された場合の被害
- Basic認証の代わりに使うべき認証方式
Basic認証の問題点から、代わりに利用するべきセキュアな認証方式まで解説しています。
ぜひ本記事を参考に自社のセキュリティ対策について検討してみてください。
Basic認証とは
Basic認証とは、HTTPに元々用意されている認証機能の一つです。簡易的な認証方式で、Webアプリケーションの特定のページやファイルに対して手軽にアクセス制限をかけることができます。
Basic認証によりアクセスが許可されるまでの流れは、以下になります。
- Basic認証でアクセス制限がかけられたページに、ユーザーがアクセスを試みる。
- アクセス制限がかけられているため、Webサーバーはブラウザに対して認証が必要であることを知らせる。
- 画面にダイアログが表示され、認証情報（IDとパスワード）の入力が求められる。
- 認証情報が正しいと認められれば、ページへのアクセスが可能となる。認証情報はブラウザに保存され、それ以後のアクセスでは認証情報が自動で送信される。
また、Basic認証には以下のような特徴があります。
- 認証情報（IDとパスワード）はBase64でエンコードされてブラウザに保存される
- アクセスするたびに認証情報が送信される
Base64エンコードは単純な変換であり、パスワードが容易に復号されてしまう可能性があります。このような特徴から、Basic認証は一般的にはあまり利用を推奨されていません。
Basic認証の問題点については各所で指摘されており、近年廃止の動きが活発化しています。Microsoftは、2023年3月31日をもって Microsoft Exchange Online での「Basic認証の無効化」を開始しました。Basic認証を利用した接続が利用できなくなるため、メールサービスを提供している場合は認証方式を切り替える必要があります。「Microsoft Exchange Online」と連携している他のサービスにも影響が及ぶ可能性があるため、確認しておきましょう。
詳しくはこちら：Learn Microsoft.com「Exchange Online での基本認証の廃止」
Basic認証の問題点を利用した攻撃を受けると何が起こるのか？
Basic認証の問題点を利用した攻撃を受けると、何が起こるのでしょうか。
Basic認証は、認証方式としてセキュリティ上の問題が指摘されており、脆弱性のような扱いをされています。そのため、企業が取り扱う重要な情報を保持するWebアプリケーションにおいては、Basic認証の利用は避けるべきでしょう。Basic認証の問題点を悪用されると、なりすまし被害や、情報漏えいなどが起こりうる可能性があります。
Basic認証の問題点
Basic認証には、以下の問題点があります。
- IDとパスワードを毎回送信するため、盗聴により容易にIDとパスワードが盗まれてしまう
- ログアウト機能がなく、再度認証する必要がないため、なりすましのリスクが高い
それぞれの問題点について、以下で詳しく解説していきます。
ブラウザにID・パスワードが残るため、盗聴のリスクが高まる
Basic認証は、認証情報をブラウザに保存します。保存される認証情報はIDとパスワードそのものであり、Base64という変換方式を用いてエンコードされていますが、デコードすれば元の文字列は簡単に確認できます。アクセス制限のかかったページやファイルにアクセスするたびにブラウザから認証情報が送信されているため、そのうち一度でも盗聴されてしまえば、認証情報が漏洩してしまいます。
また、Basic認証は認証情報を平文で送信しています。平文の認証情報を毎回送信しているため、盗聴のリスクが高いのがBasic認証の問題点です。
平文での送信というリスクに対処するには、HTTPではなくHTTPSでの通信を強制する必要があります。しかし、たとえHTTPSによる通信を強制したとしても、毎回認証情報を送信している、という問題点は解消されません。後ほど紹介するForm認証のように、セッションIDのような「仮の鍵」を発行する仕組みであれば、万が一、漏洩したとしても破棄すれば済みます。
ログアウト機能がないことによるなりすまし被害などのリスクがある
Basic認証のもう一つの問題点が、ログアウト機能がないという点です。
Basic認証は、認証情報をブラウザに保存し、アクセスするたびにWebサーバーにその情報を送信するという仕組みです。そのため、Basic認証にはログアウト機能がそもそも存在せず、ブラウザに保存された認証情報を削除するには、履歴の消去やブラウザを閉じる、といった操作が必要になります。
ログアウト機能が存在しないことによる典型的なリスクは、なりすましです。ログアウト機能が実装されていないWebアプリでは、離席中や共用PCなどを利用している場合に、勝手にアクセスされてしまう可能性があります。もちろんこうしたリスクに対しては、離席する際にPCにロックをかけたり、共用のPCの利用を避けたり、といった対策を実施すれば問題ないでしょう。
また、ログアウト機能がある認証方式を実装している場合、クロスサイトスクリプティング（XSS）攻撃やクロスサイト・リクエスト・フォージェリ（CSRF）攻撃の被害を緩和することができます。ログアウトしている状態であれば、XSSによるセッションハイジャックや、CSRFによる重要な処理の実行といった被害を避けることができます。
ECサイトを狙うWebアプリケーションの脆弱性
Webアプリケーションは攻撃の標的になりやすい傾向があり、攻撃者はセキュリティ対策が甘いWebサイトを常に狙っています。
クレジットカード決済処理を行うECサイトなどでなりすましへの対策ができてない場合、攻撃を受けてカード情報が漏えいする被害が想定されます。
決済代行業者を利用したカード情報非保持のECサイトの場合も、決済など重要な処理を実行する際に、ユーザー本人による操作か確認できていないと、Webアプリケーションの脆弱性CSRF（クロスサイト・リクエスト・フォージェリ）による攻撃を受け、カード情報をとられてしまうリスクがあります。
CSRFの脆弱性への攻撃手法を知り、ECサイトを守る方法を知りたい方は、是非「CSRF対策｜しくみと最新の防御方法を解説」をご覧ください。
Basic認証に代わる認証方式
Basic認証は実装が容易なため、特定の人間しかアクセスできないWebアプリケーションなど、限られた場面での利用については認められる場合もあります。
しかし、セキュリティ上の問題点が指摘されているため、多くのユーザーが利用するWebアプリケーションでは、Basic認証の利用は避けた方が良いでしょう。
それでは、代わりにどのような認証方式を利用すれば良いのでしょうか。本章では、Basic認証に代わる認証方式を2つご紹介します。
Digest認証
Digest認証も、Basic認証と同じくHTTPで提供されている認証方式です。
平文でIDとパスワードを送信しているBasic認証とは異なり、Digest認証は認証情報にランダム文字列の付与と暗号化を行ってはいますが、HTTPでしか利用できません。Basic認証を利用しながらSSLで暗号化する認証に比べると弱いため、基本的には利用を避けた方が良いでしょう。
加えて、Digest認証は中間者攻撃に弱いという問題点が指摘されており、Digest認証のRFCにもそのことが記載されています。
中間者攻撃とは？
ユーザーとWebアプリケーションの間に割り込み、通信を盗聴したり書き換えたりする攻撃のこと
Form認証
Form認証は、HTTPの仕様にはない認証方式で、Webアプリケーション側で実装する必要があります。
ユーザーは、Webサイトやアプリケーションのログイン画面でIDとパスワードを入力します。Webサーバーがその情報を検証して認証が成功すれば、アクセスを許可し、セッションIDを発行します。セッションIDはブラウザにCookieとして保存され、以後のリクエストには自動的に付与されます。Webサーバーは、リクエストのCookieに含まれるセッションIDを確認して、ユーザーのログイン状態を判定します。
Form認証も最初の認証情報は平文で送信されるため、HTTPSでの通信が必須となります。ただし、IDとパスワードを毎回送信するのではなく、セッションIDを用いて認証を行うため、Basic認証よりもセキュリティ的に優れています。
Basic認証を含む包括的なWebサイトのセキュリティ対策
Basic認証の脆弱性は、単独で対処すれば十分というものではありません。Webサイト全体のセキュリティの一部として捉え、包括的な対策を講じることが不可欠です。
例えば、認証方式を変更しても、内部不正や人的ミスによる情報漏洩リスクは依然として残ります。そのため、従業員へのセキュリティ教育やログ監視、適切な権限管理など、技術面と組織面の両方から対策を行うことが重要です。
さらに近年では、開発の効率化を目的に生成AIの導入が進んでおり、Webサイト運用の現場にも浸透しつつあります。一方で、生成AIに機密情報を誤って入力してしまうリスクや、不正確な出力をもとに判断ミスが起きるリスクも指摘されています。
こうした背景を踏まえると、今後は従来の脅威だけでなく、新たな技術の活用に伴うリスクにも目を向け、Webサイト全体のセキュリティを多角的に見直す姿勢がますます重要になるでしょう。
Webサイトの包括的なセキュリティ対策については、「Webサイトのセキュリティ｜安全運用に必要な対策を解説」で詳しく解説しているので、ぜひご覧ください。
Webサイトを攻撃から守るには脆弱性診断が有効
最近では、サイバー攻撃の手法が複雑化し、多様化しています。そのため、どの企業においてもセキュリティ対策の強化が不可欠です。
サイバー攻撃によって企業の機密情報や個人情報が漏えいすれば、企業のイメージや信頼が損なわれ、大きな損害を被ることになります。サイバー攻撃の手口は日々進化しており、非常に巧妙化しています。そのため、脆弱性診断の実施は極めて重要です。
脆弱性診断について詳しく知りたい方は、「脆弱性診断（セキュリティ診断）とは｜必要性からやり方まで、すべて解説」をご一読いただくことをおすすめします。
まとめ｜Basic認証の実装は慎重に検討を
本記事では、Basic認証の仕組みと問題点について解説してきました。Basic認証はForm認証に比べると実装が容易というメリットがありますが、一方で、簡易的な認証方式のためセキュリティ上の問題点が指摘されています。
そのため、以下のような特定の状況下の場合に限り、Basic認証の利用が許容されることがあります。
- 個人のWebサイトの管理
- 開発中のWebサイトのテスト環境
- 社内の特定ユーザーのみと共有するコンテンツ
個人情報や機密情報を含まない限定的なユーザーグループに公開される情報の場合、あるいはアクセス制限を設けたい場合には、Basic認証の利用は問題はありません。
しかし、2023年3月31日をもって Microsoft Exchange OnlineでのBasic認証の無効化を開始したように、多くのユーザーが利用することを想定したWebアプリケーションでは、Basic認証のセキュリティ上の問題点が指摘されているため、使用を避けることを推奨します。代わりにForm認証を採用し、セッション管理を行うようにしましょう。
また、近年では生成AIを活用したWebアプリケーションの普及により、認証の脆弱性がAI経由で悪用されるリスクも高まりつつあります。生成AIが扱う学習データや出力内容が機密情報と連携する場合、認証の甘さが情報漏洩や誤動作の原因になりかねません。
こうした多層的なリスクに備えるためにも、認証方式の見直しに加えて、定期的な脆弱性診断の実施が有効です。AeyeScanなら、従来のWebアプリケーションだけでなく、AIを搭載したシステムにも対応した高精度な自動診断が可能です。
AI時代のセキュリティ対策を万全にしたい方は、ぜひAeyeScanの資料をご確認ください。
