  |
はてなキーワード: フィッシングとは
○朝食：ヨーグルト
○調子
はややー。
明日水曜日の午前中に会議があるので、そこ次第で色々と変わるかも。
逆に、そこで僕が望む方向にがっちり決めれば、楽チンになるので、頑張りたい。
●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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
この文章はすごく長いです。ひまな時に読んでください。
わたしの小さい頃はインターネットなんてありませんでした。なので私は漫画を読んだりゲームをしたりして遊んでいました。それに比べて今の子供はとても幸せだなと思います。漫画やゲームに加えて、LINEで友達と会話し放題、ホームページは見放題、とてもうらやましいです。私がインターネットにはじめてつないだのは15歳の頃です。その頃は電話をかけてインターネットにつなげるため、接続している時間の分お金がかかりました。電話代を払う親に申し訳なくて、Yahooを開いただけですぐにやめました。インターネットで友だちと話すなんて当然できませんでした。繰り返しますが現代の子供がうらやましいです。
こんな便利なインターネットですが危険なこともあります。ミスをして、犯罪に巻き込まれたり、他人にけなされたり、恥ずかしい思いをしたり……私はそのような人を多く見てきました。こんなインターネットの世界ですが、所詮は人間が作った社会です。気をつけてほしいことはたくさんありますが、それらはあなたのお父さん、お母さん、先生から習うこととほとんど変わりありません。
外を出歩ければ交通事故にあうからといって、家にずっと引きこもっているのは間違いです。インターネットには悪い人がたくさんいますが、それは現実社会でも同じです。安全なインターネット生活を送るため、私はこれら6つのことを皆さんに伝えたいと思います。
いかがでしょうか。たった6つです。それでは始めます。
あなたも友達とけんかして、「ばか」だの「デブ」だの悪口をいうこともあるでしょう。それらは周りに誰もいなければ、誰にもわかりません。「○○君が、『バカ』って言った！！」と声を荒げても、ICレコーダーやスマートフォンで記録していない限り証拠はありません。
しかしインターネットは違います。あなたのメール、facebookやLINEに書き込んだ内容、ダウンロードした音楽など全て記録されています。携帯電話でもパソコンでも一緒です。
普通の人はその記録をみることはできませんが、警察は犯罪の疑いのある場合、見ることができます。また、ネット上の悪い人はその記録を見ようとして一生懸命になっています。インターネット業界の人は記録を見られないように必死で頑張っていますが、それでも悪い人に見られる場合があります。絶対に安全とはいえないのです。
あなたはLINEやFacebook, Twitterで悪口を書いたりしていないでしょうか。変なソフトをダウンロードしてないでしょうか。それらは全て記録されています。悪口をかいた記事を消しても無駄です。書いた記録は残りますし、消されたブログを見る方法があります。これはだれでも使えますし、別に犯罪ではありません。もしくは誰かが保存しているかもしれません。
学校やお家でネットしている時、i-フィルターというのを見たことがありますか？これは有名なソフトでみなさんに有害なソフトを見せないようにしています。このソフトを使えばお父さん、お母さん、先生がみなさんのネット利用状況を把握できます。Twitter, LINEであれば暗号化しているので書き込み内容は見られませんが、それでも何時間見たかとかは分かります。裏サイト、Yahooの検索など暗号化していない場合は何を書いたのか分かるかもしれません。
どうせ記録に残るなら、悪口ではなくもっと価値のある発言をしようとは思いませんか？
本当のことだからみんなに伝えたいと思うかもしれません。しかし社会には通用しません。本当のことでも名誉毀損罪（めいよきそん、他の人をばかにすること）は適用されます。もしみんなに伝えたいと思うならば、罪に問われるのを覚悟して伝えなければいけないのです。罪に問われなかったとしても、誰かを傷つけたりするかもしれません。送信ボタンを押す前に一度深呼吸して、内容を確認した方がいいです。
警察は人のものを盗んだり、人を傷つけたりした人を捕まえています。そして裁判を経て、場合によっては牢屋に入れたりします。そうやって世の中に悪いことをするひとを減らそうと努力しています。しかし警察も「悪いことをした人」を捕まえることはできても、「悪いことをしそうな人」を捕まえることができません。それは「悪いことをしそうな人」は別に何も悪くないからです。
パソコン、あるいはスマートフォンにはウイルスバスター、ノートンなどさまざまなウイルス対策ソフトが入っています。人によってはこのソフトを入れているから何をしても大丈夫だという人もいます。危険なことをどんどんしてもいいと考える人がいます。
大間違いです。警察の例で言うならば、ウイルス対策ソフトは「被害にあった人」のデータを集めて、「悪いことをした人」への対策をします。つまり、ウイルス対策ソフトは「最初に被害にあう人」を守ることはできません。また、「悪いことをしそうな人」へは何もすることができません。
あなたがその「最初に被害にあう人」になるかどうかは誰にもわかりません。世の中には交通事故に絶対合わない方法はありません。道路を渡るときにどんなに気をつけていても、車が自分に突っ込んでくればどうしようもないからです。だからといってあなたが信号無視をしてももっと危なくなるだけです。危険だと「分かっているなら」それはしないほうがいいのです。
大人は言います。「世の中にうまい話はあるわけがない」と。私はちょっと違う意見です。私は「世の中にうまい話はある、それは話をする人にいいことがあるからだ。」と考えています。
有料で売られているソフトを無料で配っている人があります。あるいはテレビ番組をYouTubeでみんなに見てもらいたいという人がいます。その人たちはどうしてそのようなことをするのでしょうか。
それはお金のためです。売っているものをただでくれるとなれば、だれでもよろこんで飛びつくに決まっています。彼らはそのようにして人を集めて、ウェブサイトに貼ってある広告でお金を稼いでいます。YouTubeでも再生数に応じてお金をもらうことが可能になりました。ヒカキンはそのようにしてお金を稼いでいます。
勘違いしないで欲しいのは、決まりさえ守れば無料のソフトを配ることには問題ないということです。有料のソフトを無料で配るのが良くないのです。また、悪い人はコンピュータウイルスを仕込むかもしれません。それはウイルス対策ソフトで防げないかもしれないのは2で説明したとおりです。
また、インターネットでお金を稼ぐことがけして悪いわけではありません。テレビ局に許可を得ず、勝手にYouTubeにアップするからダメなのです。ヒカキンは自分で作った動画を自分でアップしているので何の問題もありません。
テレビは無料で放送しているから、YouTubeでみんなに見てもらおうとするのは問題ないと思うかもしれません。しかし、それを決める権利はあなたにはありません。それは番組を制作したテレビ局が決めることです。
テレビ局はテレビ番組中にCMを入れることで、他の会社からお金をもらっています。最近はテレビ以外にも楽しいことがあるので、みんなはテレビを見なくなりました。なのでテレビ局がお金を稼ぐことは、昔と比べて難しくなりました。YouTubeに番組をアップしてお金を稼げるならばテレビ局はとっくにそうしています。彼らはいろいろお金の計算をして、アップしない判断をしているのです。テレビ番組はテレビ局のものであなたに番組をどうするか判断する権利はないのです。
ここまで読んでくれてありがとうございます。いくつか悪いことを紹介したましたが、それでもあなたはその悪いことを続けるかもしれません。
それはどうしようもありません。あなたとわたしは結局他人です。教えることはできても、悪いことをできないようにすることはできません。あなたを牢屋に一生閉じ込めればできることですが、そのようなことは私もあなたの父母も望んでいません。
深夜車がまったく通らない道路で信号無視することは法律違反です。しかし、実際に信号無視をするかどうかは個人が判断することです。誰もみんながやっているから、車が通らないからというのは言いわけであって、してもいい理由にはなりません。
重要なのは信号無視にしてもネットの悪口にしても「悪いと理解した上で」やって欲しいということです。知らなかったでは済まされないですし、遅いのです。大人ですら「悪いと理解した上で」やってる人は少ないです。
これまで散々「〜するな」と「危ない」とか言い続けてきまし。でもみなさんがネット上で何かするのが間違っているのではないか、とビビってしまうのは私の望むところではありません。
ニコニコ動画、Youtubeなどでどこからかとってきた音楽をそのまま使って動画をつくりアップするのはダメですが、自分で演奏した動画、その演奏に歌をつけた動画、初音ミクに曲を歌わせた動画は問題ありません。
学校の授業で動画などをつくることもあるでしょう。著作権法には教育目的であれば必要な分だけコピーすることができるとされています。有料ソフトをコピーするとかはダメです。例えば音楽を使いたいのであれば「誰の何という曲」という項目をきちんと表示してください。
ちなみに誰にもみせなければ漫画、映画、アニメ、音楽を好きに使って動画を作ることが出来ます。これは犯罪ではありません………誰にもみせなければですよ。
あなたは今お父さんやお母さんと一緒に暮らしていることでしょう。時にはケンカもするかもしれません。「お父さんはどうして僕の気持ちが分かってくれないんだろう。」と恨むこともあると思います。「お母さんは考え方が古い」とバカにすることもあるでしょう。
世の中の常識は時代が進むにつれて変わります。つまり今悪いと思われていることが、悪くなるかもしれません。5で「演奏した動画は問題ない」と書きましたが、これは「現時点」の話です。いろんな大人が話し合ってこのようなところに落ち着きました。
現代はあまりに世の中には著作権法その他の決まり事を無視しています。それは誰にも止められません。しかし、それは「今は」悪いことであるとまず認識して欲しいと思います。そしてみなさんがおとなになった時に法律や常識を変えるよう運動すべきです。インターネットは特別な世界ではありません。人間社会のうえに成り立っている社会です。ただ情報の共有コストがほぼ0なのです。
未来においては、今の常識は通用しないかもしれません。いままで気をつけたほうがいいことを書いて来ましたが、それでもどうなるか分かりません。一般、有名人問わず過去にやった犯罪をネットに書き込み、「炎上」するのはよくありますが、アメリカの大統領だってそのくらいの告白はします。このような欲求は人類共通のようです。
常識が変わるかどうかは未来になってみないとわかりません。それでも大人は変わらないもののために、今あなた方にいろんなことを教えているのです。
この文章はわたしの友達があまりにインターネットで危険なことをしているため、それを諌めるために書きました。世の中には初心者向けにインターネットセキュリティについて書かれた文章が山ほどあります。しかし、それらのほとんどすべてが技術論に偏っていました。しかし著作権だのフィッシングだのと言う前にもっと大切なことがあるのでは無いでしょうか。
インターネットの世界も技術の進歩が早く、いろんなことがどんどん変わっています。CDに入っている歌を無料でダウンロードして聞くことが、かならずしも著作権法違反であるとは言えない世の中です。何がだめで、何がよいのかというのも徐々に変わっています。信頼出来るドメインはどう判定するのか、2chまとめサイトは著作権法違法なのか、画像の転載はいいのか、短縮URLサービスは信じられるのか、
世の中は人を信じなければ渡っていけません。しかしどのような人、どのようなことを信じるのかは我々先達の教育にかかっています。そして結果どのようにするかは個人の判断に任されています。結果的に教えは間違っているかもしれません、しかしだからといって教えるのを放棄したのでは傷つく人が増えるだけです。教師か反面教師かは時代が決めることではないでしょうか。
小学校高学年程度にわかる文章のつもりで書きました。そのため「転び公妨」とか「ハッカーとクラッカーの違い」とか「ウイルス対策ソフトのヒューリスティック機能」とかいうツッコミはなしでお願いします。
他にも児童ポルノの問題など書ききれませんが、とりあえず6つだけで終わります。
http://twinavi.jp/topics/it/5593e714-5b0c-4b21-99f5-3f94ac133a21
やめてほしいなあ、と思う理由は次の３点。
事故や犯罪によって預金が不正に払戻されたとする。あまり知られていないのだけれど、このとき、預金者に明らかな過失がなかった場合には、損失額は銀行が補填する（預金保障規程という。ペイオフとは別物）。
明らかな過失というのは「普通やらんだろ」っていう内容のもので、例えば
で、会計簿アプリのケースも、自己責任でパスワード預けていたとすれば「預金者の明らかな過失」にほぼ該当すると思われるので、銀行側が損失補てんをする必要はない。その点の心配はない。
ただし預金者から補てん請求があったときに、「預金者に明らかな過失があった」ことを証明する義務は銀行側にある。大規模なデータ漏れなどの際に不正払戻しの被害が生じたら、当行預金者の被害者の存在確認と損失額の把握、預金者が「アプリ側にパスワード預けてた」ことの立証を書類にしていく必要があるのだけれど、正直、そんな面倒な仕事をさせないでくれ、と思う。そういうときに限って「銀行がアプリにデータ提供していたからいけないんだ」とか言い出すクレーマーも絶対現れるし。
ここまで書いて気がついたけど、そもそも乱数表＝取引パスワード≠ログインパスワードでしょ？データ閲覧のためだけなら乱数表データ不要なはずなのに、なんでそれ収集するのさ？
これだけフィッシングサイトに気をつけろって言っていても被害者は減らない。
アプリの画面に似せたフィッシングサイトが横行すれば（時間の問題だと思う）被害者は増加するだろう。上記とも関係するが、犯罪者に余計な知恵を付けさせないでくれ。
預金やクレジットカードの決済履歴は、その人の消費性向を如実に表す貴重なデータだ。
が透けて見える。銀行ではずいぶん前から、こういった過去のデータを分析してその人の消費性向にあった金融商品を高い精度で提案したい、という研究を進めている。銀行とすれば将来の商売の需要なネタが、他者に把握されるというのは極めて都合が悪い。やめてほしい。
～～～
もちろん預金者本人のデータを預金者がどう使おうと自由なわけだけれど、
こういう形でデータが外部に流れていくのは、所在なさというか心地悪さというか、気持ちの悪さを感じる。
そもそも、自分の中でも最もプライベートな情報をよく他所様のフォームにホイホイ入力しちゃうよなぁ、ってのが個人的な感想で。
Twitterで政治家になりすました人がフィッシングサイトを作って、そこに人々を誘導したら、誰かが引っかかりそうなもんだけど。
それ以前にネット選挙が解禁になってしまうとネットができないご老人たちから情報格差とかのバッシングが来そうだからまだまだ採用されないと思うけど。あと20年ぐらいしたら変わってくるんじゃないかな。
俺ならそんなサイトが出来たら即座に攻撃してサイト改ざんなりして、みんなの個人情報を抜き取るな。
そして、事態を重く見た政府によって出来たかと思えたネット選挙は即座に廃止、また紙の投票に戻る。
老人はあらゆることで有利なんだよ。老人の誰かにお金つまれたハッカーがやったら日本のセキュリティなんてちょちょいのちょいじゃねえか。
上みたいな反論が既に昔から何度も上がっているから未だに採用されないんだろ。
若者の考えとしては、1 賛成→選挙にいく 2 反対→選挙にいく 3 興味ない→選挙にいかない ってかんじ
それだけ大阪の未来なんてどうでもいいと思っている若者が多いってことさ。
なんせ、選挙にいくなんてダサいからな。自分の身の回りに「日曜どこいってた？」って聞かれて「選挙w」なんて言ったら「は？おっさんやんwだっさw」とか言われる。
県警でサイバー犯罪を担当している人から話を聞いた時のメモが出てきたので下記にまとめる。
メモは2年ほど前のもので、現在の警察の見解とは異なっている可能性がある。
S社でスマホを機種変更しに行ったら、、本当にひどかった。しかも１店舗目でこれはナイと思って、２店舗行ったら、どちらも同じだった。。
・これまで1GB/月も使っていないのにしきりに5GB/月以上のプランを進められた
その際、4G回線になると3G回線に比べて2~3倍の通信容量になるからと、あり得ないことを言われた...
・機種代と言って、勝手に15,000円分くらいの64GBのMicroSDカードを入れてきた
（機種代と言われた金額が明らかにディスプレイの表示金額と違ったので、理由を聞いたら初めて答えた…）
・機種変更前の携帯を普通に起動して中身が見られるように、という説明だけで新しいSIM（ゼロから定額）を契約させようとしてきた
・今入っているオプションを見直したいと言っても、中身を説明してくれないし、カタログ見るのをとても嫌がられた
・「今入ってるのはどういうオプションですか」と聞くと「セキュリティのためのもの」と言われて、
「具体的にはどういう機能ですか」と聞いても「セキュリティのため」と返答が来た
※すごく嫌な顔されたけどカタログ見せてもらった…
・「新しいセキュリティオプションがあるからそちらにしますか？」と言われて、
向こうから中身を説明してくれなかったので（かなりしぶられつつ）カタログ見せてもらうと、中身が全く別物だった。。
※今のプランが遠隔ロックや紛失時の探索サービスなのに比べて、
新しい方というのはブラウザアプリのようなもの起動してフィッシングサイトを検知するような感じ...
・プランごとに比較したいから金額の明細を出してくれと言ってもスルー
電卓はじいて金額表示するだけ、しかも実際はそれに＋でいろいろ付く...
他にも色々あった気もするけど、ざっとこんな感じ。
