  |
はてなキーワード: oauthとは
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
で、両方引っかかった。
また、両者のセキュリティーリスクはさほど高くないと思ってる。
のよう認識している。
自分の中で気を付けるべき行為だと思ってる行為としては、下記のような感じ。
他の人は、どの辺をリスクだと思って、何を気を付けているか気になった次第。
■補足
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く 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 (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
アーリーアダプターを自称する私がFacebookを始めたのは2011年の秋。
その頃は知り合いも全然いなくて、見知らぬ中国人のアカウントから友達申請が来た時に、友達の候補が中国人だらけになったのは懐かしい思い出だ。
知り合いも少ない中ちょびちょびと投稿する日々が続いた。
しかし今は私のFacebookアカウントはもはやOAuthのためのアカウントに成り果ててしまった。Google+も同様。
もはや何も投稿しなくなった。掲載したいと思うような私生活がない。「いいね」もいらない。コメントもいらない。
自分の誕生日は非公開にした。Facebookで誕生日を祝われたくない。コメントを返すのが面倒。
それから他人の誕生日の通知もやめた。興味のない人の誕生日の通知はいらない。
加えて、顔写真の「タグ付け」も拒否するようにした。自分の顔をマウスのカーソルでクリックされるなんて不愉快極まりない。絵踏じゃないんだから。
ちなみにFacebookと同時期にアカウントを取得したTwitterだが、こちらはちょびちょびととぅぶやきを続けている。
ツイッターアカウントを作りました。 → 凍結されましたｗｗｗｗ
ツイッターを久しぶりに始めました。
昔よりUIが変わってしっかり動作してる！
twiiter API 1.1 を調べて
1人だけというのはツイッターから怒られないようにするためと、
怒られない程度はcronで調整すればいいや。。と思って。(´･_･`)
require_once("twitteroauth.php"); // ------------------------------------------------------------------------- // love2av_info // ------------------------------------------------------------------------- $consumerKey = ""; $consumerSecret = ""; $accessToken = ""; $accessTokenSecret = ""; $oAuth = new TwitterOAuth($consumerKey, $consumerSecret, $accessToken, $accessTokenSecret); $q = "抽出するつぶやき"; // 指定語が含まれるつぶやきを検索 $tweets = $oAuth->get('search/tweets', array("q" => $q)); // ツイート一覧からID一覧を取得 $arrayIds = array(); foreach ($tweets->statuses as $tweet) { $arrayTmp[] = $tweet->user->id; } // そのID一覧と自分の関係を取得 $users = $oAuth->get('friendships/lookup', array("user_id" => implode(",", $arrayTmp))); // フォローしていないIDだけを抜き出して配列に格納する $arrayNotYetFollow = array(); foreach ($users as $user) { if (!in_array("following", $user->connections)) { $arrayNotYetFollow[] = $user->id; } } // 検索したツイートを調査する foreach ($tweets->statuses as $tweet) { // botっぽいのは除外する if (strpos($tweet->user->description, "bot" !== false)) { continue; } // フォローしていなければフォローする if (in_array($tweet->user->id, $arrayNotYetFollow)) { $oAuth->post('friendships/create', array("user_id" => $tweet->user->id)); // 1回の起動で 1人だけフォローする break; } }
これを
php -f this.php
みたいな感じに cron に登録すると、起動する毎に 1人フォローが増えます。
フォロワーは増えないけどね (´･_･`)
ツイッターめっちゃ厳しくなってるじゃないですか Σ(°□°;)
僕もいくつかWEBサービスを作ってきたので分かるのですが
収益をアフィリエイト広告であげようとしているWEBサービスは相当なアクセスがないと全く儲からないです。
少なくとも継続して1日あたり数千アクセスないと厳しいかなと思います。内容にもよるかもしれませんが。
僕が運営しているエロいWEBサービスの１つだとけっこうアクセスはあるのですが月間の利益はせいぜい３、４千円。
制作に費やした時間、学習コストを考えるとコンビニでアルバイトでもした方が何十倍も稼げるレベル。
http://anond.hatelabo.jp/20130124122021
この日記の人も書いているけど特にはてな経由のアクセスからは売り上げは全く上がらないと思います。
だから、これからWEBサービスを作ろうと思っている人に言いたい。
利益を得ることを目的にWEBサービスを作るというのは間違っていないと思うけれど
アフィリエイト広告を収益モデルとした場合、悲しい結末が待っている可能性が高いです。
それでもWEBサービスが作りたいんだ！
そんな熱い気持ちで作ってほしいです。
もし、WEBサービスで沢山のアクセスを集めることができたなら
例1）はてな経由やニュースサイトなどに取り上げられ爆発的なアクセスがあった場合 1、ベンチマークテストなどでは得られない生の負荷が経験できます。 ↓ 2、想定外のアクセスにあわわわわわ状態になります。 ↓ 3、アラートメールがしこたま来ます。 ↓ 4、サイトが表示されなくなります。 ↓ 5、パニックになりながらもsshでサーバーに接続して原因を調べようとします。 ↓ 6、sshでサーバーに接続できない状態に呆然とします。 ↓ 7、気持ちを落ち着かせるためXVIDEOSに行きます。 ↓ 8、賢者になります。 ↓ 9、再度サーバーに接続します。重いながらなんとか接続に成功します。 ↓ 10、TOPで探ります。 ↓ 11、いろいろ調整します。場合によってはサーバーを上位プランに変更します。 ↓ 12、トラブルを乗り越え落ち着きます。 ↓ 13、FC2アダルトに行きます。 ↓ 14、大賢者になります。 ↓ 15、おもむろにメーラーを起動します ↓ 16、件名：** PROBLEM Service Alert ↓ 17、ふぁああぁあぁぁぁあぁぁぁぁぁぁぁぁぁ ）゜д゜（
例2）自分の作ったサービスに対するなんらかのアクションがある（特にはてな経由の場合）
見ず知らずの人からメールやらコメントやらがもらえます。 ・すごくいい ・すげー ・便利 ・無言ブクマ ・俺もこんなの作りたい ・後で試す ・使えない ・しね ・ゴミ
など、悦に入ることができたり、精神的なダメージを受けたりします。
http://razokulover.hateblo.jp/entry/2013/01/23/220418
WEBサービスで得られたわずかなアフィリエイト収入を使ってアドワーズで彼女を募集したら
例4）話題になることで色んな人と仲良くなれたりします。
人脈ができて素晴らしいことになります。
※
どうです？けっこうすごくないですか？
特に例3が！
WEBサービスってすごいんです！
こんな素敵な経験ができるかもしれないんです。
彼女が欲しい！
僕は彼女が欲しいんだ！
ではどうやって彼女を作るか？
・
・・
そんなわけで一生懸命作ってみました。
サイト名：nweet
・どんなサイトか？
お気に入りのエロ動画をブックマークしているとサイドバーに表示しているブックマーク欄が肥大化しすぎてうざい
そんな人におすすめです。
XVIDEOS、FC2アダルト、RedTubeでまた見たいと思った動画再生ページのURLをツイートしておけば
後でnweetにログインするだけでツイートした動画を直近100件のツイートから抽出しブログ化します。
埋め込みプレイヤー表示可能な物はサイト内でプレイヤー表示しています。
ツイートした動画からキーワード検索可能。お気に入り機能あり。スマホ対応。
・使い方
例）XVIDEOSの場合
XVIDEOSの動画再生ページにはツイッターボタンがついてます。
share→ツイッターマークを選んでクリック→再生ページのURLが入力されているツイートボックスが表示されるのでそのままツイート
動画を分類したい場合はハッシュタグをつけてツイート（#巨乳 など）
後はnweetにログインするだけ
一瞬でブログ化完了です。
nweetではツイッターのOAuthを利用したログイン機能を実装しています。
で、作ってから気付いたんです。
てか、女の子がエロサービスってほとんど使わないじゃん！？意味がね～！！！！
う～ん・・・
・
・・
サイト名：atodemiru
機能的にはnweetと同じです。
抽出対象URLはyoutube、ニコニコ動画、FC2動画、Nosub、B9DM、anitube、Dailymotion、veoh、pandora、56.com、clip.vnとなっています。
同じく直近100件のツイートの中から上記の動画再生ページのURLを含むツイートを抽出しブログ化します。
これで、もう彼女ができたも同然です！
アドワーズ男の早川さんに続く伝説、WEBサービス男の幕開けになるはずです！
とここまできて、冷静になったんですが
応募する人って変な人しかいないんじゃないのか？
まあ、おっさんなのにこんなWEBサービス作ってる僕の方が相当あれですがｗ
そんなわけで、ひっそりとカムフラージュして募集しようかと思います。
ええ、本当はこの年でこんなことしてるのが恥ずかしい。
こんなことして許されるのはせいぜい大学生くらいまでだ。
見つけた～！！！といういう女子（20歳以上）の方は応募してみないか？
さて、長くなりましたが
サイト名：nweet
サイト名：atodemiru
良かったら使ってみてね。
このサイトの技術的なことに興味ある方はこちらをご覧下さい。ツイッターもやってるんでフォローしてね。
http://nante.hatenablog.com/entry/2013/03/14/144250
それでもWEBサービスが作りたいんだ！
と思っています。
目標としてはとりあえず新しそうなことをやってみるということで作りました。
作ったサイトは２つ。
「えっちなハイ！ムービー」（通常のアダルト動画サイト）
「えっちなハイ！ムービー in tumblr」（えっちなハイ！ムービーのtumblr bot）
えっちなハイ！ムービー in tumblrはbot作りに挑戦してみたのとtumblrでの動画の配信を試してみました。
といったところです。
自分が知らなかっただけかもしれませんが、
比較的目新しかったのはtwitterのbootstrapで、
これでcss周りがだいぶ楽になりました。
前にも使っていて割とすぐに実装できそうだったので作りました。
絞り込みで使っています。
フレームワークのcodeigniterは特に本を買ったりするわけでもなく
手順に何通りもバリエーションがあるというわけではないので
なんとかなりました。
今回は仕事などで得た知識や経験のまとめとして一人でどこまで作れそうかやってみました。
今後もまた思いついたものをちょくちょく作ってみたいと思います。
Twitterの@logoutははまちちゃん(ぼくはまちちゃん！)なのではないかと思われる。なぜかというと、このアカウントで「こんにちはこんにちは！」と発言しており(以下のURLから確認できる)、名前が「Hamachiya2」となっているからである。
https://twitter.com/logout/status/85500046010884096
このアカウントで呟かれている内容の全貌が気になるかもしれないが、それを確認するために以下のURLにアクセスしても無駄である。
普通のPCから普通のWebブラウザを使って上のURLにアクセスしても、@logoutの発言内容は表示されず、代わりに「Twitterからログアウトしますか？」と表示される。これではダメだ。
@logoutの発言内容を確認するには、例えばTogetterを介せばいい。
どうしてこのアカウントのお話をしているのかというと、iPadのSafariの場合は上に示した挙動にならないからである。http://twitter.com/logout にアクセスすると、ログアウト確認ではなく、@logoutの発言内容が表示される。
これが問題になるのは、TwitterのOAuth認証に依存しており、頻繁にユーザを変更するWebサービスを開発した時である。
ご存知の通り、TwitterのOAuthを認証の代わりに使用するWebサービスにログインする場合、まずTwitterそのものにログインしなければならない。OAuthは「このWebサービスに、あなた名義でTwitterのAPIを叩く権利を与えますか？」と訊きにくるのが肝であるから、当然ながら「あなた」名義で予めログインし、OAuthに訊かれる前にTwitter(と自分のWebブラウザ)に「あなた」とは誰かを教えておく必要がある。
残念なことに、この認証方法を採用すると、ユーザ切り替えのたびにユーザは「Webサービスからのログアウト」と「Twitterからのログアウト」の二度手間を強いられることになる。Webサービスからのログアウトだけでは不十分で、次に別のユーザでログインしようとした際に「どのユーザでログインしますか？」と訊いてこなくなってしまう(ついさっきログアウトしたユーザで再度ログインしてしまう)。何故ならTwitterは、既に誰かの名義でログインしている状態だと、「あなたが誰か、私は既に知っていますよ」と言わんばかりにユーザ認証をスキップするからである。
ユーザのストレスを減らす方法は、せいぜいWebサービスからログアウトした直後の画面に「このページからTwitterログアウトできます」というリンクを張っておくくらいのものである。ここでいよいよ、先ほどのURLが登場する。 http://twitter.com/logout へのリンクを張っておけば、ユーザは「ログアウトしますか？Yes/No」に答えるだけで済むはずだ。
この方法はうまくいった…iPadのSafariを除いては。iPadで http://twitter.com/logout を押すと、@logout(はまちちゃんのアカウント)のTweet一覧に飛ばされる。ログアウトはできない。
どうしてこのような仕様になっているのか、私にはよくわからない。また、どこにリンクを張れば、どのようなデバイスでもお手軽にTwitterからログアウトできるのか、わからない。ご存知の方がいらしたら、是非とも教えていただきたい。
ザ・インタビューズというサービスが流行ってますが、今後起こりそうなことを考えてみた。すでに起こっていることもあると思う。
これはまあアカウント制のサービスなら基本。ネタなら後述する「なりきり」になるが、ガチで本人になりすますケースが出てくるでしょう。
単に目立ちたいから、ネット住民を騒がせたいから、くらいの理由でやるならかわいいもんですが、なりすます対象に悪意をもって行うケースというのも出てくると思われる。
運営側の対策としては、TwitterやFacebookなどの既存SNSアカウントとの連携機能をつけるのが効果的なんじゃないかと。
現在はIDのみ設定可能ですがこれは片方向なので、OAuth認証で双方向の連携を。
少なくともTwitterなどで本人であることが確認されていれば、紐づいたアカウントも本人のものであることが明らかになる。
なりすましとは違って、本人ではないことを明記した上で名前を使う場合、あるいは物語の登場人物など実在しない人物の名前を使う場合、なりきりアカウントになる。
Twitterでも結構みかけるので、流行る土壌はあるように思える。
加えてFacebookやGoogle+では規約上不可能なので、規約の緩いザ・インタビューズに流れる可能性がある。ていうか規約ってあるの？
元ネタが実在人物の場合はその人物に怒られる可能性は高いです。非実在でも版権元に怒られる可能性はありますね。
参考：コナミが「ラブプラス」２次創作規制へ？Twitter「姉ヶ崎寧々」のなりきりに削除依頼 - ゴールデンタイムズ
ザ・インタビューズでは回答に画像を貼れるので、ここに著作権上問題になる絵を貼って、それが問題を大きくしそう。
これは、あるのか？
すでにネットでの活動が顕著な有名人がアカウントを取る事例は見受けられるので、ないとはいえない。
答えたくない質問はスルーできるので、ブログの承認制コメント欄くらいのノリで使われるかも。
いろんな意味で緩い系の企業や自治体とかは使うかもね。あと某与党の若手議員とか。
まあこれはなさそうだけど一応。
リークといえば昔は2ch（「○○だけど何か質問ある？」的な）がほとんどだったけど、今は2chが使われることが減ってる気がする。
理由は色々あるだろうけど単に衰退してオワコンだからってのが一番の理由だと思う。
あとアカウント制じゃないのでどれが本人か分かりづらいってのもあるでしょう。IDとかトリップとかは限界あるし。
変な規制が増えたせいで一人が同じスレにたくさん書き込めなくなったってのも大きい。
その点ザ・インタビューズは回答者と質問者がはっきり分かれてるし、たぶんまともに回答ができなくなるような制限もない。
ブログ、Youtube、ニコ動なんかと違って双方向コミュニケーションを容易に取れるので、リークも捗るかもしれません。
ただまあ、ザ・インタビューズの運営がどこまで信用されるかにもよるかと。国内のサービスだからね…
今まで挙げたようなアカウントは特に、当然炎上の危険性を大きくはらみます。
ただ2chやTwitterとかと違って、回答者が答える質問を選べるし、選ばれなかった質問が表に出ることもないので、炎上はある程度コントロールできます。
が、ついかっとなって答えなくてもいい質問に余計な回答を入れて炎上というのはありそう。
なんせ質問者は匿名なのでどんだけ回答者を煽るようなことを書いても批判を直接受けることはないし完全に安全。ここは2chと同じ。
そしてユーザーは大抵Twitterもやってるので、炎上はよりダイレクトに意思疎通ができるそちらに波及するでしょうね。
燃え上がると言えばこっちも発生するでしょう。
既出、あるいは同じような質問、心をえぐる質問、やたらと長文を要求する質問、モラルのない質問、質問爆撃（同じ人が同じ人に嫌がらせを目的として無難で陳腐な質問を大量投下。これシステム上防がれてるのかな？）、バトン（これ今は多分ないけどそのうち出てくると思う。mixiで流行ったアレね）、馴れ合い、等々でだんだん疲れてくるでしょう。
そのうちに質問者ひいては自分の周囲の人物への疑心暗鬼なども生まれることでしょう。
おそらく多くのアクティブユーザー、特に質問がたくさんつく有名人のアカウントは1年以内に放置、休眠状態になると思います。
これは燃え尽き症候群の逆。要するに誰も質問してくれなくてつまらないからやめちゃうというパターン。
このサービスは確かに、誰もが誰もに質問できるサービスではあるけれども、きっと何者にもなれない誰かに質問して楽しいか、という話です。
有名人や友達がたくさんいる人、ぶっちゃければTwitterのフォロワー数が多い人以外はあんまり質問つかないんではないでしょうか。
もちろん面白い回答をつけまくってファンを増やすのはありでしょう。でもそんなことができる人物は大抵すでに他のコミュニティで人気者なんですよ…
といって、システム上自分自身に質問はつけられないので自作自演はできない。複垢とってまで自演してもむなしいだけ。
まあバトンみたいな質問量産体制ができたら質問数は増えるかもだけど、mixiと違うのは質問者が誰か分からない点。
誰だかわからない人物の汎用質問なんて答えて楽しくないんじゃないかね。たぶん3つのデフォ質問に回答するのと同じ気分になると思うよ。
ザ・インタビューズは3か月～半年くらいは他のSNSがたどった道をたどることで盛り上がるけど、やはり同じようにその後は徐々にさびれるんじゃないでしょうか。
2010年の年末から年始にかけて10連休ほどあったので、新しいサイトを作ろうと思い立った。
月に１万円だと、毎日コーヒーを飲んでるだけでなくなってしまうので、コーヒー代くらい稼げたらうれしいなあ。じゃあどうする。何を作る？
ということで、まずTwitterを使ったものを作ることにした。
ひとつのジャンルにしぼってツイートをかき集めれば、面白い流れになるんじゃないか。人が来るんじゃないか。そう思った。togetterみたいな。で、ジャンルは、個人的に興味がある子育て。ていうか毎日帰宅してから朝まで子どもの寝かしつけや夜泣きの対応でサイトを更新する暇も、俺が寝る暇もあんまりない。ので、手がかからないことが大前提。なんだったら自動更新でもいい。
自動更新かー。と思って「ブログ 自動更新」でググったら、wordpressにRSSから更新するプラグインがあるらしいことを知った。はい決定。その瞬間、「TwitterのAPIからRSSを引っ張ってwordpressに投稿するサイト」に決まった。
さくらインターネットのスタンダードを申し込んだ。１４日お試しがあるらしいけど、仮申し込みの時点で住所も入れてコンビニ請求にしたら、数日後に請求書が送られてきてビビった。（同時にドメインも申請しちゃった）
まあ、webで申し込んで、すぐにサーバコントロールパネルという画面に入れるようになった。「クイックインストール」というリンクがあったので見てみたらMovableTypeとWordPressを自動でインストールしてくれるらしかったので、ボタンを押した。インストールできましたというので発行されたURLをクリックしたけど404だった。１時間くらい404で、その日はもう寝た。
次の日の夜。これはもう、１０連休を利用して毎晩1時間ずつ捻出するしかない、さくらのお試し１４日あるから約14時間で作りきるしかねえ、と思った。
サイトにアクセスしたらwordpressが入ったページが出てきた。おお、サイトができてる！
まずTwitterを調べるか、と思って、「Twitter API」で検索したけどOauth？とかいう面倒なことをしないといけないらしかったのでやめた。じゃあ普通に検索は？と思って「Twitter 検索」で検索したら、search.twitter.comの結果はjsonかatomで取得できるし、APIコール制限もないらしいのでこれに決定。検索だけで１時間たった。
夜も更けて、続けて作業した。「wordpress xml 投稿」で検索していくつか探したらFeedWordpressというプラグインがあったので入れた。あ、事前知識としてMovableTypeでのブログはやったことがあったので、プラグインを入れるみたいな話はスムーズに進められた。
で、twitterの検索結果をatomで返した結果を入れてみた。ら、本当に投稿されてた。よっしゃできた、と思った。１ツイートが１エントリになってたし、投稿者もツイートした人になってた。よかった。でも、満足できなかった。
次の日。同じことを自力でやる方法を探した。「wordpress xml 投稿」で検索して、XMLをパースできるようになればいいんじゃないかと思い、simplepieというPHPライブラリにたどり着いた。が、PHPなんてまったく知らないし、憶える気もなかった。actionscriptで書かせてよ、とずっと思ってた。
次の日。「wordpress xml 投稿」でまた検索。どうやらwordpressの投稿って、xmlrpcというやり方を使ってるらしかった。ので、「wordpress xmlrpc 自動投稿」で検索したら、なんかサンプルコードが載ってたのでそのまんまコピペ（結局PHPだった）。したらちゃんと投稿されていた。ふむ。ここで何を思いついたのか、「wordpress xml パース」と昨日みたいなことを検索した。simpleXML？というライブラリがあるらしかったので、それを試してみることにした。（たぶんPHPが動いたので気をよくしてたんだと思う）
こういう流れでいけると思った。考え方はactionscriptをエディタに書いて、ノリであてにいった。変数に宣言するのはできた。＄var1とかで宣言したことになるらしい。URLRequestに相当するコードを探したら「file_get_contents」らしいことが分かった。（「PHP 外部ファイル」で検索）
で、ゲットしたのはXMLなんだけど、上記検索したなかにたまたま書いてあった「simplexml_load_string」というのを使うとXMLをパースできそうな気がしたので、ノリで書いたactionscriptでは
var req:String = "http://search.twitter.com/?q.atom=mogemoge";
var r:URLRequest = new URLRequest(req);
var kekka:XML = r.send() as XML; ←いまここ
なので、XMLにキャストしたんだろうなみたいな感じだった。E4Xを使えればいいのにPHPって馬鹿ねと思いながら寝た。
年があけて、３が日が終わりそうだった。年末にやってたこと（上記までのこと）を思い出しながら、XMLの必要な部分だけ抜き出す方法を模索した。atomっていってもentryがたくさん入ってたから配列にするんだろうけど、ってんで「php foreach」を検索。なんとなくサンプルコードをまねしながら、記事タイトル、記事本文だけ取得した。あとはxmlrpcのサンプルにあわせて投稿するようにした。できた。寝た。
次の日の朝、ブログを見た。昨日更新したものしかあがってない。自動じゃねーじゃん。
で、「自動 投稿」で検索したら、クローン(cron)という仕組みを使わないといけないのだった。クローンはサーバの仕組みらしく、そういえば俺はPHPをはじめDB、サーバという単語を極力さけて仕事してきたので、もう気持ちが悪くなってきた。「さくらインターネット cron php」で検索して、なんとかやり方を見つけて、cronを登録した。(1時間に１回にした。設定は * * * 0)
仕事から帰ってきて、サイトを見ると、投稿が大量にたまっていた。やった！で、調子に乗ってツイッターアカウントを作った。なんだったらツイッターも自動化したかったので「twitter bot」で検索した。Easybotterというサンプルボットがあったので使わせてもらった。自動で一行ずつつぶやくようにした。
ツイートを集めることは成功したけど（毎時間１００件のツイートを１エントリとして投稿してる）、それを眺めて面白いんだろうか？ ボットを動かしてるけど人がくるんだろうか？
そんなとき「trivist」がはてブに載ってた。なんかにたものを感じた。やっぱツイートを引っ張ってきて投稿するサイトはアリなのか？アリなはずだ！
サイトの体裁を整えた
trivistをまねて、記事を評価（はてなスターとかいいねボタンとかに近いもの）する仕組みが欲しくなった。「wordpress 評価 プラグイン」で「wp-postratings」というプラグインを発見して、入れてみた。どうやら１エントリーに１評価しかできないらしい。俺のサイトは１エントリーに１００ツイートあるから、どのツイートを評価するのかが分からない。
いったん、wordpressの全投稿を削除した。で、cron に登録されてるPHPを、１記事に１エントリーにした。
エントリーを投稿するついでに、Yahoo日本語解析APIをつかってツイートを分析して、名詞と動詞だけを取り出そうと思った。それをタグにすれば、タグクラウドが作れると思った。はてブはずっとずっと昔からやってるから、Yahoo日本語解析っていうのが2006年くらいに流行ったことをなぜか憶えてたので、やってみた。できた。
なんか俺、PHP書くのが早くなってね？
アクセス解析を入れてみた。サイトに来てる人は、俺だけだった。
どうにかして人を増やしたい。サイトの広告募集はする気がないし、ベタベタとバナーを貼りたくなかった。みんなが気軽に見に来て、軽い気持ちで評価してくれて、更新を楽しみにしてくれるサイトにしたかった。コミュニティサイトじゃないけど、やっぱりサイトはコミュニケーション設計をしないと意味がないんじゃないか、見てくれるユーザはどうやったら楽しいんだろう、ということを考え続けて１０日ほど経った。Twitter経由で来てくれた人が３人ほどいるようだけど、何がダメなのか分からないので増田にお願い。
ここまで書いて教えてくんじゃねーか、と思われるかもしれないが、ググレカス的な検索は上記で書いたみたいにいろいろやってきた。でも、サイトを作ってみてはじめて、ユーザに向けたサイトってどう作ればいいのかが分からないということに気づいた。
小遣い稼ぎもしたいんだけど、面白いサイトを作るヒントがほしいと思った。
kanzen21やtrivistみたいに、俺も過程を全部さらしたから、辛辣な意見を求む。そしてはてブされるのを待ってます。
このバージョンから今ま
でのBasic認証から、OAuth認証という認証方式になりました。TwitterのBasic認証が2010年春くらいから非推奨になるそうなので。
具体的には、ファイルの中にユーザー名やパスワードを直接書くのではなく、このサイトからTwitterのサイトへ張っているリンクをたどって、Twitterのサイトに認証してもらって、それで発行されたキー（文字列）を保存して、ファイルに書き込んでもらう、という手順を取ることになります。
ちょっと手順としては面倒だけど、今までの方式より安全だし、Twitterを投稿したときに表示されるクライアント名（「webより」などの部分）を変更できるというメリットがあります。
すでにOAuth認証用のキーを持っている人は、そのキーをそのまま使うことができます。
setting.phpに書いてある$consumer_key、$consumer_secret、$access_tokenと$access_token_secretの４つのキーを、自分で取得したものに入れ替えてください。
自分で独自のOAuth認証用アプリを作れば、つぶやきの「送信元」を自由に変更することができます。詳しくはPHP+OAuthでTwitter - SDN Projectなどを参照してください。
まだOAuth認証キーを持っていない方は、ここで取得することができます。その場合、つぶやきの「送信元」は「EasyBotter」になります。
以下のリンク先の指示に従って、OAuth用のキーを取得してください。
俺エロゲー殆どやったこと無い(大昔1～2作品触った程度でとても語れる素地はない)し、興味はないんだけど、別の点で一つ。
世間的にはどうでもいいことなのかもしれないけど、こういう書き方では「この機能がTwitterから正式に認可されて公開される」と勘違いするバカが絶対に出てくるんじゃね？
で、なんとか自分の勘違いじゃないかと思って掲載意図を考えてみたけど、「キチンとTwitterの(OAuth)認証を受けて登録されている。」の意味だったとしてもそれをここで掲載する理由が全くわからない。今のところTwitterに外部ツールから書き込む方法はOAuthしかないんだから、そんなもの言われなくてもわかってるわけだし。
情報強者の皆様ならご存知でしょうけど、Twitter向けアプリケーションは知識とTwitterへの開発者登録さえあれば誰でも作ることが出来ます。そこにTwitterサイドからの審査などは一切ないです。仮に内部的に何かしてるとしても、少なくとも登録時リジェクトはないはず。
横からだけど、LastPassなんかのサーバー型パスワード管理ソフトは
暗号化されてるとはいえ、Webサービスのパスワードを全てサーバーに上げちゃっているわけで
スパコンでマスターパスワード 高々8桁程度を解析してしまえば 全部のパスワードを持って行かれちゃう。
そんな恐ろしい物すら使うユーザーがいるんだから、OAuthぐらい いいよね。と 思わなくもないこともないが 俺は使わない。
そもそも、OAuthどころか、生パスワードを生のまま持って行った、某有名衣料メーカーアプリもあることだし、
ユーザーにとっては・・・まいっか。なんだろうなと。
OAuthがどうのとかアイデンティティがどうのとかじゃなくて、
人のもん勝手に使ったらそら怒られるだろ。アホか。
基本的な所すっ飛ばしてなに言ってんの？
程度の度合いはあれ、加害者が一番悪いんだよ。
他人のからあげに１滴でもレモンかけられたら程度の差はあれ怒られるのが当たり前なの。
バカすぎないかインターネッツの人たち。
四時作者の小池です。面倒だからここに書く。
首記の件はどうでもいいのだけど、
「あ、ちなみにOAuth許可してたらモノにもよるけどアプリケーション側からDMとかも取得できるからね。まあホイホイOAuth登録するんだからDMに住所とかメールアドレスとか大事なこと書いてたりしないとは思いますけどね。」
について。この表現だと誤解を招きそうなので。ユーザーから OAuth 経由での API アクセスを許可されたアプリケーションは、そのユーザーが読むことが出来るデータの全てにアクセスできます。書き込みを許可していればアカウント削除以外のことは大体出来る。
DM を「読む」だけなら OAuth 認可を受けたコンシュマーは誰でもできます。
デスクトップアプリケーションであれば通信を監視すればよいけど、 Web アプリケーションの場合はそれが出来ない(例えば四時と twitter の間で何か通信をしたとしてユーザーからそれが見られない)です。
何度も言っていることですが、 DM を読まれるとかそういう件については、 OAuth で twitter と連携する Web アプリケーションは一律「信用できない」ということになります。 mixi ボイスの twitter 連携だとか HootSuite とかでも、それはそうです。一律ゼロ。
だけどそこに提供者の信頼を加算することは、出来るでしょう。それは個々人の価値観の問題だ。
ちなみに僕は自分が作ったアプリケーション以外には、特に Web アプリケーションには、 OAuth を許可しません。他人の住所などを DM で多数受け取っていて、それを暴露させる可能性は少しでも下げたいからです。
なる四時の騒動をまとめとく。（追記:ブクマされてるので念のため書いておくが増田は素人です。技術的な面に関しては参考までにどうぞ。）
間違ってたらトラックバックなりなんなりで訂正してくれ。
なるほど白夜じゃねーの #4ji
http://twitter.com/ssig33/status/20179930626
http://twitter.com/ssig33/status/20179966911
favoritesがどれくらいの速度出るのか試してみたい
http://twitter.com/ssig33/status/20179979441
その結果、以下のpostが大量favされる（favstar参照）
http://favstar.fm/users/ssig33/status/20179930626
http://favstar.fm/users/youpy/status/20124150089
ところがfavが消せない（小池はfavを消すつもりだったと思われる）
っていうか今 fav 消せないの何
http://twitter.com/ssig33/status/20180907486
Web からは fav 消せるなあ
http://twitter.com/ssig33/status/20181045593
もしかして四時の token だけ弾かれてる？
http://twitter.com/ssig33/status/20181057823
(token:OAuthトークンのこと。http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html を参照。分からなければ「アプリから操作を行う権限」とでも思っておけばいいはず。)
四時の token から favorite を消せない
http://twitter.com/ssig33/status/20181132468
そして現状に至る。
何故か8/3の15時頃より急に拡散してるっぽい。
小池氏が悪いとか叩く前によくわからずに「なる四時」を登録しちゃったユーザも悪いと思うんだよね。
登録した人はどうせノリで登録してるでしょ？
あ、ちなみにOAuth許可してたらモノにもよるけどアプリケーション側からDMとかも取得できるからね。まあホイホイOAuth登録するんだからDMに住所とかメールアドレスとか大事なこと書いてたりしないとは思いますけどね。(追記:小池氏本人より訂正がありました。すまん。 http://anond.hatelabo.jp/20100803163235)
favやpostだけなら大したことなくても本来隠匿されているDMもアプリ開発者によって自由に閲覧できるわけだよ？
増田はそのあたり良く考えてからOAuth認証したがいいのではないかなと思いますね。
最後に関連ページをリンクしときます。はてな記法良くわからんのでURLそのまま貼る。つーか文中のURLもおかしいけど許してくれ。
http://4ji.ssig33.com/ - なる四時
http://twitter.com/ssig33 - @ssig33(小池 陸)
http://d.hatena.ne.jp/ssig33/20100803 - twitter の速度について(ssig33)
http://syawa.net/t/4ji - なるほど4時じゃねーのを使っているユーザ一覧 しゃわたん(@syawatan)氏作成。
http://r.nanapi.jp/2965/ - Twitter「なるほど四時じゃねーの」を解除する方法
大企業から、中小企業まで、どんだけ、なんちゃってSIerがいると思ってんだと。
某ユニクロ様ですら、twitter事件でOAuth使えなかったんだぜ？
日本のITがどんだけかって話だよなぁ・・・orz すまん、泣きたいよ。
全角半角な・・・某有名Perlの人の全角半角変換が他の文字の中で文字化けする文字があって使えなかったんで
１から書いたことがあるんだが、文字通り５０音テーブル書くだけなんで、チャラいよなぁ。なんで、やんねーんだろうな。
日本のSIerってそういう、やっても大して稼働食わないところは、断るくせに。
文章で書いたら１行でもテスト工数が莫大でものすごい大変みたいなところをあっさり受けて、デスマってたりするよなぁ。
ほんと、客もSIerもまともに見積もれない人が多すぎるよ。この国・・・こういうと、客が・・・見積りってツッコミがよくあるけど、
やっぱり、客にも客レベルってあるよ。
Twitter の OAuth 許可ページがあまりにも酷い => 応急処置 - リタマス
これのGreasemonkey スクリプトが危険だったので修正したよ！
このスクリプトは、本文中にupdate（または更新）が入っている時に警告を出すようになっていたんだけど、これだとチェック漏れのバグがあるとwrite権限を要求しているのに警告が出ないのでread onlyのように見えてしまう
人間が本文読めばわかるから大丈夫だろと思うかもしれないけど、このスクリプト使い続けていたら警告が出ない＝read onlyだと判断して本文読まなくなるはず
read onlyの時にも色を変えて警告を出すようにした（writeなら赤、read onlyなら黄）
これで警告表示の色を見れば赤ならwrite黄ならread onlyだとすぐにわかるし、警告がでなかったらなんかおかしいとすぐに気づくはずだ
危険なものと安全なものが混ざってる中から危険なものを選り分けても安心はできないけど、安全なものを選り分けたんなら安心できるよね！（これなんか専門用語ありそうだけど僕は知らない
最初のスクリプトだと https://twitter.com/oauth/authorize?* と https://twitter.com/oauth/authenticate?* で動くようになってたけど、
twitterのOAuthの認証ページは他にもhttpsのかわりにhttpを使ったものとか、twitter.comのかわりにapi.twitter.comとかがあるから、それらのページでは警告が出なかった
IDとパスワードを教えなくても いろんなサービスに自分の情報の一部を見せたり書き込みさせたり出来る仕組みの事。
違う。
Twitter使ってて最悪のパターンって、パスワード変えられて完全にアカウントを乗っ取られ、友人知人関係が壊滅。さらにメアドも抜かれて同じパスワード使ってそうな所も漁られて無茶苦茶されることじゃないか？
パスワードを教えるとそんな事が起きるかも知れない。そこでTwitterは、パスワードを教えなくても「書き込み権」や「読み込み権」を与えられる「OAuth」ってのを用意してる。
例えばブログを更新したら自動的にTwitterに「ブログ更新したよ！ htt...」って書いてくれるサービスなどがある。他にも写真や動画を上げたらとかブクマしたらとか。 当然全て「書き込み権」がないとサービス提供できない。
逆に、iPhoneなどでReplyやRTをもらったら通知してくれるアプリもある。 こちらも、この手の情報は基本的に「読み込み権」がないと取得できない。
で、こういうサービスを使う度にパスワードをばら撒くのはヤバすぎだろｊｋ、ってのが Twitter が言ってる事。
（なお、どんなサービスがあるかは纏めてくれてるところ参照で。結構色々あって見てるとｗｋｔｋ出来る。）
確かにそのとおり。でも画面をちゃんと見てないあなたも悪い。
今回問題になった「Ｑ＆Ａなう」というサイトの場合このような画面になったはず。太字の所だけ抜き出すと
後はわかるな？
Twitter側も、この画面をいつまでたっても翻訳してないし、問題がある。前はもっとわかりにくかったので多少改善はしてるけど。
でも、ある程度日本語化されてるとは言っても、やっぱり海外のサービスを使ってるわけで、「拒否 or 許可」とかの場合は少しぐらいは注意した方がいい。
周りにいるだろ？ 日本語ですら「OK or キャンセル」とか「はい or いいえ」を読まずに押してパニくってる奴が。あんな風にならないようにだけ気をつければいい。
使いたいサービスなら許可すればいい。その代わりそのサービスにスパムを撒かれたりする可能性はどうしても残る。
ポイントは
今回なら
私も FriendFeed や Boxcar なんかは、信用した上で許可してる。彼らにスパム撒かれたらそれはもう仕方ないと割り切って。正直なところBoxcarはなんで読み書きなのか意味が分からんのでかなり躊躇ったけど。
https://twitter.com/account/connections
ここに行けばあなたがこれまで許可したサービスの一覧が出る。よく分からん物とかがあればここから「許可を取り消す」とすればいい。
こういう風に後から個別に許可を取り消せるのも OAuth のいいところ。全部にパスワードを教えてる場合だと、まずパスワード変更して全サービスお断りにしたあと一つずつ再設定していかないといけない。
なお、OAuth は Web とかのソースコードを利用者に見られないサービスで主に使われるので、ＤＬするタイプのアプリケーションとかではまだまだパスワード認証が主流。最近少しずつ変わってきてるけど。
ネタフルのHootSuiteの記事（http://netafull.net/twitter/032057.html）を読んで個人アカウントで試してみたが、企業アカウントでは全く使えないことがわかった。
複数アカウントが使えるのはいい。複数ユーザーで使えるのもいい。RSSフィードを流せるのも、時間指定して投稿できるのもいい。デフォルトでは@hootsuiteを自動でフォローするようになっているのもかまわないだろう。グループの表示に検索を使ってるようで、protectedのアカウントや公式検索に引っかからないアカウント（15%ほどいるらしい）を追加できないことにも目をつぶろう。
何が駄目か。
twitterとの連携にOAuthではなくパスワードを使っている事が致命的である。
パスワードがあればパスワードの変更もメールアドレスの変更もできる。つまりパスワードがもれるとアカウントの完全な乗っ取りができてしまう。乗っ取られても個人アカウントなら新しいアカウントを作って友人にフォローしてもらうだけですむ。だが、企業アカウントではフォロワーはお客様だ。それもコストをかけ宣伝し、こつこつと積み重ねてきたフォロワーだ。スパム的な方法で3500人までフォロワーを増やしてアカウント停止された@tweeterjpも、新しいアカウントをスパムまがいなRT署名で宣伝してやっと440人といったところだ。
何ヶ月かかけてやっと1000人のフォロワーが集まったというようなまともな企業アカウントでは、これは致命的な事になる。
OAuthが正式に採用されてからすでに数ヶ月は経っている。それなのに仕様変更の多いtwitterでいまだにOAuthに対応できていないというのは、ろくにサポートされていないか、悪意をもってパスワードを集めていると思われても仕方ない。これでプロフェッショナルクライアントを名乗るのは企業ツイッターユーザーを馬鹿にしているとしか思えない。
こんなのにだまされるようでは本気でtwitterに取り組んでいるとは言えないだろう。ネタフルの記事を見て今日からHootSuiteを使い始めた企業アカウントがあれば、それはまともな企業ではないので即リムーブをオススメする。
個人で使うにはそんなに悪くないと思うよ。http://hootsuite.com/
