Mais conteúdo relacionado
Semelhante a OAuth Security Workshop 2017 #osw17 (20)
OAuth Security Workshop 2017 #osw17
- 1. OAuth Security Workshop 2017 TOI
2017-07-24
Tatsuo Kudo http://www.linkedin.com/in/tatsuokudo
Cyber Consulting Services
NRI SecureTechnologies, Ltd.
- 2. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 1
IETF OAuth Working Group がオーガナイズする、
OAuthのセキュリティにフォーカスしたワークショップ
業界関係者と研究者が一堂に会する場を設けること
により、OAuthがもたらす「アシュアランス」の改善と、
OAuth自体の品質向上を目指す
年1回開催。2017年は7月13, 14日の2日間、スイス
連邦工科大学チューリッヒ校にて実施
OAuth Security Workshop とは
https://zisc.ethz.ch/oauth-security-workshop-2017/
Source: https://twitter.com/_nat_en/status/885861840990990337
- 3. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 2
スケジュール
https://zisc.ethz.ch/oauth-security-workshop-2017/
08:30-09:00 Registration and coffee
09:00-09:15 Torsten Lodderstedt, YES Europe Opening Remarks
09:15-10:15 David Basin, ETH Zurich Security Protocols at ETHZ slides
10:15-10:30 break
10:30-11:30 Cas Cremers, University of Oxford
Automated analysis and the subtleties of
authentication: Adventures in TLS 1.3 (Invited
Talk) slides
11:30-11:45 break
11:45-12:30 Michael Jones, Microsoft
OAuth Token Binding: Status and Next Steps
slides
12:30-13:15
Denis Pinkas, DP Security
Consulting
A privacy by design eID scheme supporting
Attribute-based Access Control (ABAC) slides-
scheme slides-German-eID paper
13:15-14:45 Lunch at Dozentenfoyer (directions)
14:45-15:30
Naveen Agarwal, Breno de
Medeiros, Google
OAuth & Phishing – Experiences @ Google
slides
15:30-16:15 Torsten Lodderstedt, John Bradley OAuth security slides
16:15-16:45 break
16:45-17:30 Sven Hammann, ETHZ
Proposing a new Private Mode for Open ID
Connect slides
18:00 Dinner at The Alehouse – Palmhof (location)
08:30-09:00 Coffee
09:00-09:45
Daniel Fett, Ralf Kuesters, and
Guido Schmitz, Universität
Stuttgart
The Web SSO Standard OpenID Connect: In-
Depth Formal Security Analysis and Security
Guidelines slides
09:45-10:30
Nat Sakimura, Nomura Research
Institute
Future Proofing the OAuth 2.0 Authorization
Code Grant Protocol by the application of BCM
Principles slides paper
10:30-10:45 break
10:45-11:30 Hannes Tschofenig, ARM
Lessons learned from security protocol design:
Meaningful content for security consideration
sections of technical specifications slides
11:30-11:45 break
11:45-12:30
William Denniss (presented by
John Bradley), Google
Improving Native App OAuth Security with
External User Agents slides
12:30-13:15
Go Yamamoto, Richard Boyer,
Kenji Takahashi, and Nat
Sakimura, Nomura Research
Institute
Asserting Access Tokens from the Transport
Layer slides
13:15-14:45 Lunch at Dozentenfoyer (directions)
14:45-15:30 Jacob Ideskog, Curity
Simplified Integration of OAuth into JavaScript
Applications slides
15:30-16:00 break
16:00-16:45 Antonio Sanso, Adobe Invalid curve attack in JWE ECDH-ES slides
16:45-17:30 General Discussion
- 4. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 3
セキュリティプロトコルのモデル化
ScytherによるNSPK(ニーダム・シュレーダー公開鍵プロトコル)の解析デモ
AliceからBobの通信をCharlieが仲介し、BobはCharlieのことをAliceだと信じてしまう
cf. https://staff.aist.go.jp/y-isobe/CSP-NSPK/NSPK-CSP-slides-IEICE-Taikai-20150909.pdf
“Provably Repairing the ISO/IEC 9798 Standard for Entity Authentication” の話
ISO 9798-2-5 Symmetric key encryption with TTP (Trusted Third Party)
TTPが実際のEntity Authをやった場合どうなる!?
Security Protocols: Foundations, Methods, and Tools at ETHZ by David Basin, ETH Zurich
https://zisc.ethz.ch/wp-content/uploads/2017/02/basin-securityprotocols.pdf
- 5. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 4
1.3のゴール
レガシーなやつを排除してクリーンスタートする。楕円曲線しか使わないとか
0-RTT、いきなりペイロードが暗号化されてる状態
Clean up design。よりよいデザイン原則。IETFの人がデザイン過程に関わってる
0-RTT
それなりのキーから始めて、あとでアップグレードする。PSK (pre shared key) -resumption。
かなり速い。delayed authentication
Tamarin Prover で formal analysis
クライアント認証周りの攻撃 (revision 10+) を発見
nonceの再利用によるなりすまし
Awkward handshake: Client can’t tell difference between “accept” and “reject but continue.
サーバーが複数インスタンスの場合とか
Automated analysis and the subtleties of authentication: Adventures in TLS 1.3 by Cas Cremers,
University of Oxford
https://zisc.ethz.ch/wp-content/uploads/2017/02/cremers_tls_invited.pdf
- 6. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 5
仕様3つ
draft-ietf-tokbind-protocol, draft-ietf-tokbind-negotiation, draft-ietf-tokbind-https
Keyは長期間 → PC閉じてまた起動してもそのままバインドされてる
Cookieのchannel binding
super cookieを避けた。鍵ペアはブラウザがクッキーと同じバウンダリで作る。eTLD+1
TB4OIDC: tbhというカンファメーションクレーム。ハッシュ。IDトークンに入れる
議論
tokbindいるんか? なにを解決しようとしてるのか
導入時の課題。最新の環境が必要。経済学的には、いろんなブラウザからのアクセスを受け入れた
い。Windows 7とかも。そうするとダウングレードアタックを招く。非常に重要な議論
0-RTTはまだ完全に理解されているものではない。Rev 21でなんか変わった
OAuth Token Binding: Status and Next Steps by Michael Jones, Microsoft
- 7. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 6
アクセストークンを属性のやり取りに使ってる話 (?)
A privacy by design eID scheme supporting Attribute-based Access Control (ABAC) by Denis Pinkas,
DP Security Consulting
https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacybydesign.ppt
- 8. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 7
Challenges with “Undefined”
Developer registration, Approval Page, Notification, Usage, User controls, Revocation, Admin Controls
Googleならではの課題
スコープが数100
データタイプ、なんでもある。GDriveとかも。SnapchatがGCP使ってたり
ユーザーのリテラシー。グローバルなのでバラバラ
企業ユーザーが悪意のあるアプリに権限付与しちゃったりとか
こないだの “OAuth Phishing Attack”
client_idを無効化した。無効化することで同時にトークンも使えなくなる
今後はベリフィケーションをもっとやる、ユーザー数がある閾値を超えたらマニュアルレビューする
Wordpress Plugin のケース。コンタクトしてねボタンがGmailの権限を必要とする。インストールするのはWordpress管理者
Approval Page
多くのユーザーは書かれてることを読まない。レビューとかは読む。Yahooで、スコープを減らす機能をつけた → スコープ減らしたら
SSOしかできなくなった → 前のページに戻ってスコープ戻そうとしたり
サインインについては承認ページをなくした。メールアドレスとプロファイル email profile だけ
UXチームの調査にもとづいて、ボタンを “Trust” にした。ユーザーが実際に信頼するということをわかりやすくした
リボケーション: リスクの高いアプリから順に並べて、レビューしてもらう
ドメインレベルでのスコープ制御: G Suiteでできるようになった。いま何社かでテスト中。Gmailとか単位。あとスコープ単位
OAuth & Phishing – Experiences @ Google by Naveen Agarwal, Breno de Medeiros, Google
https://zisc.ethz.ch/wp-content/uploads/2017/02/agarwal_challenges.pdf
- 9. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 8
“Access token phishing”
リソースサーバーが悪いやつだった場合にどうするか
ASからMetadataを取得する
クライアントに負担がかかる
Audience Restriction
クライアントが、トークン使いたい先 (URI) を指定してATを取得する
TLSへの攻撃には弱い。DNS Attackにも? いずれにせよ TLS ちゃんとしてる前提
PoP
RS XがMITMしようとしたリクエストが無効なものになる。署名が一致しないので
Transport: Token Binding, MTLS (Subject DN使う)
Application: 新しいトークンを作ってAudience Restrictionする。Signed Request, J-POP
Q. Real issueはなによ?
UMAとか、もろに影響がある。あるRSがやられて、そこを踏み台に他のRSがやられちゃうケース。FAPI では Sender Restriction やろうとしてる
Q. ふつうASはRSのこと知ってるよね?
Federated OAuthとか、Googleが3rd PartyにAT出すケースとかある
OAuth security by Torsten Lodderstedt, John Bradley
https://zisc.ethz.ch/wp-content/uploads/2017/02/lodderstedt_accesstoken.pdf
- 10. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 9
IdPはユーザーがどのRPにログインしようとするかを知ることができる。たとえば医療関係の
フォーラムにアクセスしようとしてるとか
Our solution: We propose a new mode that hides the RP’s identity from the IdP
OIDC private implicit mode
implicit modeと同等のセキュリティ
client_id_hash、rp_nonceの導入
▪ AuthZ Reqにおいて、rp_nonceはフラグメントで送る
IdPのJSがブラウザ上でrp_nonceを使ってhashを計算する。ハッシュはランダム値
議論・コメント
IdPのJSが値をサーバーにフォワードしないというのは現実的なん?
IDトークンのリプレイはどうなん?
データ最小化難しいのでは
redirect_uri の verification を JS でやる? できる?
Proposing a new Private Mode for Open ID Connect by Sven Hammann, ETHZ
https://zisc.ethz.ch/wp-content/uploads/2017/02/hammann_oidc_private_mode.pdf
- 11. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 10
OIDC の formal model を開発した
ベストプラクティス準拠
主要なセキュリティ・プロパティを形式化
Authentication (IDトークン), Authorization (ATを使ったアクセス), Session Integrity
Security Guidelines
Mix-up対策(まだ確定してない)
stateはフレッシュなノンス(プレディクタブルにしないように)
リファラーからの漏洩対策
User Intention Tracking
リダイレクトは307じゃなくて303で
オープンリダイレクター除去
CSRF対策
サードパーティリソースの除去
すべてTLS
セッション管理、ログイン前とログイン後でセッションを分ける
The Web SSO Standard OpenID Connect: In-Depth Formal Security Analysis and Security Guidelines by
Daniel Fett, Ralf Kuesters, and Guido Schmitz, Universität Stuttgart
https://zisc.ethz.ch/wp-content/uploads/2017/02/schmitz_oidc.pdf
- 12. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 11
BCM Principles を RFC 6749に適用し、追加すべきパラメーターを検討
3 Criteria
Unique Source Identifier
Protocol + version + msg identifier
Full list of actor/roles
Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles
by Nat Sakimura, Nomura Research Institute
https://zisc.ethz.ch/wp-content/uploads/2017/02/sakimura_future-proofing-oauth.pdf
- 13. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 12
Approaching security in the IETF
RFC 3552: システムセキュリティはスコープ外。ジェネリックなセキュリティフレームワーク、GSSAPIとかSASLとか、プラガブルなやつ。スタイルとして有用なドキュメントではある。不満なところ、セ
キュリティに関する記述が分散してること、セキュリティ専門家がドキュメント全体を読まなきゃいけないこと
RFC 6793: プライバシー
W3CのPrivacy Interest Group はJS APIが対象
“We examined 20 RFCs (15 standards-track) from 1996, well after the imposition of the security mandate: only three had anything substantive to say about security.” -- Nick
Doty, at al. wrote in their position paper for the IAB Privacy Workshop
PKCS#11実装を解析したら no randomness なやつがあった話。 http://homepages.inf.ed.ac.uk/s1050796/
議論・コメント
SAML Conformance Testingの話。みんなテスト通るよ、メッセージチェックしてないから。Negative Testing重要。IETFだとネガティブテスティング無い。相互運用性だけ
アウェアネスとエデュケーション重要。Rationalをもっと書くべき
RFC 6819、Core Specと同じくらいのページ数。誰が読む?
テスタブルであること、テスタビリティ。 "Formal" な stuff を入れるとか
Lessons learned from security protocol design: Meaningful content for security consideration sections
of technical specifications by Hannes Tschofenig, ARM
https://zisc.ethz.ch/wp-content/uploads/2017/02/HannesTschofenig_OAuth_lessons.ppt
- 14. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 13
何が問題か
ユーザー認証・認可について、ブラウザをembedして使うと、かんたんにcookieとか取れるし、JSを注入できたりする
開発者に悪意がなくとも、サードパーティのSDKを使ってるとリスクがあるかも
In-App Browser Tabs
AppAuth ライブラリ
Coming Soon: OpenID RP Certification
iOS 11 beta
WWDC Video #225 https://developer.apple.com/videos/play/wwdc2017/225/
(beta 3 adds SFAuthenticationSession to enable Shared Authentication Context (Single Sign-in))
Improving Native App OAuth Security with External User Agents by William Denniss (presented by John
Bradley), Google
http://www.thread-safe.com/2017/07/appauth.html
- 15. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 14
インターネットから物理システムを監視したい。REST API出したい。そこの認可にOAuth使いたい
工場Aと工場Bとの連携。工場BはAのセキュリティをマネージできない
提案: 認可サーバーが証明書を発行し、X.509の属性としてATを返す。クライアントはその証明書を使ってRSに接続する
議論・コメント
クライアントが動的にクライアント証明書を切り替えられるだろうか?
ガチガチに繋がったPKIは避けたい、別々にCA持ちたいというニーズ
Token in Token?
リソースサーバーごとにクライアント証明書を切り替える? チャネルの再利用できないよね
15分毎に50万台の証明書をアップデートするような環境に有用
署名処理はいまやそんな高コストではないという前提
証明書をATとして使えばいんじゃね、イントロスペクションすればいんじゃね、という話
Asserting Access Tokens from the Transport Layer by Go Yamamoto, Richard Boyer, Kenji Takahashi,
and Nat Sakimura, Nomura Research Institute
https://zisc.ethz.ch/wp-content/uploads/2017/02/yamamoto_token_transport_layer.pdf
- 16. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 15
フロントエンドのつらみ
デベロッパーが理解するにはいまだ難解
SPA対応、implicitでは不十分
トークンハンドラー・パターン
フレームに入れて分離、有効期間長めのトークン
Token Handler Token
▪ postMessage、タイムアウト5秒くらい
Assisted Token Flow
"Assisted Token" は cookie に入れる。HTTP Onlyにして、JSから覗けなくする。Secureにして、
HTTPオンリーにする
for_origin
redirect_uriではない。クライアントをサーブするドメイン。フレーミング(型にはめる)ために使う。
X-FRAME-OPTIONS、CSPヘッダー
議論・コメント
Service Workerでやるといんじゃね?
問題は単純、レイヤーをどこで分けるかがポイント
Simplified Integration of OAuth into JavaScript Applications by Jacob Ideskog, Curity
https://zisc.ethz.ch/wp-content/uploads/2017/02/ideskog_assisted-token.pdf
- 17. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 16
http://blogs.adobe.com/security/2017/03/critical-vulnerability-uncovered-in-json-encryption.html の話
Invalid curve attack in JWE ECDH-ES by Antonio Sanso, Adobe
https://zisc.ethz.ch/wp-content/uploads/2017/02/sanso_jwe.pdf
- 18. Copyright © NRI SecureTechnologies, Ltd. All rights reserved. 17
スライド / ペーパー
https://zisc.ethz.ch/oauth-security-workshop-2017/
Twitter
https://twitter.com/hashtag/osw17, https://twitter.com/hashtag/osw2017
Resources