  |
はてなキーワード: 一方通行とは
1年間、ずっと彼女がいる人のことが好きだった。
そいつとはちょうど1年前、本当にちょっとしたきっかけで仲良くなった。お互いの部屋を行き来するようになり、一緒にテレビを見たり一緒に寝たり、そういうことを何度かしているうちに私はどんどんと彼のことが好きになって、もしかしたら向こうもそうなのかもしれないと、そう思っていた矢先、そいつに彼女ができていたことを知った。
かなり、かなりショックだった。けど、もう私は後戻りできなくて、そのまま1年間、浮気相手のような、2番手のような、今流行りのソフレのような、1週間に1回くらいの頻度で部屋に行き、2人で過ごしてキスをして一緒に寝るというよくわからないふわふわとした関係をずるずると続けてきてしまった。
いつか辞めなきゃいけないということは分かっていて、でも無理だった。彼は彼女と別れる気もなければ私との関係を自分から終わらせる気もないようだった。終わらせるとしたらその役目は私が負わなきゃいけなくて、傷つくのも、私だけ。そう思うとどうしても耐えられなくて、目をそらして逃げ続けて、1年が経った。
もしかしたら、もしかしたら彼も私のことが好きになってくれるかもしれないという期待もあった。私を大事に思ってくれているような感じはあったし、諦めなければそのうち私が1番になれるんじゃないかって、妄想を抱えて現実から顔を背け、関係を続けてきた。
でも、昨日。
私はふと出来心で彼のラインを覗いた(勝手に人のラインを覗くなんてまずそれ自体がクソとしか言いようがないし、そこに関しては私が全面的に悪いとしか言いようがないのだが、そこは一旦目をつぶってほしい)。そこには彼女との会話や私との会話の他に、共通の友人(女)との会話もあった。私は何の気なしにその会話を開いた。それがとんでもない地雷だった。
言ってしまえば、彼はその女の子とも浮気関係にあった。私だけじゃなかったのだ。彼はその子に向かって、「好き」「早く会いたい」とラインを送っていた。キスの写真もあった。
とんでもないものを見てしまったという動揺と、ショックと、怒りと、悲しみとで頭が混乱する中、ふと思った。
私は1年間この関係を続けてきたけど、彼に「好き」って言われたことはなかった。私はずっと2番手にされているのだと思っていたけれど、それすら勘違いだったのかもしれない。最初っから最後まで、私の一方通行で、彼から感じていた私への親愛は、全て幻想だったのかもしれない。
彼にとって、私は、なんだったんだろう。友人だろうか。キープだろうか。それとも、部屋によく来る抱き枕か何かのように思っていたのだろうか。わからないけれど、ひとつ言えるのは、私のこの1年間は全くの無駄だったということだ。
今は彼の顔を見たくないし、もう1人の浮気相手の女の顔も見たくないけれど、大学が一緒なので否応無しに見なければいけない。ていうか今日会うし。耐えられるだろうか。
ほんとにこの1年間、なんだったんだろう。できることならやり直したい。
ずっと好きだった人と付き合えることになった。
前から彼と共通の知り合いと何人かで遊んだりしてたけど突然彼から個人的にご飯に誘われた。
何回か彼と個人的に会ううちに、彼は私のことが好きなのでは？と勘違いしてしまった。喪女もいいところである。
ついに調子乗って「付き合ってくれませんか？」って言ってしまった。
彼は驚いて「考えさせて」って言った後に「いいよ」って言ってくれた。
この時点で彼は私のこと好きじゃないんだなってちゃんと気付けばよかった。
正直付き合う前の方がデートっぽいことしてたしLINEもたくさんしてた。
今じゃご飯行ってもあまり会話が進まないしLINEも既読無視される。
その度に「ああ、彼は私のこと好きじゃないんだな」って痛感させられる。
彼のことはずっと好きだったし今でも好きだけど一方通行すぎて正直好きでいることにちょっと疲れてきている。
一言で言うなら『やっぱNEVERまとめもまともじゃないのこいつもさっさと閉鎖しろ』という話。
ただの個人的意見だがネットに限らず不特定多数に現在の正しい情報を提供するためにはエビデンス(証拠的な意味での)は公的機関等が発表した信頼性の高い書物、論文、記事であるのが絶対条件。そしてその中でも過去4〜5年くらいまでのものが実際に使えるものだと思っている。私が学生時代にディベートの試合なんかをしていた時には年季の入った引用先のエビデンスは信憑性が下がるから使うなと指導されたものだ。
WELQに始まるキュレーションメディアの騒動では著作権違反やらエビデンスなんてクソ喰らえと言わんばかりのデマ拡散やらで多いに盛り上がったが最近NEVERまとめでも微妙に怪しいまとめを見つけてしまったのでそのことについて記そうと思う。
近辺でのインフルエンザの予防接種を扱う病院を調べていると何故かまとめサイトに行き着いた。「インフルエンザワクチンは打たないで！」とかいうタイトルなのだが引用(という名のただのほぼパクリなのはともかく)されている情報の信憑性が欠けているように思えて仕方がなかったので少し調べることに。
このまとめの引用元としてよく使用されている元母里氏の書籍だが発行はなんと2007年。9年も前の医学を元にまてめているらしい。そして氏のワクチンは全く効かないだとかのアンチ的意見も引用されてるが、(引用に問題があるのかもしれないが)特に例を出されている箇所は約30年ほど前のワクチン使用中止の話がベースとなっている節がある。医学が進歩する中、今のワクチン事情に引き合いに出すものではない。
あと気になったのが慶応大等の研究結果によりインフルエンザの予防接種は中学生や乳幼児には無意味！という記事。研究結果自体をちらっと拝見すると単に"件数不足により分析不可"ということらしい。うむ、毎○新聞の記事はあてにならないということか。
…とまあ医療知識に乏しい素人目でもちょっとおかしいなと思っていたのだがネット上にもこのまとめについてWHO等の発表や最近のワクチン事情について比較的信憑性の高いエビデンスを用いた反駁をされている方々がいるようで。それらはワクチンの効果は十分期待できるものであり近年使用されているワクチンは危険性が低いよう改良されている等まとめの内容と真逆を行く情報ばかりだ。
無論私もワクチンに限らず薬には副作用があるもので100％の安全性があるとは考えていない。が、この情報を見た今まとめにあるような危険性があるとも考え難いものがある。まとめを信じるか否かは各々に任せるとしてもこのような情報も確認したまとめ閲覧者はどれ程いるのだろうか。
他に腹の立つことを挙げるならば後半のページにあるこのまとめに対する肯定意見やワクチン否定派のTwitterまとめ。否定的な意見は気にもせず一方通行で「常識はウソ、こんなに沢山の人が信じているから正しいに決まってる」的な誘導をしたいのだろうか。このような自分に都合の良い情報ばかりを集める所はアフィリエイト丸出しの2ちゃんねるまとめサイト等にもよく見られるものだが。
このまとめを知る人からしたら何を今更とも思うかもしれないが一連のキュレーションサイト問題がここまでの大炎上となった今、この騒動が鎮火する前に是非このような情報を拡散するNEVERまとめも逃げずに削除なり何なりの対応を取ってほしいものである。
ネットの海を泳いでいると、しばしば乞食行為に出くわすことがある。「誕生日が近いのでほしいものリスト公開します！！」みたいな。
ブログをやってる人、いわゆるブロガーなんて人種がそういった類のことをやっている印象だが、傍から見てて「気持ち悪いなぁ」と思ってしまう。乞食している側も贈っている側も馴れ合っている感じがして非常に気持ち悪い。
そういった行為を見かけると「そんな物乞いみたいな真似してないでブログの収益を使って自分で買えばいいじゃん」と思うし、「この人たちは現実のみならずネット上でも馴れ合って一体何がしたいのだろうか」とも思う。
私個人の感覚としては、プレゼントという行為は自分でクレクレ言いに行くものではなく、贈る側が何らかのアクションを起こすことによって始まるものだと思っているのだが、世間一般の感覚はどうなのだろう。友人でも家族でもない人に物をねだるだなんて行為、私には到底できる気がしない。
似たような例として、海外のフリーソフトやオープンソースソフト界隈ではPayPalによる寄付文化があるが、ああいったものに対して特に嫌悪感はない。恐らく、自分自身が「そういった寄付がモチベーションに繋がる」ということを身に染みてわかっているからだろうし、そもそもそこに馴れ合いは存在せず、利用者→開発者という一方通行の感謝の念だけが存在している(と私は思っている)からだろう。
同様に、プロフィール欄などに欲しいものリストのURLが貼ってあるような例も見かけるが、あれらも特に嫌悪感はない。PayPalの件と同様に自らクレクレ言っているわけではなく、その人に対する何らかの報酬・対価を贈るための手段として、PayPalなり欲しいものリストへのリンクが置いてあるだけだからだろう。
要は私の中に「友人でも家族でもない人に物をねだる」「ネット上で馴れ合う」といった価値観が存在しないために、ここまでの嫌悪感に繋がっているわけだ。狭量な人間だね。
まぁそれはともかく、こんなことを言っていると、ほしいものリスト乞食をやってる人からは「嫉妬してるだけでしょ」「全員がブログで収益出てるとでも思ってるの？」「嫌なら見なければいいじゃん」といった声が飛んできそうである。
嫉妬云々は感情の話なので否定したところで証明のしようがないが、収益云々に関しては「初期費用がゼロで済む以上、金額を問わなければブログで利益を出すのは全く難しくない」と思っているので、そんなことを言ってくる人とは根本的にブログに対するイメージが違うのだろう。
「嫌なら見るな」という意見はごもっともなド正論なので、そういった乞食行為をやっているのを見かけたらTwitterなりFeedlyの購読を解除するようにしている。
悲しいなぁ。
今まで生きてきて、1度も結婚式に呼ばれた事がない。ひとりっ子かつ親戚付き合いも殆どないので、身内の結婚式にも出たことがなく、本当に祝いの席に参加した経験は皆無である。流石にこの歳になると、結婚式に出た事がないとは恥ずかしくて誰にも言えない。友達がいないと公言しているようなものだ。
友達がいなかった訳ではない、と思っている。いや、今となってはよく分からないが。
小学校はイジメられっ子だったが、学区の違う中学、高校では一緒に遊ぶグループもできた。しかし卒業と同時に縁が切れ、今ではフェイスブックでふわふわ繋がっているだけの関係。なまじ繋がっているから、彼等が素敵なパートナーと結ばれて華やかな式を挙げたことだけは知っている。早い人には子どもも出来た。大学生活はリア充とは程遠かったものの、サークル、語学のクラス、バイト先、学生寮にそれぞれ親しい人達がいた。しかし、サークルは活動がガチ過ぎてついて行けなくなって辞めてしまった。無理にでもついていくべきだったのだろう。語学クラスとバイト先の仲間は、進学•就職を機に付き合いがなくなった。こちらも高校時代同様、フェイスブックだけで未だふわふわ繋がっていて、最初の数年は同窓会もやったりしたが、そのうち開催しなくなった。SNSでの私の見かけの友達数はやたら多い。学生寮の人間とは、引越した後も比較的長く付き合っていたが、2-3年もすると徐々に疎遠になってしまった。学生寮は同窓会ネットワークもないので、今後会うことはないような気がする。大学院の研究室の関係者とは、今も関わりがない訳ではないが、非常に表面的な付き合いである。
考えてみたら、友達だと思っていたのは私の一方通行な勘違いで、どこにも友達は居なかったのかもしれない。だから、誰からも祝いの席に呼んでもらえないのだ。お前が積極的に繋がりを残そうとしなかったのが悪いんだろう、自己責任だ、と指摘されるかもしれない。確かに、私は同窓会の幹事をやった事もないし、そんなネットワークも行動力も持っていなかった。でもその程度の受け身人間、いっぱい居るじゃないか。それに、親しい(と思っていた)数人に連絡して遊びや飲みに誘うくらいのことなら、自分でもやってきた。けれど、私がやると何故か上手くいかないんだ。誰も乗り気でないような、酷い場合には全員不参加で流れるような。
今の職場にも、プライベートで飲みに行ったりする仲間はいるが、彼等を友人と呼んで良いのか分からない。職場が変われば簡単に付き合いは無くなる気がする。ついでに言うと既婚者ばかりなので、仮に付き合いが続けられても結婚式未経験なのは変わらなかったりする。
そういえば職場の後輩が、学生時代の友人の結婚式が今週末あると言っていた。新しい服やらご祝儀やら、出費がキツいと嘆いていた。「増田さんくらいの年齢だと結婚式多いですよね？どうやってやりくりしてるんですか？」と聞かれたけど、さすがに行った事がないとは言えず、金欠だよね等々言って適当に誤魔化しておいた。今頃披露宴なのだろうか。誰かの華やかな人生の門出に立ち会って祝福するというのは、どんな感じなのだろう。私には、誰かを祝福する資格は無いのかもしれない。
レイヤーにして法曹界の卵という訳がわからない存在になってることを
映画300みたい♡と記事中の写真から肉体美を十分くらい賛美したのだけど、
聞けば、見たことがないらしい。
単純に、友人は学校の旧い同期のことで盛り上がりたいのだと気づいた。
同期との繋がりが友人A一人だけになってしまったオレと違って
友人は定期的な交流があるようだった。先の記事も一週間前だった。
誰かが知らせてくれたんだろう。本人かも知れない。
そう分かって、雄っぱいではなくメイクを落とした顔の方を凝視したが、
200人程度の同期にこんなやつがいたかどうか、終電で別れる最後まで思い出せず、
ダルい気分で自宅に帰った。
その晩は学校の中の狭い付き合いでしか生まれない古い嫉妬を思い出して久々に胸が軋んだ。社会に出てから一方通行な関係は普通だと自明だと自分に言い聞かせてたんだが。
うちの子が風邪でダウンしてしまったので、今日は会社の休みをとった。今、子どもは寝ているので、様子を見ながら、先週末から気になっていたことを、長文に書いてみよう。
立て込んだ住宅街で、アップダウンが激しく、カーブの多い道幅の狭い道路が入り組んでいる・・・東京23区の住宅街では珍しくはない道路事情だろう。私が日常的に駅へ行くのに使っている道路も、そのような地域の人々の生活道路のひとつだ。道幅は広いところで5メートルあるが、全体をつうじては4メートルのところが多い。歩道は確保されていない。タクシーの運転手も嫌がるような一方通行の狭い道だ。
その道路の中でもとりわけ道幅が狭い区間が、200メートルほどある。一番狭いところは道幅3メートル50センチだ。
この道は私たち住民の生活道路だが、数百メートル向こうを通っている幹線道路への抜け道として「抜け道マップ」に掲載されたこともあり、ただ通過するだけの車も少なくない。近隣のコンビニの配送の大型車もひっきりなしに通る。時間帯によっては学生のママチャリも多い。住民は、ベビーカーに子供を乗せたお母さんも、歩行補助のカートを押して歩くおばあちゃんも、道路幅のわりに多い交通量に気を使いながら、びくびくして歩いている。
「歩きスマホ」は、この道では、既に問題として指摘されていた。駅に向かう人と駅から歩いてくる人が狭い道路の両側にいるだけで、道幅は半分以下になる。車はひっきりなしに通る。そこで歩きスマホなどしたらどういうことになるか・・・後ろから車が来ていることにも気づかずに手元を見て歩き続けている人がいたので、見かねて、すれ違うときに「危ないですよ」と言ったこともあるが、「何、このおばちゃんは？」という目つきで睨み返されただけだった。
この道路は曲がりくねっている。道路幅が5メートルの区域からカーブを描いて下り坂を曲がったところが幅4メートル、その先が幅3メートル台の区間で、歩きスマホという問題などなかった時代でも、カーブを無謀にも飛ばしてくる土地勘のない車と、歩行者や自転車が接触しそうになるようなことは、しょっちゅうだった。せめて拡幅すれば危険は軽減できるとして、区の「安全安心な住み良いまちづくり推進評議会」のようなところでも議題になったそうだ。だが、道路の拡幅は一向に実現しそうにない。地権者が多すぎて埒が明かないのである。
私自身も、先日、そこでヒヤリとする目にあったばかりだ。日曜日で、ママチャリでスーパーに買い出しに行くため、道路の左側を徐行していた。私の10メートルほど前にはカートを押した高齢者がゆっくりと歩いている。道路の右側は幼い子ども2人の手を引いた父親と母親が歩いていて、それだけで道幅は半分以下だ。ここに車が来たら危ないなあと考えながら、私が高齢者にほとんど追いついたとき、カーブの向こうから歩きスマホの若者が現れた。面白いマンガでも読んでいるのか、画面をスワイプしながらニヤニヤと笑って歩いてくる彼は、高齢者に気づかず激突しそうだ。そこは高齢者が慣れたもので、電柱の際に立ち止まり、若者を先に通そうとした。歩きスマホの若者が道路の左側をそのまま歩いてきて、右側の親子連れとすれ違おうとする瞬間、両者の間に確保された狭い空間を抜けて、私はママチャリで進もうとペダルを踏み込んだが、急に歩きスマホが電柱に気づいたのか、道路の中央に向けて足を踏み出した。「フラフラと道路の真ん中に出てきた」のである。このままでは私が歩きスマホに激突してしまう。反射的にハンドルを切って自転車の急ブレーキをかけた。後続の自転車が反射的に左に出て、電柱脇の高齢者に気づいたのだろう、左後ろから急ブレーキの音がした。同時に、カーブの向こうから、下り坂でスピードに乗ったミニバンが曲がってきた。子どもの「あっ」という声が聞こえた。歩きスマホは下を向いたままこっちに歩いてくる。耳にイヤホンがささっているのにそのとき気づいた。後続の自転車のおじさんが「っぶねぇ！」と叫ぶ声がした。
いったい、どのようにして何事もなく済んだのか、回想しても思い出せない。私は気づいたら道路の右側、縦一列になって立ち止まっていた親子連れの後ろで自転車を降りてハンドルを支えていた。道路の左側では、電柱脇の高齢者も、歩きスマホの若者も、後続の自転車も、通り過ぎていくミニバンとは接触していなかった。一瞬のできごとだった。でも、長く感じた。スローモーションに見えた。
歩きスマホが急に道路の真ん中に出る前に、一瞬でいいから画面から目を上げて周囲を確認し、できれば道路脇に寄って立ち止まってくれていたら、あんなふうにヒヤリとすることはなかっただろう。
こういう環境に、「ポケモンGO」がやってきた。この先で道路が少し広くなっているところに、何かのスポットがあるのだそうだ。
日曜日の夕方、狭い道路で、2列に広がった男子2人組が、一心不乱にスマホを見つめて歩いてくる。「男子」と言っても20歳は超えているようすだ。普段この狭い道路を使っていれば、体の小さな子どもでも、この道で2列になって歩いたりはしない。その後ろのほうには、自転車にまたがって、ハンドルにもたれかかってスマホの操作をしつつ、つま先で地面を蹴りながらふらふらと進んでいく15歳くらいの少年もいる。前方などまるで見ていない。この先はカーブだし、右方の道から出てくる車もいる。事故が起こらなければいいけれど。
「ポケモンGOで歩いて健康増進」と言って宣伝するのはよい。スマホのアプリを起動したままで歩くだけなら何の問題もないのだから。しかし、せめて、画面を見ていなければならないようなシーンは公園の敷地内のような広いスペースや、歩道が整備されている場所だけにしてくれないだろうか。それでも「歩きスマホ」に係る問題は避けて通れないだろうが、人と自転車と車がひしめきあっている幅の狭い生活道路に、多くの「歩きスマホ」が出没することは、シャレにならないのだ。
ARがどうのこうのなどという高尚なことは、現に人間が暮らしているリアル世界に持ち込むのなら、交通事故のような基本的な安全性を確保してから実験してほしいと思う。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond: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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
友人知人の悩み、細々とした愚痴（時々悩みを装った自慢も）を聞くことは、たとえ些細な内容でも苦ではなく、むしろ少しでも楽になってくれれば有難いなあと思い、聞いているつもりである。それに聞いてくれて有難うなどと言われると、「社交辞令だよな」とは思いつつも嬉しい。
しかしそういう悩み、愚痴を細々と持ち掛けてくる人に限り、彼ら彼女らがいつも他人に持ち掛けてくる内容に類似しているような悩み、愚痴を他人に持ち掛けられても、まるで興味を示さない、あるいは明らかに話半分で聞いて（ひどい場合は嫌な顔をする）、返答はそこそこ。挙句いつもの自分の話に持っていく事に、最近気付いた。
そういう対応をされたり、されているのを見たりしていたら、いくら聞く事が苦でなくても、興味深い内容でも、そういう輩の話は一切聞かず、シャットダウンしてしまおうと思う。
見返りを求める行為は卑しい事なのかも知れないけれど、やはり一方通行は解せないし、甘えるな、馬鹿にするなと思ってしまうのだ。
随分上から目線の文章になってしまい恥ずかしいが、ここ最近こんな出来事が続き、もやっとしてしまったので思わず投稿した（初投稿）。
好きな人の「好きな人」にはなれないから、互いに代わりを務める。
そんな物語を読むと、いつも心が荒んだ。
当時好きだった相手は、自分の事などこれっぽっちも興味が無かった。ように思う。
ただ、互いに必要だった時のみ連絡をとるという、慾望だけが繋がっていた。
そんな相手を思い出す。
きっと相手には、他に思う人も居て、自分はそれを埋めるだけなのだと
一緒にいるときにも、感じる。感じていた。
いつも、ただただ悔しかった。
行為のあとの虚しさの中で、消えない悔しさが腹の底に溜まっていた。
相手には、代わりである自分がいる。でも、自分には、代わりが居なかった。
いたとしても、頭の端で、いつも思い出していた。
そんなものが、ダラダラと3年だか4年だか続いていた。
ただ酒を煽って、欲を求めることがあっただけで、何も変わることはなかった。
均衡を破ったのは、恐らく自分だ。
確信が持てなかっただけで、予想をしてなかったわけではない。
だから、心の何処かで多分、納得していた。ああ、やっぱりか。って。
それからはもう、ただただ崩れていくだけだった。
誰かの代わりかもしれない、と
誰かの代わり、でする行為は、雲泥の差だった。
連絡を取るのをやめて、些細な興味に突き動かされることもやめた。
今でもまだ、忘れられない自分の未練たらしさに呆れながら、慰めることも少なくない。
当時はただ、異常な思考のまま、朦朧とした頭で、何も考えられていなかったのだろう。
今になってみれば、ただ弄ばれて、利用されていただけだっただろうに。
いや、利用していたのは、こちらも同じだったのだが。
なぜこんなことを、こんな所にツラツラと書き連ねているかといえば
アニメ化と新刊発売を控えた「クズの本懐」を読み返してしまったためだ。
誰を思って、何を思ってキスをしていたのか。
今更聞いたところで、何にも成れはしないけれど。
それでも止められなかった自分が浅ましくて
誰かに話したことは、あまりない。
それでも無性に、誰かに聞いてもらいたくなった。
長々と大変申し訳無い。
此処に記せば、当時好きだった相手の事を、少しでも昇華させられそうで
匿名の海に溺れてみたくなった深夜。
全てのクズに幸あれ。
