  |
はてなキーワード:中間者攻撃とは
中間者攻撃の話をしているので、通信経路の途中にプロキシを仕込むような話ではありませんか？
ユーザがサービスに対してパスキーを生成したつもりにさせておいて、本当のパスキー（秘密鍵と公開鍵）はプロキシが作ってサービスに登録しておけばいい
なりますしによるパスキー登録のパターンですね。攻撃シナリオとしてはあり得ます。
イメージとしては
1.フィッシングサイトに通常のID/パスワードでログインさせる
2.フィッシングサイトが正規サイトへ中継ログインし、正規のログインセッションを窃取する
3. そのセッション情報を使って攻撃者が自分の端末へパスキーを登録する
になるでしょうか。
ただこの攻撃は最初にユーザがパスキー以外の方法でフィッシングサイトへログインしようとする行動が必要です。
今後発生しうる可能性は勿論ありますが、パスキーを使う前段の問題でしょう。やはりパスワードは滅ぼすべきですね。
（勿論サイト側としても、パスキーが登録されたらユーザ側へメール等で通知して作成されたことを知らせると言った対策は必要です）
https://b.hatena.ne.jp/entry/s/xtech.nikkei.com/atcl/nxt/column/18/00001/10906/ を見て、パスキーでできること、できないこと、その他まとめます。
パスキーはドメインと紐付けて鍵を生成するので、ドメインが異なる別のサイト（フィッシングサイト）へ正規サイト用の鍵が用いられてしまうことはありません。
人間の目にはどれだけ精巧なフィッシングサイトであっても、ブラウザから見ればドメインが違えばそれは全く別のサイトです。騙されやすい人間ではなく「ブラウザがドメインから判断して適切な鍵を利用する」が肝と言えます。
これでフィッシングサイトは実質、無意味なものになりました。やったね！
※マスコミ用語（？）ではリアルタイムフィッシングと呼ぶようですが、一般的にはこれは中間者攻撃と呼ばれるものです。「ほぼ」としたのは、ブラウザやOSの実装にバグがない限りという条件が付くためです。
パスキーの突破が不可能なら、ユーザにパスキーを使わせなければ良いのです。ブラウザやOSを騙すより人間を騙す方が遥かに容易いでしょう。
こんなメッセージを見て「パスキー使えないのか～、じゃあパスワードでログイン、ポチっとな」となる人が絶対居るのでパスキーとパスワード廃止はセットであるべきです。が、パスキーを使えないレガシーな環境を切り捨てることになるので、サービス提供者側としてはやりにくいでしょう（今時パスキーも使えないレガシー環境を許容すべきではないのですが）。
またパスワードを廃止したとしても、次はアカウントリカバリ手段への介入・悪用からの乗っ取りを目的として誘導するフィッシングサイトが作られるでしょう。
ユーザ側の認知度の問題の他に、サービス提供者側はパスキー実装だけでなく既存認証基盤との共存を考慮する必要があるのでそれなりのコストが掛かるようです。
それでも金融資産を扱うサイトは変なワンタイムパスワードなんかやってないでさっさとやるべきなのですが。
パスキーは認証のためのものであって、認証された後にマルウェアなどがセッショントークンを窃取する攻撃には無力です。
スマホでの使い勝手からよく誤解されていますが、生体認証はパスキーの要件ではありません。
生体認証は「Webサイトログインのための本人確認」ではなく「鍵を使うための本人確認」です。この本人確認の手段は必ずしも生体認証でなくとも構わないのです。
パスワードと違って、1つのサイトに対してプラットフォーム毎にパスキーを作成することが可能です。
最近はブラウザまたはOSの同期機能で1つのパスキーを共有することもできますが、ログイン手段の冗長化という観点でプラットフォーム毎に作っておくのも良いかと思います。
現在、証券口座乗っ取り対策で行われようとしているメールやSMSでの追加認証は逆効果になると思ってる。
メールやSMSなんてフィッシングの入れ口なわけで、そこを頻繁に使わせるのはダメだろう。
初回登録時の1回だけならメールやSMSでの認証はありだけど、頻繁に使わせたらフィッシングを踏む確率を逆に上げてしまうだろう。
結局、FIDO認証や物理キーの認証にもっていかないとダメだと思う。
それまでのつなぎだとしても、メールやSMSを二次認証につかうのは筋が悪い。
もし急いで対策しないといけないとしたら、ユーザに日本語も使える新しい秘密の質問でも作ればいいんじゃないのかな。
ユーザのIPアドレスが普段とはあまりに違う場所から行われていたら、その質問を表示して答えられなければアクセスを拒絶するという感じで。
お前の兄ちゃんだよ。
本当に兄ちゃんか？
本当兄ちゃんだよ。
4
わーい兄ちゃんだ。
これだよ。これ。
ドリフのバカ兄弟の認証こそ手っ取り早く実装できる認証の例だろう。
でもユーザーが中間者攻撃を使って送信内容が解析してきた場合、彼らの秘密のファイルやチャット履歴などをあなたが傍受しているのがバレちゃいます。
せっかく「E2E暗号化方式を採用しています！へーしゃはあなたのデータにアクセスできません！！😤」などと謳っていても実は別口で傍受してたなんてバレたら終わりですよね。
そこで証明書のピンニング（certificate pinning）を使いましょう。
これはアプリの中に埋め込まれた証明書を使う事で通信の信頼性を確立するもので、これを使うことで中間者攻撃を無効化できます。
銀行取引の保護や、ゲームのチート対策などにも使われている技術です。
GoogleやAppleといった大企業ももちろん色んなところで使っています。
中間者攻撃ができないのでユーザーは「何か送ってるな」程度のことしか分かりませんし、もしユーザーになにか聞かれても「UX向上が目的のアナリティクスなんですけど！でも安心してね！へーしゃはあなたのデータにアクセスできません！😤」としらを切れます。
実際、Amplitudeなどの大手ユーザー解析サービスはアナリティクスデータの送信にこの技術を使っています。
現在、証明書のピンニングは非推奨とされている例が散見されますが、それを捨てるなんてとんでもない！
証明書の有効期限が切れる前にアプリをアップデートしないとデータが送信できなくなる等が理由ですが、こっそり送ってたデータが送れなくなってもUXは何も変わりませんからね。
最大のリスクは内部告発ですが、結局外からは分からないので、「そんな事はやっていません！弊社に恨みを持つ者の悪質なデマです！気になる人の為にアナリティクスをオプトアウト出来るようにしました！良かったね！」などと言って、ユーザーを上手に扱いましょう。
https://qiita.com/ockeghem/items/c6a3602d2c2409f89fbb
オフラインでも通用する物理的なハッキングもそもそも公衆無線LAN論の外としてさぁ
お前そりゃ悪人の庭に自ら足を踏み込んだらカモネギでむちゃくちゃにされるに決まってんだろって
そんな話は一般人にとっちゃぶっちゃけどーーーーーーでもよくない？
証明書含め基本のセキュリティ対策は提供側が最低限しているというほぼ確認しようが無い前提に立って
「一般人がフリーWi-Fiに繋いだときのリスク」が求められている話なんで
たとえば同じフリーWi-Fiに悪い人と同時に繋いでいたらリスクがあるのかな？とか正式なフリーWi-Fiに繋いでいるときに通信を盗聴されるフリーWi-Fi独自のリスクはあるのかな？ってところが疑問点
正規の手順で正しく使っているのにも関わらず自宅のWi-Fiより高まるセキュリティリスクって…(不安)みたいなところに
偽APやらそっから中間者攻撃やらに繋げられてもまったくもって芯を食ってない
ファイル共有についてはまあ不注意っちゅうか利用者しっかりしとけよって話なんだけど
とかく全体的に"ずらし"をされてるって気分を毎度セキュリティ記事を読むたび思うんだよね
お前、その前提だされたらなんもいえねーわ
みたいな
昔、PCにハッキングする早さを競う企画があったと思うんだけど、そのPCはセキュリティアップデート施してないデフォルト状態でしたってことでｽﾞｺｰっとすっこけたことがあった
それで「ハッキングは怖いですね～」ってならんでしょ
まあガチガチの最新状態のなかで未知の脆弱性を見つけるなんて逆にお金もらえることなんだから企画になりゃせんがね
僕のPCが日常使いでハッキングされる危険性を煽りつつ内実セキュリティアップデートすらしてない環境前提で話が進んでもズレてんだわ
ってこっちの話もずれたけどよー
うちの会社のアプリの通信の一部にはピン留めされた証明書が使われている。
と言ってもサードのサービスとの通信でだ。そのサービスのSDKをアプリに仕込んで、ユーザーの挙動を逐一そのサービスに送って後で解析するのだ。
そしてそのサービスはセキュリティを理由にこの技術を使っている。
これにより中間者攻撃ができないので何を送ってるのかはセキュリティ専門家でも分からない。
だから何でも送り放題だ。うちはパスワードこそ送ってないが、こんなもんまで送って良いんかなというものも送っている。
でも通信を覗けないのでバレない。これ自分がただのユーザーだったら超嫌だなと思う。
犯人にとって転売品は何でもよく、個人間取引を乗っ取った中間者攻撃の三角貿易で現金を詐欺るのが目的。というのはgithub見ればわかる。
犯行少女にとってネット取引の経験があり、価格のぶれ幅のあるチケットを扱ったのだろう。
チケット出品した専門学校生と落札者は、入金・チケット受け取りが完了して事件の存在にも気付いてない。
確かに警察への被害届の訴えは、チケット落札入金したのに届かない、という形だが、そこにとらわれて事件を単純視していたから
実名口座実住所の振込先専門学校生の存在が確認できただけで十分として事件捜査がおろそかになったのだろう。
＞・詐欺は重い罪で、嫌疑後の証拠隠滅も容易な場合が多いので、８万円程度でも１９日の拘束はありうる。
証拠隠滅の問題だったら、事件発生2016年8月、徳島県警三好署への被害届2016年9月、そこから年をまたいで専門学校生逮捕2017年5月は遅すぎる。
証拠隠滅するような犯人が、のこのこ実名口座に入金させるのが警察検察にとっての常識なのか？
＞・もし犯人が架空口座を使ったりBTC等で取引してたら、チケット転売サイトへの情報開示請求だけでは辿れず、ツイッター社へのIP開示、プロバイダ照会まで行かざるをえず、さらに犯人がMACアドレスをデフォルトから変更した上でFree-Wifiを使って取引していたら、辿り着けなかったかもしれない。
むしろまずIP開示、プロバイダ照会をもってデジタル証拠として、あなたが疑わしいから逮捕するよ、と持っていくのが筋ではないか。
その上で犯人が無線LANタダ乗りMAC偽装で、とわかれば、誤認逮捕やむなし論が出る余地がある。
専門学校生へ接触した犯人のIP、被害者へ接触した専門学校生名義での犯人のIP、なと真犯人へたどり着く証拠はあったからこそその後の捜査で見つかったはず。
半年以上の捜査の期間でそれすらもしていないのに、いきなり逮捕勾留して否認・嫌疑不十分釈放してから本格捜査で真犯人到達って怠慢では？
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾanond:20160426145507anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication:本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にもOAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事はOAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法でOAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りのOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定のOAuthベースの規格について述べるのではなく、現状で大手がOAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法でOAuth を使っているサービスの利用者であっても、また自らOAuthベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まずOAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されているOAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中にはAmazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおけるOAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM やOracle を含め、懸念した IETFメンバーがOAuthベースのサービスに対する攻撃を 50クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuthベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこのOAuthベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえにOAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuthベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのようにOAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理にOAuthベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうとOAuthベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCPサービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よくOAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつOAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略:スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4.脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要なOAuthベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアなOAuthモデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な)バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuthベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secretパラメータは、基本的に言ってサードパーティのプラットフォーム固有の APIユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secretパラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント:パラメータ名の中にsecret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secretパラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローをOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮にFacebook がGMail 用のOAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員GMail に対してFacebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API利用者が、埋め込むべきでないところにsecret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uriパラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要なOAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういったOAuthベース API がたくさん見つかります。Google はOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret:開発者コンソールで取得したクライアントパスワード (Android, iOS,Chromeアプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uriパラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだOAuthベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数のOAuthライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的なOAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1.クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者はOAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームがOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年のOAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google がOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくともGoogle の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアなOAuthフローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
http://anond.hatelabo.jp/20130526021902
http://anond.hatelabo.jp/20130528230001
の続き
２．中間者攻撃（man-in-the-middle attack）
ブラック企業は鉄壁の防御で僕等の希望を押しつぶすように見えるけど、たかが人の子の作りしもの。
必ず「人間」という弱点はある、というのが前回のあらすじ。
さて「釣りバカ日誌を参考にしてもスーさんなんて見つからないよ」というのが●●の壁。
順番が逆。
まず組織の偉い人にターゲットを定めて、アプローチする為の踏み台を探す。
例えば「お局様、『偉い人』が新人時代の世話役。口癖は『▲▲ちゃんも偉くなったもんよね』」とか
新人だったら「新人同期◆人で『偉い人』のお話を伺いたいっす」とか
ブラック企業の中で頑張ってもしょうがないなら、社外の偉い人をロックオン
とにかく人の力を借りて「１．なりすまし」に使える材料とアプローチする機会を探す。
これが二番目
（続く）
