  |
はてなキーワード: フィッシングとは
さっき突然ZOZOTOWNからメールが届いて、何かと思ったら会員登録完了のお知らせだった。
一瞬迷惑メールかと思ったが、どうも違うようだ。
最初の会員登録完了のメールには個人情報が記載されていなかったのだが、注文完了のメールには名前、住所と、当然ながら購入したものが記載されていた。
何が言いたいのかというと、僕は突然ZOZOTOWNの会員登録プロセスの不備により、見知らぬ人の個人情報を手に入れてしまったのだ。
通販サイトの会員登録プロセスは、入力したメールアドレス宛に会員登録用URLを送るものが一般的だと思っていたので、ZOZOTOWNのような大手通販サイトがこのようなサイト完結型の会員登録を行っていることに驚いた。
また、会員登録ミスの連絡をするにしても、個人情報に関する規約に同意した上で僕の個人情報を株式会社スタートトゥデイに提供しなければならないことから断念した。（フィッシングサイトである可能性が否定できないため）
スタートトゥデイの社員の方、このエントリーを見たら、5月2日0時6分にhから始まるメールアドレスで会員登録され、0時8分に衣服購入したアカウントを探して購入者に連絡してください。
○朝食：プリンどら焼き
○夕食：すがきや
○調子
はややー。
明日も、新人さん二人に色々教えつつ、来週の準備をするだけかな。
●DS
わーい、わーい。
とはいえ、攻略サイトを解禁すると、どうもクリア後の裏ダン的なので、もう5Fまであるらしい。
でも、これで終わりでいいかなあ。
DSの下画面に地図を書いてダンジョンをマッピングしていくところが、とにかく楽しかった。
ちなみに、キャラクタの名前は「〜〜〜百合」と百合の一種の名前になる繋がり。
・ヒメ（パラディン）
敵が力を貯めたり、いてつくはどう（的なのね）食らった直後などはフロントガード、
「チェイス」という、味方の属性攻撃に追撃を加える、攻撃力No1で、攻撃の要。
ただこの、味方の属性攻撃を挟まないと攻撃できないのが、若干回りくどくて、ピンチのときは稼働できないこともあった。
とはいえ、準備万端のときの全体術式＋チェイスは超攻撃力高くて、楽しかった。
・カノコ（バード）
自分かヒメに序曲で属性を付与して、コオニちゃんのチェイスの発火をさせるのが目的。
とはいえ、ヒメの防御陣形、ウケの医術防御で味方強化の枠が二つ埋まるので、攻撃力アップか、序曲かの二択になるのが面倒だった。
大体は、攻撃力アップ、防御陣形、医術防御をかけたあと、自分に攻撃力アップを外すように序曲をかけてた。
ぶっちゃけ、できることは色々あるのに、この強化枠三つのせいで、暇な時も多くて使いこなせなかった。
・ヤマ（アルケミスト）
大爆炎の術式、大氷嵐の術式、大雷嵐の術式、の三つを使い分けて全体攻撃を加える仕事の人。
敵が多い雑魚戦では便利だったけど、足が遅いからどうしても回復のTPも必要で完全作業にはできなかった。
あと、ラスボスやFOEみたいな単体で出てくる敵には、あまり効率が良くなくて、コオニのチェイス発火が目当てのことが多くて、TP節約のために最弱の呪文の火の術式を唱えることもよくあった。
・ウケ（メディック）
医術防御をかけたあとは、エリアキュアIIを連発するだけの簡単なお仕事のキャラ。
まじでやることがこの二つしかなくて、使ってて暇なキャラだった。
とはいえ、医術防御はかなり防御力がアップするし、エリアキュアIIはほぼほぼ全員が全回復だしで、強かったのは間違いなかった。
でも、道中のザコ敵では戦闘後の回復役って感じで、戦闘でなにもできないのが微妙。
こういう、キャラクタを育てるゲームは楽しかった、もうちょい感想を突き詰めたいな。
感想はそれはそれとして、次はどのゲームをプレイしようかなあ。
●3DS
普通にプレイ、すれちがいフィッシングの全島コンプがあと二島。
台確認のみ。
○ポケとる
・デイリー要素
をやっただけ。
デイリー要素のみ。
ログボのみ。
○朝食：なし
○昼食：おにぎり三つ（昆布、チーズおかか、七海キンピラマヨ）、豚汁、ベーコンエッグ、トマト、ブロッコリー
○調子
見たのは、僕は四度目ぐらいの視聴になる「セッション」という映画。
祖母がなにやら友人から勧められたらしく見たいと言うので、僕の家の近所でレンタルビデオを借りて着て、一緒に見た。
何度見ても面白いなー。
●DS
18Fをうろうろして、19Fに突入するも、ワープのせいでやたらとマッピングが難しい。
そろそろ、普段メインづかいしているスキルがカンストしだしたので、終わりが見えかけてきたかなあ。
●3DS
久々にプレイ。
ぼうしコンプと、ゲーム選択画面の金色マークのコンプが目標なんだけど、最近はなかなか進まない感じ。
残るのは、
・伝説（これなんで金色マークつかないかよくわからんから、IIの裏伝説10週をやってるけど5週以上は確定だけど、今何週かわからん）
・大砲忍者（5面のボス、6面ありそうだから先はまだ長いかな）
ぼうしチケットはあと三枚で、チケット交換できるぼうしはコンプ。
チケットは、フィッシングの他県とすれ違ったとき行ける島のクリアで二枚、
迷宮の一部屋全部埋めるで一枚の三枚の予定。
○ポケとる
90000ちょいぐらい溜まってるので、またメインステージをやっていこう。
目標の悪ポケコンプは、ダーテングやシザリガーがかなり先だから、まずはメインステージを進めることを優先してる感じ。
デイリー要素のみ。
ログボのみ。
○朝食：ヨーグルト
○夕食：オーシャンサラダ、キムチ、袋ラーメン、春巻き、ビール（二本）
○調子
はややー。
偉い人がインフルエンザらしく、来週の中頃まで仕事が停滞する。
ある程度先行してやっておいて、柔軟に対応する感じの準備をしてた。
明日は前に書いた、女の人と遊ぶ日です。
ただ緊張度合いがパないので、心を落ち着かせるために、ビールを二本も飲んだ。
はややー、頑張るぞー。
●DS
●3DS
フィッシングのすんでる県以外の人とすれ違わないといけない特別な島を一つ攻略。
あとその特別なのが二つと、日本国外の人とすれ違わないといけないのが一つなので、先は相当長い。
マニューラとドンカラスのドット絵バッジが実装されたけど、ドット絵の方のバッジは特に集めてないので、いつものあれの更新はまた今度。
シンオウのドット絵バッジが新しいカテゴリになったせいで、1000個制限がシャレにならなくなってる。
まあぶっちゃけ、リージョンフォームじゃない普通のベトベターとかベトベトンとかニャースとかペルシアンとかコラッタとかラッタとかは、悪ポケ扱いしなくてもいい気がするんだけど、
いましめフーパをずっと悪ポケ扱いして可愛がってたから、同じ理屈で、図鑑Noが同じポケモンは好きの対象にしちゃうんだよなあ。
○ポケとる
連勝もできない。
○朝食：なし
○夕食：ご飯、納豆（二つ）、減塩野菜たっぷり味噌汁（フリーズドライ）、豚肉炒め（久々に自炊した）
○調子
はややー。
まあでも、ストレスが溜まるからといって、どうこうするわけでもなく、いつも通り仕事を頑張った。
●DS
8Fを探索中。
危険な花びらに怯えながら、7Fと8Fの回復ポイントを行き来して7Fでレベル上げ。
その甲斐あってか、危険な花びらも編成しだいでは安定して倒せれるように。
そろそろ、次に進もうかな。
●3DS
久々に経過報告。
・スロットカー
クリア済。クリア後のやり込みはやる気ないので、最近は未プレイ。
・株トレーダー
クリア済。クリア後もプレイ中。目標の全アイテムコンプまで、あと二つ。あと50億ぐらい貯めれば終わる。
もうすぐクリアっぽいけど、二週目とかありそうだから、本当にクリアかどうかは不明。
3-2を攻略中。
何面まであるかわかんないけど、半分ぐらいは進んでるかな。
そこそこ楽しい。
・探検隊
雪山一つ目を終わらせた。
これも終わりそうだけど、二週目とかありそう。
・ガ〜デン
そろそろ、花を納品するところもクリアしていきたい。
・合戦
面白い、面白くない以前に、ただすれちがい人数を貯めるだけの時はただただ無なだけで、何もない。
・迷宮
22Fを攻略中。
楽しい、楽しい、楽しい、もー、ずっとこればっかりプレイしたい。
これも超楽しいけど、ゲームコインを大量に使わないと、クリア後の島は攻略できないので、停滞しそう。
でも、楽しい。
・ゾンビ
クリア済。
ぼうしチケット集め中、とはいえ残りはプレイ回数を重ねる系がほとんどなので、そろそろやめるかも。
クリア済。
ぼうしチケット集め中だけど、こちらは技術力をすごく求められるので、僕には難しいので、そろそろプレイをやめるかも。
台確認のみ。
○ポケとる
ほうせきが溜まってたので、コインに変換したら、コインがカンストに近い。
メガバンギラスはないと困ることがよくあったので、性能的にも欲しいし、悪ポケだからこそ欲しい。
けど、まだメインステージ310だから、100以上進めないといけないのか、うーーーーむ、めんどい。
ログボのみ。
○朝食：なし
○夕食：マクド
○調子
はややー。
今日は何事も起きない、至って平凡な1日でした。
そうえば書いてなかったですが、水曜日はちょっと病院の検査があるので、早退します。
なので気分的には明日火曜日行ったら、水曜日は午前中までなので、気楽な感じです。
●DS
8Fを探索中。
昨日、危険な花びらに全滅させられたせいで、回復ポイントを治すイベントをもう一度する羽目に。
●3DS
ひとまずスタッフロールは見た。
うわー、僕の中で「女の子同士が海を見る」ってシチュエーションが心にくるのか、大したことない薄いストーリーなのに感動してしまった。
スタッフロール後もまだまだ先は長いのでゆっくりプレイしていこう。
・株トレーダー
目標の100億を達成。
だいたい、あともう60億ぐらい稼げばアイテムも全部集まるので、頑張って行こー！
台確認のみ。
この間書いた通り、1000個制限があるので、悪ポケの新規追加以外は極力プレイを避ける方向でいきたい。
○ポケとる
悪ポケじゃないんだけど、リージョンフォームではあくタイプになるラッタ、
ログボのみ。
＞ Subject:お願いがあります
＞ To Masuda
＞ 添付のアドレスを打ち込んで
＞ 増田母宛に送ってほしいのです
120％、フィッシングだと思った。即、スパムフォルダに入れようとしたが、念のために母親に電話した。
そしたら、本物だった。びっくりした。
なんでも、高齢の知人から手紙をもらったのだが、そこにメールアドレスが書いてある。
そのアドレスを打ち込んでみたのだが、どうも数字の「7」がちがうような気がする。
「7」が打ち込めなくなってるみたいなので、息子に頼んだ、ということのようだ。
「それ、フォントの問題だから。セリフがないフォントで表示されてるだけだから」と説明してようやく納得してもらった。
ウチの親もパソコン使い始めて20年近くなるのに、なんだかなあと思った。最近はパソコンじゃなくてタブレットだから、文字入力の機会が減って、余計にこういうとこがわけわかんなくなってるのかもと、好意的にとっておこう。ボケたとは思いたくないし。
○朝食：ヨーグルト
○夕食：ご飯、納豆（二つ）、減塩野菜たっぷり味噌汁（フリーズドライ）、かぼちゃ豆腐コロッケ（かぼちゃよりコーンが多く入ってて詐欺られた感がした）
○調子
はややー。
帰り際に偉い人が訳のわからないことを言い出したので、ちかたなく残業して打ち合わせしながら色々検証。
疲れた。
打ち合わせに参加してる人全員が「これ無理じゃね？」と言い出す素敵な時間になったので、多分無理。
●DS
3Fを攻略中。
鹿や牛を倒せるようになったので、3FのFOEにも突撃するも、
なんとか、逃げることができたので、全滅は避けれたけど、
ちょっとこういう無茶は今後控えよう、少なくともセーブはしよう。
●3DS
昨日寝落ちしたせいで、充電できてなくて、家に置いてきてしまった。
こうなると、探検隊と合戦は進まないんだけど、すれ違い迷宮はめちゃくちゃ簡易に進められるから一長一短だなあ。
今は、すれ違いフィッシングに熱中したいから、ちゃんと持ち歩きたい。
ログボのみ。
○ポケとる
何気に、すれちがいや購入ボーナスで溜まったホウセキがそこそこあるので、週末はウィークエンドショップでライフが一時的にブーストされるアイテムを使って、メインステージを攻略するのもいいかも。
○朝食：ヨーグルト
○夕食：ご飯、納豆（二つ）、減塩野菜たっぷり味噌汁（フリーズドライ）、ツナ缶、しうまい
○調子
できるとかできないとかじゃなくて、一緒に仕事してる人とウマが合わない感じ。
まあ、この人と仕事するのは来週いっぱいまでだから、適当にいなして、適当に時が過ぎ去るのを待とう。
こういうときに、無理してわかりあおうとか、無理して理解しようとか、無理して理解してもらおうとか、気負いすぎるのが僕の良くない癖なので、ちゃんと相手を理解できないことと、相手が僕を理解してくれない、ということを理解してあくまで程よい距離感で適度にこなそう。
●DS
2Fを攻略中。
ちょっとよくわかってなかったんだけど、アリアドネの糸ってアイテムを使うとダンジョンの中からイキナリ街に戻ってこれることに気づいた。
おお、これ、すごい楽だな。
今までは、もどり道のことも考えてリソースを配分してたんだけど、これからは少し突っ張っても問題ないわけだ。
そこで覚えさせた、バードっていう歌を歌ってサポートする職業につかせたカノコちゃんの「氷劇の序曲」というスキルが超強い。
これは、通常攻撃に属性ダメージを追加するスキルなんだけど、サポート専門のバードにもかかわらず、このスキルを使えば使ってない戦士的な職業のソードマンと同等の攻撃力になる。
もちろん、攻撃力がもともと高いソードマンに使えばより一層強くなる。
今まで、アルケミストのヤマちゃんと、ソードマンのコオニちゃん以外は、ダメージがしょぼかったんだけど、このスキルでサポートすればそこそこには戦えるようになった。
そんなわけで、この間ボコボコにされた中ボス的な鹿に再チャレンジ！
パーティーの五人中三人が死ぬという激戦ながらも、なんとか撃破。
ボロボロになってもアリアドネの糸で戻れるので、点在してる鹿や牛と戦いまくって、レベルをあげた。
そろそろ2Fも終わりっぽいので、3Fの攻略を目指そう。
●3DS
楽しいんだけど、1日にプレイできる回数が決まってるのがもどかしくて、むずむずする。
ログボのみ。
○ポケとる
・ポケモンサファリ攻略中（コイキング（いろちがい）、ギャラドス（いろちがい）、ユキワラシ（ウィンク）、の4匹を捕獲。昨日はシェルダー、オニゴーリ（ウィンク）、マメパト、ハトーボー、ケンホロウを捕獲してるので、残りはパルシェンのみ）
今回のサファリのレア枠の金色コイキングや赤色ギャラドスは、メガ進化のメガギャラドスが本編ではあくタイプなこともあり、僕の愛好対象として絶対捕獲したかったので、捕獲できてよかった、よかった。
残りのパルシェン、そもそもまだ遭遇すらしてない。
ログボのみ。
○朝食：なし
○昼食：そば
○調子
詳細は次の○で。
早起きしてまで、遊びまくったのは久々だったので、ちょっと疲れた。
明日からまたお仕事が月から金まであるので、この日記を投稿したら、さっさと寝ようと思う。
積みゲーがひどい。
今世代機はもちろんのことながら、前世代機や前々世代機の積みゲーすらも結構ある。
っていうか、スイッチを携帯機と捉え、スコルピオも世代交代という捉え方をしてしまうと、前々々世代機（GBA、旧箱）にもうすぐなる積みゲーなんです。
ここで、今までのゲーム日記を振り返ると、実は意外と「プレイし始める」と、毎日プレイするんですよ。
ただ、この「プレイし始め」までが長い。
これはもう自分の中ではっきりと理由がわかってて「下調べ」をしようとするから、ダメなんです。
やれ、ツイッターの反応だ、やれブログの反応だ、やれAmazonレビューだ。
そういうのをクタクタと読んでは「ああ、ここがしんどそうだから、やめとこ」だの「えー、この仕様びみょー」だのと、プレイもせずに、些細な点が気になってプレイできていない。
そのくせ、一週間ぐらいたつと「へー、面白いっていう人もいるんだー」と今度は良い評判ばかりを集めて、自分もプレイしたいと思いつく。
だのに、結局最初の、悪評集めになぜか戻って、また「プレイしない理由探し」を始める。
もう、うんざりだ！
楽しくないなら、楽しくないで、プレイして、その上で「合わなかった」「僕には面白くなかった」と、自分の中で納得しないと、積みゲーは減らないんですよ！
いつまでたっても、自分の言葉でゲームを評せないから、いつまでたっても、積みゲーとしてせこせことゲーム棚に物を積み上げるんですよ！
というわけで、今日は「1日5本せめて電源だけでも……」と題して、とにかく、あーだこーだ言わず、ゲームを次々プレイしていきます。
それぞれの○の最後に、今後も継続してプレイしていきたい度合いを五段階で評価していくけど、これは自分で自分のことを忘れがちな自分のための指標であって、他人へのオススメ度合いとかでは決してないです。
●GBA
マリオとルイージの二人を操作するのが特徴的なアクションRPG。
マリオらしい「ジャンプアクション」を、RPGの戦闘シーンに落とし込んでる感じ。
「ブラザーアタック」っていう、他のゲームでいう「特技」とか「必殺技」とか「スキル」に当たる攻撃が、
マリオとルイージのコンビの動きに合わせて、マリオの動作ならAを、ルイージの動作ならBを、タイミングよく押さないと、威力が出ない。
これがやたらと難しい。
一応、難易度を自分で決めれて、最低難易度にするとボタンを押下するタイミングでスローモーになる、どのボタンを押すのか表示される、とさすがの僕でも技を決められるんだけど、どうも、この最低難易度だと通常攻撃にちょっと色がついた程度で、なんだかなあ、な感じ。
アクションの比重が思いの外大きかったのが、ちょっと微妙な感じでした。
●DS
シリーズがナンバリングが5作、リメイクが2作、コラボ的な作品もいくつかと、めちゃくちゃ大人気のダンジョンRPG。
特徴的なのは、DSの下画面を使って、自分のマップを書いていくところ。
キャラメイクをするタイプのゲームなので、僕のパーティーを紹介すると、
・ヒメ（パラディン）
・ヤマ（アルケミスト）：炎を育成
・ウケ（メディック）
・カノコ（バード）
こんな感じ、ソードマンとアルケミストは育成の方針で色々変わるっぽいので、それも記載。
今日は、2時間ほどプレイして、プレイ状況は1Fのイベントをこなして、2Fに降りて少し探索し。
これは楽しい。
ダンジョンRPGは、GBのWiz外伝と、PCゲーをいくつかプレイしたことがあるぐらいだったので、久々のジャンルへの手探り感が楽しいのがまず一つと。
「え、なにこれ、設定ミスじゃね？」と思うぐらいの大ダメージを敵全体に与えられるのが、最高に気持ちいい。
TP（マジックポイント的なの）的に1発しか打てないのも、「必殺技」感が出てて、超楽しい。
最高ランクじゃないのは、戦闘演出の間延び感が早くもすることかな。
スキルならまだしも、通常攻撃の演出がもっさりしてて、ひたすら敵を倒したりする段階になったときに、面倒そう。
●3DS
ヴァンガード自体は、漫画版やアニメ版を少し見たり読んだりしたことがあるだけで、TCGとしてのゲーム性は全く知らない。
が、最初の1時間はチュートリアルと、最初にもらう構築済みデッキをどれにするか考えてただけで、実際に対戦部分をプレイしたのは2時間程度。
今使っているクラン（MTGでいう色、遊戯王でいうカテゴリ的なもの）は「オラクルシンクタンク」
色々あるなかでこのクランにしたのは、このクランの特徴が「ドロー」にあるです。
一時期、ポケモンカードにハマってて、この日記でもよく店舗大会に参加したことを書いてたと思うんですが、
ポケカの何が楽しいって、7枚ドローとか6枚ドローとかを毎ターンのように唱えられるんですよ、これがとにかく気持ち良かった。
そんな、ドロー好きなので、ヴァンガードでも、ドローが得意なオラクルシンクタンクにしました。
何戦かプレイしてその中でも気に入ったのが「バトルシスター ふろまーじゅ」ってカード。
ヴァンガードを知らない人にも伝わるように書くと、ライフがピンチのときに仲間を揃えると2枚ドローして、攻撃力がパンプするってカード。
あと、これはグレード3の共通効果でふろまーじゅ特有ってわけじゃないんだけど、攻撃時にも2枚引けるので、もーとにかく気持ちいい。
面白いは面白いんだけど、ストーリーとかは特にないみたいだし、なによりTCGのデジタルゲームって、CPUに手加減してもらわないと毎回毎回ガチでやり合わないといけないから、ちょっと疲れるんだよねえ。
村長になって、村を大きくしたり、大きくしなかったりする、スローライフ系のゲーム。
ネットのみんなが「しずえさんかわいい」「しずえさんかわいい」っていうから、どんなもんかいな？ と構えてたけど、
確かに可愛いね。
これは、人気が出るわけだ。
ゲーム的には、1時間ほどプレイして、まだ家ができてないのでテント暮らしをしてる。
まだ、村長の仕事も木を植えただけだし、そもそもシステムが全部解放されてない感じ。
スローライフゲームだけあって、毎日少しずつプレイするものなんだろう。
ゲームとしては楽しいと思うんだけど、釣りはすれちがいフィッシングしてるし、作物育てるのはすれちがいガーデンしてるし、って感じで今プレイしてる他のゲームと、若干被ってる感があるのが、やる気が削がれた。
●iOS
○LaraCroftGO
うーむ、なんか、iPadminiとの相性が悪いみたいで、カクカクするし、しまいにはアプリが落ちるので、新しいiPhoneの方でやろうと思う。
が、iPhoneの空き容量がないので、音楽を厳選したり、いらないファイルを削除したり、とスマホの整理に熱中してしまった。
ま、まあ、電源はつけたから、よしとしてほしい。
プレイ継続したい度合いは判定不可能、また次のこの企画の開催まで持ち越します。
○いつもの
ログボのみなんだけど、これを書くようにしないと、ログボをとることすら忘れちゃうんだよね。
●3DS
お弁当屋さんに行くまでに一応持ち歩いたけど、さすがに人通りが少ないところなので誰ともすれ違えなかった。
セルフすれちがいをすればいいんだけど、なんかやる気が出ないので、今日は未プレイ。
ログボのみ。
○ポケとる
ログボのみ
ログボのみ。
○朝食：きしめん
○調子
はややー。
休日はややーなので、洗濯したり、掃除したりしたあと、日の光を浴びたくてブラブラ散歩してた。
なんだけど、寒いし、あんまり太陽照ってないしで、散歩が不完全燃焼だった。
やっと、年明けいきなりの嫌なことも振り切ったし、風邪も治ったし、明日こそ前言ってた
●XboxOne
○HaloWars2
さすがに、こういうルールが色々ある難しいゲームのチュートリアルをスマホ片手に翻訳しながらプレイするのは辛いので、製品版購入後におまけを貰える権利だけもらってアンインストール。
●3DS
一応補足すると、ゲームコインは3DSを持って歩くとたまる、本体に依存したゲーム内通貨で、対応してるゲームなら何にでも使える、ゲームを有利に進められる要素。
で、1日10枚最大300枚まで貯められて、今日はその300枚を全て使い切った。
全てを投入したのは、僕が今一番きゃわわきゃわわ、と思っている女性キャラクタ「コペラ」が登場する「すれちがいフィッシング」
釣って、釣って、釣りまくって、幻の魚を新たに二匹ゲット。
これで合計三匹ゲットしたので、残るは二匹。
ふひひ、楽しい。
けど、この楽しいゲームを満喫できるのが、次は30日後ってのが、口さみしい。
本体の日付をリセットすれば、ゲームコインは貯められるんだけど、そこまでするのもなあ。
ログボのみ。
バッジケースの枠が残り12個しかないので、ちょっと手に入れるバッジを当面は悩もう。
普通絵でさっさと揃えてくれれば、ドット絵の枠を外すから余裕が出るんだけどなあ。
○ポケとる
メガヘルガーのランキングイベントは、明日の夜にでもやろうかなあ。
目標は、メガスキルアップを一つ欲しいんだけど、まあメガストーンだけでもいいや。
ログボのみ。
○朝食：ヨーグルト
○調子
はややー。
明日水曜日の午前中に会議があるので、そこ次第で色々と変わるかも。
逆に、そこで僕が望む方向にがっちり決めれば、楽チンになるので、頑張りたい。
●3DS
それぞれプレイ中。
・サクッと！ スロットカー
EXは無視ってるけど、正直あんまりゲームとして好きじゃないので、ぼうし貰うぐらいまででやめる予定。
・サクッと！ 株トレーダー
46億円。
目標の100億は遠い上に、100億いっても目標のアイテムコンプはできないので、当分遊べそう。
半分もいってないけど、なかなか楽しいので遊び続けたい。
先は長いのでゆっくり遊びたい、女の子可愛いからプレイしてて楽しいし。
・サクっと！ 探検隊
このゲームあまり好きじゃない、歩数多い人とすれ違うだけで、特に遊びの要素がないし、秘宝とか動物の写真集めるのにモチベーションがわかない。
・すれちがいシューティング
4-2までクリア。
面白いんだけど、これだけガチにゲームをプレイするので、ついついプレイしないときもあったりする。
やることは単純なんだけど、お花を集めるのが単純に楽しいし、サポート役の男の人が格好良いので楽しい。
・すれちがい合戦
いや、その、ほっとんどプレイしてないです。
・すれちがい迷宮
7Fを攻略中。
これがゲームとしてもローグライクな感じで一番楽しいんだけど、一番可愛い助手のシラベールちゃんが出てこないのが心底不満。
シラベールちゃんといちゃつきたい。
・すれちがいフィッシング
ゲームとしては普通な釣りゲーだけど、ガイドさんとイチャつけるから、こっちの方が好き。
・すれちがいゾンビ
こういうアクションゲーム苦手なんだけど、1ステージが短いから、気楽にできて楽しい。
ログボのみ。
○ポケとる
メガスキルアップが今18個なので、頑張ってセレビィを50まであげ、19個にして
メガレックウザを完成させたいところ。
ログボのみ。
○朝食：野菜ジュース
○調子
はややー。
なんか、めちゃくちゃシンドくて、ヘトヘトになってしまった。
土日はお休みなので、ゆっくり休みたいので、お酒を飲んで脳みそをゆるくしておいた。
●3DS
色々プレイ。
すれちがいフィッシングが一つ目の島を攻略したんだけど、コペラちゃんと良い感じのストーリーがあって、
ポケモンサンでも思ったけど、女の子と女の子が夜に海の見える場所にいるのが、僕の心のスイッチを強く押すようだ。
ログボのみ。
なんだけど、ホウエンのドット絵バッジがきてるねー、台コンプぐらいはするかも。
○ポケとる
良い加減、530コインを狙う構成にしようと思い試行錯誤したが、めんどいなこの作業。
僕には向いてないわ。
ログボのみ。
○夕食：ご飯、納豆（二つ）、シーチキン、減塩野菜たっぷり味噌汁
○調子
はややー。
ゲームするって言ったけど、思いの外まだしんどくて、そんなにたくさんはできなかった。
っていうか、すれちがいとポケとるだけで、全然新しいゲームはできなかった。
明日から仕事初めですが、水曜日と木曜日と金曜日の三日間行けば、三連休なので。
気楽に、のらーりくらーりとやっていこうと思います。
●3DS
・伝説II
さすがに飽きてるので、ゲームコインを150枚ほど使って、ぼうしをコンプリート。
お知らせコンプは興味ないのでやりません。
ただ、さすがに150枚は使いすぎた感があるね。
・スロットカー
いわゆるキッチン系ゲーム（制限時間内に客が望む料理を作る系のPCのフリーゲーでよくあるやつ）かな？ と思ったら全然違うゲームだった。
すれ違った人から食料をもらって、それを元にいろんな組み合わせの料理をしていくゲーム。
すれ違いのパターンでいろんな食材を組み合わせられる的な感じかな、勇者にご飯を食べさせて、その勇者の冒険の報告が新聞で読めるってフレバー部分が気に入った。
すれ違った忍者を上手く大砲の軌道上に配置して連鎖させるゲーム。
これもまたシンプルだけど、ゲーム中に登場するくノ一の「シノビ」ちゃんが、超絶可愛いのでプレイ意欲がグビグビ湧いてきた。
下品な言い方をすると、スケベブックに出てきそうなキャラだ……
・探検隊
これはちょっと特殊で、すれ違った人の「歩数」を使って冒険をするゲーム。
うーむ、すれちがい要因の3DS3台を持ち歩くのはさすがに面倒なので、このゲームはゆったり進行になりそうだ。
釣りゲー。
コペラちゃんが可愛すぎる。上で、シノビちゃんきゃわわって書いたけど、この子も負けず劣らず可愛い。
……今年はあれだな「ゲーム日記色々アワード」を作るので、それの可愛い女の子部門にノミネートさせておこう。
・ゾンビ
いや、無双ゲーっていうかベルトアクション3D風味じゃね？ とか言われそうだけど、いまいちこういうジャンルのゲームってやらないから、ジャンル名がよくわかんないや。
これは素直にプレイしてて楽しい系だね、ストーリーもあるみたいだし楽しめそう。
全方位ちっくなシューティング。
今までのミニゲームから一転して、かなりのガチシューティングだな。
シューティング苦手で、ゴリ押しできなさそうだから、若干不安かも。
・ガーデン
花を育てるゲーム。
進めると、タネを交配するシステムもありそうな感じ。
ちょっとすれ違っただけじゃ、よくわかんないや。
・合戦
じゃんけんゲー？
うーん？ ほら、僕ってチュンソフ党員じゃないですか……
今やもうスパチュンだから別にいいんだけど、あんまり罵倒したくないので、ちょっとこのゲームの詳細な感想は控えます。
・迷宮
ちょっと今までプレイしたことがないゲーム性だから、いまいちジャンルがわかんないや。
すれちがいでもらったピースを、上手くダンジョンに当てはめると、プレイヤーが進んで行くんだけど、ランダム要素ましましってノリ。
この中で一番「凝ってる」感じがして、楽しいな。
上で、シノビちゃんやらコペラちゃんが可愛いとか書いたけど、ベルちゃんがダントツに好きですね。
今年はこの可愛い子ちゃん三人を愛でていこうと思う。
ログボのみ。
○ポケとる
とイベント系をこなした。
いや、ボーマンダは普通にメインステージでもよかったんだけど、いまいちわかってなかった。
ログボのみ。
たとえばこのコンテンツの中の一つ「不適切な表示に関連したコンテンツ」の例として
虚偽表示や不明瞭な表現でユーザーをコンテンツに誘導するページ（偽の記事を本物のように見せかけるなど）
虚偽、不正、または誇大な主張によってコンテンツや商品、サービスを宣伝するページ（「一攫千金」の情報など）
別の個人や組織、商品、サービスとの提携関係があるか、別の個人や組織からの承認を得ているかのように示唆する虚偽表示のあるページ
今回のWELQがやったことというのはまさにこれなのではないのだろうか。虚偽や誇大な主張でコンテンツを宣伝し、GoogleAdSenseを含むアフィリエイトサイトへと誘導したこと。これこそGoogle AdSenseの禁止しているものではないのか。
gmail.comに対してgmai.comやgmail.coを取って、フィッシングをしたり、
で、タイポやcoドメインは既知だと思うんだけど、co.jpに対して
hoge.co.jpに対してhogeco.jpを取る方法はあまり使われてない。(neでもgoでも同じ)
海外大手は軒並み取られてる.coも、日本系だと結構空いてる。
でも既に取られている類似ドメインもあり、誤送信したメールはそこに吸い込まれてる。
実際に奇跡的にまだ空いてたexciteco.jpには大量に誤送信が来てて、結構誤送信はある模様。
例えばxxx@hatenane.jpにメールを送るとvalue-domainのメールサーバに届く模様。これはてなじゃないよね？
で、これに気付いて、co.jpドメインの持ち主全員に連絡するのも無理だなあ、ということでJPRSに連絡してみた。
が、電話番号教えないと注意喚起はできないと拒否され、黙っていても気付かれずに被害が増えるだけなので、
ここで公開することにした。
ついでに言うとセカンドレベルが取れるccTLDみんな同じなので、教えておいて下さい。
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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
