2018年3月5日月曜日

[告知]ISACA大阪支部月例会でID管理チェックリストについてお話しします

こんにちは、富士榮です。

1月にJASAの定例研究会でID管理チェックリストについてお話しさせていただいたのですが、ほぼ同じ内容で今度はISACA大阪支部の月例会でお話しさせていただきます。

ちなみにJASAのイベントの様子はこちらです。
 JASAのイベント開催レポート
 http://www.jasa.jp/seminar/monthlyreport.html


詳細、申込はこちらからどうぞ。
 http://www.isaca-osaka.org/global_EventsDetail.php?eventsId=33

3月19日(月)が申込期限です。関西の方、ぜひお申込みください。(関西でこの手のイベントをやるのは結構レアですし)

前回より持ち時間が長いので、ネタを考えないと・・・

2018年3月3日土曜日

[LINE Login]emailアドレスをid_tokenに含めることが出来るようになりました

こんにちは、富士榮です。

LINE Login v2.1で新たにメールアドレスが取得できるようになっています。

https://developers.line.me/ja/docs/line-login/web/integrate-line-login/#applying-for-email-permission

ポイントは以下の通りです。

  • 事前に申請が必要(ユーザに表示する同意画面のスクリーンショットが必要)
  • 特に承認の連絡はなく、いつの間にかメールアドレスが取得できるようになる
  • id_tokenの中のクレームとして取得できる
  • 当然ですが、scope指定でemailを設定する必要がある

以前は個別にパートナー登録が必要、かつprofile apiで取得しないと取れなかった属性なので大きな進歩です。

ということで、やってみます。

◆申請

LINE Developerコンソールを開きます。

Channel設定の下の方にメールアドレス取得申請が出来ています。

ここで申請をします。

この際、同意文書のスクリーンショットが必要なので、あらかじめ用意しておきアップロードする。

申請済み、となるのでしばし待つ。(いつ有効になったのかは不明です。私は申請当日はテストできなかったので、翌朝テストしたら取得できました)


◆クライアントの要求scopeを修正する

メールアドレスを取得するので、scopeにemailを入れてあげます。

◆アクセスする

後は実際に取得できるか確認するだけです。
アクセスするとクライアントがメールアドレスへのアクセスを要求していることがわかりますので、同意します。

ちゃんとメールアドレスが取得できました。

まだまだ全ユーザがLINEのプロファイルにメールアドレスを登録している訳ではないと思いますが、他方でメールアドレス登録を必須としているアプリケーションやサービスも多いので、メールアドレスをLINEから取得できればユーザのID登録の手間を下げることができ、離脱率をさげることが出来ると思います。

是非、活用して行きましょう。

2018年3月2日金曜日

[SAML脆弱性] 外部IdPと連携している場合は要対応

こんにちは、富士榮です。

#コメント部分が本ポストの中でもコメントとして扱われて消えてしまっていたので修正しました。tkudoさんご指摘あざーす
#その他、もろもろ修正しました。酔っぱらって夜中に斜め読みしたらダメですねw

DuoがSAMLの実装に関する脆弱性に関するレポートをしています。

 ZDNetの日本語版記事
 https://japan.zdnet.com/article/35115353/

#しかし、中身は「SAMLプロトコルの」脆弱性じゃなくて、SP実装の不具合なので、「プロトコルの脆弱性」は言い過ぎだなぁ、、と思います。

例によって記事になると何のことかさっぱりわからないので、元ネタとなるDuoのレポートを読んでみました。
(実際に実験は出来ていないので、また時間があれば試してみたいと思います)

Duoのレポート
 Duo Finds SAML Vulnerabilities Affecting Multiple Implementations
 https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations

#Oktaのブログもわかりやすいです。
 A Breakdown of the New SAML Authentication Bypass Vulnerability
 https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-bypass-vulnerability

簡単にまとめるとポイントは、以下の通りです。

  • 外部IdPへの認証要求への返答として帰ってきたSAML ResponseのNameIDにコメントが含まれていると、正規化~署名検証時をした後、コメント部分より前の部分しかNameIDとして扱われず、別のユーザになりすますことが出来てしまう
  • 影響を受けるのは以下の製品・サービス
    • OneLogin
    • Clever
    • OmniAuth-SAML
    • Shibboleth
    • Duo Network Gateway
  • 原因はSAML ResponseのNameIDの値の間にコメント(<!-- コメント -->)が存在した場合に、コメントの後ろの値を無視してしまうため(例:hoge@example.jpとhoge@example.jp<!-- コメント -->.evil.jpが同じNameIDとして扱われてしまう)
  • 対応方法は対策済みバージョンへアップグレードすること

要するに、こんな感じです。

通常はSAML ResponseをSPが受け取る動きは以下の通りです。

今回指摘された正規化~検証後の値の取り扱いに関するバグがあるとこうなります。

NameIDがメールアドレス形式の場合はSP側で別のユーザになりすますのは難しいとは思いますが、NameIDが社員番号などの番号だった場合は割と容易になりすますことが出来そうです。

例えば、
 攻撃者が「123<!-- コメント -->456」
  というユーザでIdPで認証すると
 SPがSAML ReponseのNameIDを「123」として扱ってしまう(コメントより後ろの「456」を正しく連結してくれない)ので、
「123」という全く別のユーザとしてSPへアクセスできてしまうことになります。

まずは皆さんがお使いのSAML SP(もしくは外部IdPと連携しているSAML IdP)が本件に該当するかどうか、対応版がリリースされているかどうかを確認して対策を進めてください。