KEEP LEARNING

アウトプット至上主義

HSTSの必要性

f:id:food_blog:20200614231805p:plain

本記事ではセキスペ 過去問(H.31/秋 午後I 問2)を例題として解説する中で認証方式の理解を深めます。

※IPA公式サイトから実際の問題を使用しております。 

 

1.前提知識

  • HSTS(Hypertext Strict Transport Security)

 

2.知識のインプット

 

HSTS

Hypertext Strict Transport Security(HSTS)は、WebブラウザにTLSの使用を強制するポリシーメカニズムです。 WebブラウザがHSTS指定されているWebサイトにアクセスすると、Webサーバーは次回からhttpsアクセスするようにWebブラウザに通知します。 こうして、HSTSはすべての通信がクライアント側のセキュアなトランスポート層を介して行われることを保証することにより、TLSのより効果的な実装を可能にします。 HSTSは、特に中間者(MiTM)攻撃防止に有効とされています。

 

単純なHTTPからHTTPSへのリダイレクトとの違い 

HSTSは主にリクエスト内のデータを傍受する中間者攻撃を防止できるメリットがあります。

中間者攻撃によってリクエストが傍受されてもTLSにより通信が暗号化されているため、通信内容は理解できません。


しかし、攻撃者は標的型攻撃メールやリンク偽装などで、暗号化されていないHTTPによるアクセスに導き、暗号化しない状態で通信させることで、Cookieの値や、フォーム送信した情報を傍受しようとします。

 

HSTSの場合はHTTPでの通信はそもそも行われないので、上記のリスクを軽減できます。

 

3.背景

近年、クラウドサービスに対するパスワード認証が破られてる不正アクセスが度々発生している。クラウドサービスが乱立する中利用者のパスワード管理も煩雑となり、よりセキュアな認証方式が必要になってきている。そうした背景もあり、パスワードレスの認証方式の標準化が進められている。

認証方式の安全性を評価する能力を問う。 

 

4.過去問の要約

 電子メールの送受信にはオンプレミス環境を導入しているが、海外拠点ではクラウド型のメールサービスPを利用している。

送信者が海外拠点の従業員から不審なメールアドレスをから受け取った。

この不審なメールアドレスを調査すべく、以下の調査を実施した。

f:id:food_blog:20200614215535p:plain

不正アクセスの確信を受け以下のように認証方式の強化を実施した。

また、認証強化においての要件は以下の二つである。

f:id:food_blog:20200614220242p:plain

メールサービスPは単体ではパスワード認証にしか対応していないが、認証連携の機能がることがわかった。認証連携機能を利用すれば、メールサービスPにアクセスしようとした時に、他のID管理サービスにリダイレクトされ、そこで認証が行われ、認証に成功すると、メールサービスPにアクセスできるようになる。そこでX社が提供するクラウドサービス型ID管理サービス(IDaas-X)を利用することとした。IDaaS-Xでは認証サーバXを使って利用者を認証する。

IDaaS-Xが対応している認証法式には次の2種類がある。

f:id:food_blog:20200614220929p:plain

上記の認証方式で要件1、2を満たせるか検討する。登録処理を図3、OTP認証方式の認証処理を図4に示す。

f:id:food_blog:20200614221319p:plain

OTP認証方式を利用した場合、ログイン時刻によって変化するOTPも必要になるので、パスワードが搾取された場合でも不正ログインを防ぐことが可能になる。しかし、OTP認証方式を利用し、かつ、登録処理を正しく行ったとしても、要求2を満たすことができない恐れがある。

 

次にパスワードレス認証方式の検討する。オーセンティケータ登録処理を図5,

認証処理を図 6に示す。

f:id:food_blog:20200614222250p:plain

パスワードレス認証方式を利用すれば、要求2を満たすことができる。

 

5.解説

 

OTP認証方式を利用し、かつ、登録処理を正しく行ったとしても、要求2を満たすことができない恐れがある。 

 この場合はwebブラウザ(ユーザ)とサーバXの中間に攻撃者が要したサーバを中継させることでフィッシングの被害に会う可能性がある。

具体的には攻撃者が、ホテルで公開されているWifiと同じSSIDと事前共有鍵を用意して置くことでユーザに攻撃者が悪意のあるサーバに誘導するこどができてしまいます。

 

図2中のa,bには以下が回答となります。

a:メールサービスP

b:攻撃者が用意したwebサーバ

 

このようにアクセスポイントを偽造する(騙す)ことで偽のサイトへ誘導され認証情報等が攻撃者に搾取されてしまいます。

 

また、図2の下線について、サーバ証明書が信頼できない旨のエラーが表示されなかった理由としては以下が考えられます。

単純にHTTPで接続がされてしまっていたため。

HTTPでの接続を完全に回避するためにはHSTSの実装が必要となります。

 

OTP認証方式を利用し、かつ、登録処理を正しく行ったとしても、要求2を満たすことができない恐れがある。

 

 こちらもWebブラウザとサーバXの間に攻撃者による偽の中継サーバを経由させられた場合は、認証サーバへの認証要求、そしてその戻り値の取得、OTPの要求、さらにはメールサービスへの認証要求が突破されてしまいます。

 

図5,6のc,d,e,fにはそれぞれ以下が入ります。

c:秘密鍵A d:公開鍵A

e:秘密鍵K f:公開鍵K

 

自身の署名には秘密鍵、その検証には公開鍵を利用します。

 

パスワードレス認証方式を利用すれば、要求2を満たすことができる。

パスワードレス認証の場合は認証サーバ側でwebブラウザがアクセスしたサイトのオリジンと認証サーバのwebサイトオリジンの一致の確認をするので、ブラウザと認証サーバの間に想定していない攻撃者のサーバを中継した場合、オリジンが一致しなくなるため、認証に失敗し、フォッシング等のリスクを回避することができます。